[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)
My discuss comments are addressed in new revision.
Pls change my DISCUSS into a noObjection
Thanks,
Bert
> -----Original Message-----
> From: Jacqueline Hargest [mailto:jhargest@foretec.com]
> Sent: dinsdag 6 mei 2003 0:07
> To: hardie@qualcomm.com
> Cc: iesg@ietf.org
> Subject: 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.
> >
>