Subject: FW: IESG Review Comments

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 17 Oct 2002 14:51:01 -0400

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:[email-masked]]
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?

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Oct 2002 16:12:58 -0400

Scott,

The choice of labelN.labelN-1..label1.label0, for values of N < big, seems
to be entirely editorial in nature. Second, while Donald may have had the
best of intentions in bagging some SLDs (example.{com,net,org}, the strings
MUST, MANDITORY, MUSTY and MANDIBLE occure nowhere in 2606, therefore to
conclude that some labelN.labelN-1..label1.label0 sequence is "wrong" seems
without foundation.

Personally I don't care what you do, and I do wish IESG review would focus
on the protocol, not the namespace ephemera. If someone from .be could get
"cenestpasunepipe.be" (The Treachery of Images) that would be splendid, and 
get the ICANN marketing cruft out of the way.

utterly-bogus.nld and pseudo-random.nld work for me.

The point is a clear spec, nothing else.

Eric

---

From: "Ram Mohan" <[email-masked]>
Date: Thu, 17 Oct 2002 17:19:43 -0400

Scott,
As you may have noticed, in the Bucharest ICANN meeting, the Board resolved
to have registries adopt the proposed Redemption Grace Period
(http://www.icann.org/bucharest/redemption-topic.htm) policy.

Embedded in the document are the following, which may have an impact on EPP.
I forward to provreg to determine if any of these need to be factored into
our thinking.  (New capability, may or may not need a command; new domain
status if agreed to, will require some remapping)

-ram
>>Creation of New "RESTORE" Capability

The Technical Steering Group proposes the creation of a new "RESTORE"
capability that can be provided by a registry to registrars via one or more
of the following methods: a modification of the registry/registrar protocol,
an administration website, a fax service, or a telephone service. The
RESTORE capability will only affect names that are within the Delete Pending
Period. In other words, all RESTORE requests for names not in the Delete
Pending Period will be ignored.

>> Registry Transparency Requirements for Deleted Names

In order to ensure fairness to all registrants and registrars, the Technical
Steering Group proposes that deleted and restored names should be handled as
openly and transparently as feasible. Original registrants and those wishing
to be "next in line" to register a name that is being deleted should be able
to tell when a name was deleted and when it will be "returned to the pool"
of names available for registration.

Accordingly, under the proposal, a registry Whois check on a name that is
within the Delete Pending Period would return at least the following
information:

  Domain Name: example.com
  Sponsoring Registrar: exampleregistrar.com
  Domain Status: DELETE PENDING PERIOD
  Delete Requested: 31-may-2002

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 17 Oct 2002 17:41:08 -0400

1. Mailing list names and URLs

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving 
   working document readily available to a wide audience, facilitating 
   the process of review and revision.

Having mailing list, the url for the IETF's "Internet-Drafts" directory [1],
for the working group, its archive, seems to meet the clear sense of sec2.2
of 2026. After the development is complete, they do seem likly to "age".

In any case, this is an RFC editor issue, and rather cosmetic..

2. Manditory to implement transport confidentiality or confidentiality and
   integrity.

Hmm. This was not a requirement when the prevailing model of access was
described in rfc518. How about rfc597? Nope. How about at the dawn of the
classical period with rfc625? Nope. Let's try rfc756 (keep this in mind,
I do), and Nope again. ... Skipping ahead to the dawn of the modern age
there is rfc1261 -- and another Nope. Not until we get to rfc2832 does
the possibility even begin to exist.

There is, or are, one or more use-case assumptions buried in this that
must be beaten out of the mush of "Security". I don't know what they are,
yet.

3.,4. Sigh. the authInfoType isn't of type token. Fix language (not
schema).

5. Now there is a catch worth paying for. Thanks Steve!

6. Scott's note (Bradner I assume) interests me.

What would interoperating implementations of EPP look like, if they either
attempted congestion control themselves (now there's an extension), or if
they could cause congestive collapse of some transited link. For it to be
of any but local interest, and not expose some fatally stupid bandwidth
under provisioning at the registry (I can think of one) and constitute a
(self-inflicted) DOS attack, the failed transit link would have to be a
core link.

Even counting-to-infinity type events didn't cause congestive collapse
when I was younger and an operator.

Feel free to think out loud folks, why does congestion control really
matter? This seems rather far from the VGRS "storm" events.

I've commented on 7 seperately.

I'll think about 8. This is on-par with element-level XML encryption.
(Ironically, the XMLP activity is "on the other line" about just this.)

Eric