[ietf-provreg] Summary of IESG Comments and Disposition

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

This note describes the IESG review comments that we've received and
addressed in the most recent versions of the EPP specifications.  Here are
the references to the current documents:

http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt
I just finished this version today.  This is a temporary location until the
document is announced by the Internet-Drafts administrator after the San
Francisco meeting.

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt

Here are the references to the IESG comments along with a description of
what was done to address them:

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html

1. <draft-ietf-provreg-epp-07.txt>
Do we put mailing list names and URLs in RFCs?

RESOLUTION: The paragraph describing the mailing list and archives has been
removed.

2. I'd like a stronger Security Considerations section, though I think it
can be added by an RFC Editor note.  In particular, I want it to say that
EPP "MUST NOT be used over a transport mechanism that does not provide
confidentiality", or "All transport mappings for EPP MUST provide
confidentiality and integrity".  (I think that that's what they intend, but
it's not clear enough.)

RESOLUTION: The text has been changed to read "EPP instances MUST be
protected using a transport mechanism or application protocol that provides
integrity and confidentiality".

3. <draft-ietf-provreg-epp-domain-05.txt>
What is an "authorization token"?  It's not defined, but it's mandated by
the security considerations.  (I suspect it's what is discussed in 2.6, but
it doesn't use the same words.)

RESOLUTION: The text describing an "authorization token" has been changed to
use the same "authorization information" term described in section 2.6.

4. <draft-ietf-provreg-epp-contact-05.txt>
What is an "authorization token"?  It's not defined, but it's mandated by
the security considerations.  (I suspect it's what is discussed in 2.8, but
it doesn't use the same words.)

RESOLUTION:  The text describing an "authorization token" has been changed
to use the same "authorization information" term described in section 2.8.

5. <draft-ietf-provreg-epp-tcp-05.txt>
The Security Considerations section seems to require TLS client
authentication, which in turn requires client certificates. Is this
intended?  If so, great!  But in that case, what is the fate, if any, of the
EPP login/password command?  Is it still needed?  Is it still legal?  What
does it mean?  Must the identities agree? (The requirement for server
authentication is excellent, but some more text mentioning the need to
validate the certificate chain is probably a good idea.)

RESOLUTION: The Security Considerations section has been modified to
explicitly note the need to validate the certificate chain.  The
certificates used for TLS authentication authenticate the client and server
machines involved in the provisioning exchange.  The EPP login functionality
is still needed, though, as it provides a facility to authenticate client
user identities so that the server can make access control and authorization
decisions based on the identity of the client, in addition to the identity
of the machine the client is using to communicate with the server.

6. <draft-ietf-provreg-epp-07.txt> sec 2.1
I think it would be good to be a bit more strict about the use of congestion
control protocols specifically require the use of an IETF standards track
congestion control protocol such as TCP or SCTP

       i.e. change the following line:
       - The transport mapping MUST manage congestion.

       to:
       - The transport mapping MUST only be to an IETF standards
       track congestion control protocol such as TCP or SCTP.

RESOLUTION: Section 2.1 has been modified to read as follows:

"- The transport mapping MUST be onto a transport such as TCP [RFC793] or
SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914
[RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP
[RFC3080], then the performance issues need to take into account issues of
overload, server availability and so forth."

7. <draft-ietf-provreg-epp-07.txt>
page 12, example greeting has:

     S: <svID>Example EPP server epp.example.tld</svID>

in an example greeting. Did we not decide at some point that examples should
be of the form: epp.example.org ??

RESOLUTION: All examples in all documents have been changed to use the
example domain names (example.com, example.net, and example.org) described
in RFC 2606.  Sample IPv4 addresses have been changed to use the Test-Net
address block listed in RFC 3330.

8. why do domain/contact/.. not have granular information about privacy?

RESOLUTION: This comment has been addressed through a very lengthy
discussion process that resulted in making the existing <dcp> element
mandatory.  This change is reflected in a new version of the core protocol
document that can be seen at the temporary URL provided at the top of this
message.  The formal announcement will be made after the San Francisco IETF
meeting.

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html

1. The transport mapping MUST manage congestion.

RESOLUTION: See the resolution for item 6 above.

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html

<draft-ietf-provreg-epp-07.txt>
1. The transport mapping MUST manage congestion.

RESOLUTION: See the resolution for item 6 above.

2. Within the optional dcp (data collection policy) element: there is a
non-technical spin in at least the following label definition, what kind of
marketing is meant?

  <contact/>: Contact for marketing purposes.

Please add more to this definition so that is more neutral in in its
terminology.

RESOLUTION: The description of this element has been changed as follows:

"<contact/>: Contact for marketing purposes.  Information can be used to
contact individuals, through a communications channel other than the
protocol, for the promotion of a product or service.".

3. How does IESG and the community check the extensive XML in a
specification like this (analogous to the ABNF and MIB checking described
that is done regularly...)?  How did you check what's here?  Why might it
not matter?

RESOLUTION: Syntax checking matters.  There are a variety of freely
available XML syntax checking utilities, such as the Xerces XML parser
written in Java, that can be used to validate all of the schemas and
examples provided in the documents.  The normative schemas can be copied
from the documents, edited to remove page headers and footers, and pasted
together to create the formal syntax specifications for the protocol.
Examples can be copied from the documents, edited to remove the "C:" and
"S:" line prefixes, and pasted together to create a set of sample instances
of the protocol.  Scott Hollenbeck has also published external files
containing all of the examples and schemas in two public places:

ftp://ftp.verisign.com/pub/epp/

http://www.verisign-grs.com/files/

Other WG members are mirroring these file collections to provide additional
redundancy.  The examples and schemas can be run through an up-to-date
validating XML parser to confirm validity.  As part of the normal document
editing process, Scott has been running all of the examples and schemas
through the Xerces-J parser to confirm that everything remains valid
according to the current W3C XML Schema specifications.

<draft-ietf-provreg-epp-tcp-05.txt>
1. "An EPP client streams EPP commands to an EPP server on an established
TCP connection.  A client MAY establish multiple TCP connections to create
multiple command exchange channels.  A server MAY limit a client to a
maximum number of TCP connections based on server capabilities and
operational load."

It is not a good thing for the net for services to choose this approach.  A
MAY like this is problematic for congestion control reasons.  I would like
to change this language from "MAY establish" to "MAY but SHOULD NOT" and
from "A server MAY limit" to "A server SHOULD limit"

RESOLUTION: Text changed as requested.

2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914

RESOLUTION: References added.

That's it!  I'll try to have the updated EPP schema and example package
(none of the examples changed) uploaded to the public locations as quickly
as possible.

-Scott-