[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [iesg-secretary #6902] draft-provreg-epp document set back to ballot (wg response attached)
Your request #6902 was resolved by jhargest:
These documents have been added to the next telechat agenda.
Randy's position has been changed to a "no-ob".
Jon, please advise on Scott's and/or your position at your
earliest convenience.
Thanks,
Jackie
>>>>>>>>>>>>>>>>>> Original Message >>>>>>>>>>>>>>>>>>
>Subject: draft-provreg-epp document set back to ballot (wg response attached)
>From: Ted Hardie <hardie@qualcomm.com>
>To: iesg@ietf.org, iesg-secretary@ietf.org
Hi,
Please add the set of documents associated with draft-provreg-epp
to the ballot for the next telechat. Because Scott was one of those
holding a discuss, we need to check if Jon wants to hold onto his
discuss. Please move Randy to no-objection, based on the email he
sent at the retreat.
For those others holding a discuss (Ned, Allison, Jon (for Scott),
Steve,
and Bert), please review the points below to ensure your needs have
been met.
thanks,
Ted Hardie
Begin forwarded message:
> From: Edward Lewis <edlewis@arin.net>
> Date: Mon Apr 28, 2003 11:04:11 AM US/Pacific
> To: iesg-secretary@ietf.org, hardie@qualcomm.com
> Cc: Edward Lewis <edlewis@arin.net>, jaap@sidn.nl,
> ietf-provreg@cafax.se
> Subject: [ietf-provreg] provreg wg responses to IESG comments
>
> 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.
>