FW: IESG Review Comments

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

Forwarded with Patrik's permission for the benefit of the WG, these are the
comments received back from the IESG's review of the EPP documents.  I'll be
editing the documents shortly to incorporate the IESG's suggested text
changes and others received from the WG over the last few weeks.

I've added annotations to number the comments in this message.  We're still
trying to obtain clarifications for comments 6 and 8.

-Scott-

-----Original Message-----
From: Patrik Fältström [mailto:paf@cisco.com]
Sent: Tuesday, October 15, 2002 5:17 AM
To: Scott Hollenbeck
Cc: Jaap Akkerhuis; Edward Lewis
Subject: Discuss on epp documents


[Ooopss....I forgot to click on "send", this window has been sitting 
for a week in my laptop behind the window with the mailboxes....I AM 
SORRY]

 From IESG:

Steve:

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

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

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

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

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

Scott:
note:

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.

Bert: document: draft-ietf-provreg-epp-07.txt

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

Patrik answers:

 > We should follow RFC 2606 which states that:
 >
 > 3. Reserved Example Second Level Domain Names
 >
 > The Internet Assigned Numbers Authority (IANA) also
 > currently has the
 > following second level domain names reserved which can be used as
 > examples.
 >
 > example.com
 > example.net
 > example.org
 >
 >
 > I.e. using "tld" as an example top level domain is wrong.
 >
 > Can you please have a discuss on this?
 >
Sure... it seemed more like a small nit to me, in any event, such a
discuss I think can be cleared with a RFC-Editor note.

Randy:

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