Re: [ietf-provreg] Summary of IESG Comments and Disposition

["Ram Mohan" <rmohan@afilias.info>]

Scott,
Thanks - good work!

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: <ietf-provreg@cafax.se>
Sent: Tuesday, March 11, 2003 9:49 AM
Subject: [ietf-provreg] Summary of IESG Comments and Disposition


> 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-
>