[ietf-provreg] provreg wg responses to IESG comments

[Edward Lewis <edlewis@arin.net>]

About this message:

The original form of this note is written by Scott Hollenback.  I've 
updated it based on our further work on one comment and the addition 
of host attributes which is summarized after the IESG comment 
responses.

  - - -

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-07.txt

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

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

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

Here are the references to the IESG comments (part I) 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 and the addition of a disclose element.  Making <dcp> mandatory
is documented in the EPP base document, descriptive text in section 2.3
and in the schema in section 4.1.

The definition of the <disclose> element appears in the contact mapping
document, first appearing in section "2.9 Disclosure of Data Elements 
and Attributes" with modifications to sections 3.1.2, 3.2.1, and 
3.2.5.  In
section 3.1.2, the <authInfo> element is added to <info> command so 
that authorization decisions can be made when disclosure elements are 
also provided.

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

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00116.html and 
follow ups to that message.

IESG comments, part 2, as in the following URL:
   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.

  ----------------------------Other Edits------------------------------

Due to comments received by the chairs off list, the WG revisited the issue
of hosts-as-attributes instead of host objects.  The reason for revisiting
this issue at such a late date is the increasingly widespread review 
of the EPP documents by individuals.

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00051.html

The WG has adopted the the option of including hosts (name servers) 
as attributes on domain objects as a mutually exclusive option to 
host objects.  As part of this, address data is also permitted but no 
other DNS data.  These
changes appear in the domain mapping document, first at the end of 
section 1.1 to describe new provisions.  Also, modified schema and 
text appear in sections 3.1.2, 3.2.1, and 3.2.5.  In the new section 
"2.7 Other DNS Resource Record Attributes" contains a discussion that 
limits DNS data to just addresses.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.