Subject: [Enum] LAST CALL for draft-ietf-enum-rfc2916bis-05.txt

From: Richard Shockey <[email-masked]>
Date: Wed, 09 Apr 2003 10:49:27 -0400

I think it is fair to say we have thoroughly discussed this document and 
reached rough consensus on the contentious issues as reflected in this 
version so as the non author chair I'm going to declare a last call on this 
for a 2 week period.

So ....

This is a formal request for final comments within the IETF ENUM WG
working group for one document. The document below is being proposed for
forwarding on to the IESG for consideration as Standards Track RFC.

This is a working group product, which has been thoroughly discussed since 
2001.

This document has undergone extensive review and revisions during the past 
few months and I believe that we now have working group consensus on its 
adequacy based on discussion on this list and at several working group 
meetings.

The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections which have
not gotten previous or adequate discussion, or minor errors which need
correction.

The 2 week Last Call will begin immediately and will end on April 23 at 
12PM EST

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Telephone Number Mapping Working Group of 
>the IETF.
>
>         Title           : The E.164 to URI DDDS Application (ENUM)
>         Author(s)       : P. Faltstrom, M. Mealling
>         Filename        : draft-ietf-enum-rfc2916bis-05.txt
>         Pages           : 24
>         Date            : 2003-4-8
>
>This document discusses the use of the Domain Name System (DNS) for
>storage of E.164 numbers.  More specifically, how DNS can be used for
>identifying available services connected to one E.164 number. It
>specifically obsoletes RFC 2916 to bring it in line with the Dynamic
>Delegation Discovery System (DDDS) Application specification found in
>the document series specified in RFC 3401.  It is very important to
>note that it is impossible to read and understand this document
>without reading the documents discussed in RFC 3401.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-05.txt

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Fri, 11 Apr 2003 15:24:06 -0400

At 09:39 AM 4/11/2003 +0800, bill wrote:

>Hello, folks:
>
>Following is some of my comments:
>
>[1]section 1.2:"...that is how to handle numbers allocated according to 
>the ITU-T standard E.164...", E.164 is a recommendation, so I prefer to 
>use recommendation than standard here.

OK ..this is an appropriate nit .. I agree with your suggestion.

>[2]section 5, the two paragraph in the middle: "
>    IAB is to coordinate with ITU-T TSB if the technical contact for the
>    domain e164.arpa is to change, as ITU-T TSB has an operational
>    working relationship with this technical contact which needs to be
>    reestablished.
>
>    Delegations in the zone e164.arpa (not delegations in delegated
>    domains of e164.arpa) should be done after Expert Review, and the
>    IESG will appoint a designated expert."
>
>I personally think these words are related to the management of e164.arpa 
>in practice and not very suitable in this section. There have been an 
>instruction to RIPE from IAB and an interim procedure from ITU-TSB in 
>place, as well as liaison between ITU-TSB and ISOC/IAB dealing with the 
>future cooperation. So maybe here just give some reference in this paper 
>for those who may interested in the management of e164.arpa.

Well IMHO this is almost the same text as in 2916 I think we have strong 
consensus in the WG that we don't want to see this document delayed any 
longer. IMHO this issue is not fundamental to the protocol

>[3] the security consideration section said too many things about the DNS 
>security threat which was mostly cited from a I-D of DNSEXT WG. I 
>personally think it should make some summary here about the DNS security 
>problems and give reference to the documents for further information.

I appreciate your comments but I think given the unique audience for this 
draft it is useful and prudent to be somewhat pedagogical as Dave Crocker 
mentioned in a earlier message on the list. I continue to support the text 
as is.

>Best
>-bill
>2003/04/11

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 12 Apr 2003 00:29:05 +0100

At 10:49 am -0400 9/4/03, Richard Shockey wrote:
>I think it is fair to say we have thoroughly discussed this document 
>and reached rough consensus on the contentious issues as reflected 
>in this version so as the non author chair I'm going to declare a 
>last call on this for a 2 week period.
>
>So ....
>
Hi Folks,
   first comment. Change to section 3 requested.

At the meeting (BTW, MANY thanks to Brian and our esteemed co-chair for
the minutes) in response to my question, it was agreed to change the
spec to require a standards track or experimental RFC, as some of the
enumservices done during trials will be experimental (that's why we do
trials :). This is not reflected in -05.

In 2916bis-05, the last sentence of Section 3 currently reads:
    "In order to be a registered ENUM
    Service, the entire specification, including the template, requires
    approval by the IESG and publication of the Enumservice registration
    specification as an RFC either on the Standards Track or as a BCP".

Please change this to:
    "In order to be a registered ENUM
    Service, the entire specification, including the template, requires
    approval by the IESG and publication of the Enumservice registration
    specification as an RFC either on the Standards Track or as a BCP or
    an Experimental RFC".

(side) point:
Looking at 2026 section 5, I don't see how an enumservice could ever be
defined in a BCP.

The meeting minutes show a group reluctance to include Informational (as
I read it), but it seems that the 2026 description of BCP is not really
appropriate to an enumservice definition as described in 2916bis section 3;
a Standards track RFC would seem to be required, if the enumservice is
not defined in an Experimental. I'm not asking that "BCP" be removed,
but I just don't understand this. Any elucidation gratefully received.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum