Subject: RE: [Enum] Re: refresh: IESG review of rfc2916bis

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 4 Oct 2003 21:20:06 -0500

> 
> Was the language on what type of RFC the enumservice field registrations 
> could be ammended ?..the consensus was all ENUM service fields 
> registrations must be either proposed, draft, or experimental but not 
> Informational.
> 

I thought it was supposed to be standards-track, BCP or experimental (and
yes, not Informational).

Jon Peterson
NeuStar, Inc.

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 5 Oct 2003 11:20:15 +0100

>I thought it was supposed to be standards-track, BCP or experimental (and

Hi folks,
   (BCP is not standards track :).
Many thanks to Jon for the reminder - someone with a memory.

IIRC, the discussion went -
Earlier drafts said ENUM service field registrations 'must be defined 
in a standards track RFC'.
*  "need to include Experimental for trials, and that isn't Standards track"
*  "just say 'must be defined in an RFC'"
*  "don't want to include Informational"
*  "just say 'must be defined in a standards track or experimental RFC'"
*  "may well want to include BCP"
*  "say 'must be defined in a standards track or experimental RFC, or 
in a BCP'"
All agreed.

This sentence revision fell in the bit bucket during final draft prep, hence
the "please put it back in as agreed" a few months back.

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.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Oct 2003 12:26:27 +0200

Lawrence, others...

The quickest way this can be resolved is by having you look at version 
-06, and propose a OLD/NEW text.

Can one of you do that please?

    paf

On 2003-okt-05, at 12:20, Conroy, Lawrence (SMTP) wrote:

> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, 
> Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is 
> confidential to
> Roke Manor Research Ltd and must not be passed to any third party 
> without
> permission. This communication is for information only and shall not 
> create or
> change any contractual relationship.
>

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 5 Oct 2003 11:58:00 +0100

At 12:26 pm +0200 5/10/03, Patrik Fältström wrote:
>Lawrence, others...
>
>The quickest way this can be resolved is by having you look at 
>version -06, and propose a OLD/NEW text.
>

Hi Patrik, folks,

  First, the irresistible comment about drafts in XML format -
<whinge> I could give the .txt line numbers but the are no use to the 
authors </whinge>
Hence, please look through the XML source for a matching section title.
Now that's out the way...

I've tried to re-structure the sentence concerned (1st sentence
in section 3.1.4) so that it's a bit easier to read in its
extended form.
BTW, one could put either 'in' or 'as' in that sentence. To me,
'as' implies that the document has the sole purpose of registration;
'in' may be more appropriate, particularly for a BCP. However, this
may be a nit too far, hence it's left as in the OLD.

OLD:
3.1.4 Publication Requirements

    Proposals for Enumservices registered must be published as RFCs on
    the Standards Track or as a BCP. IANA will retain copies of all
    Enumservice registration proposals and "publish" them as part of the
    ENUM Enumservice Registration tree itself.

NEW:
3.1.4 Publication Requirements

    Proposals for Enumservices registrations MUST be published as one of
    the following documents; RFC on the Standards Track, Experimental
    RFC, or as a BCP.

    IANA will retain copies of all Enumservice registration proposals
    and "publish" them as part of the ENUM Enumservice Registration tree
    itself.

all the best,
   Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Oct 2003 15:22:23 +0200

I think we definitely are where we need a new version of the I-D.

Michael, can you take my proposed changes and the text below and create 
a new I-D?

    paf

---

From: Richard Shockey <[email-masked]>
Date: Sun, 05 Oct 2003 11:22:28 -0400

At 09:22 AM 10/5/2003, Patrik Fältström wrote:

>Michael, can you take my proposed changes and the text below and create a 
>new I-D?

are you sure we need to revise the ID and resubmit to the WG ...this is 
going to open up a whole can of worms but if we need to do so then we can 
go to last call at the moment of issuance.

Is this the consensus opinion of IETF Management as well? because I'm going 
to have to send a note to the list explaining this.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 5 Oct 2003 17:47:34 +0200

On 2003-okt-05, at 17:22, Richard Shockey wrote:

>> Michael, can you take my proposed changes and the text below and 
>> create a new I-D?
>
> are you sure we need to revise the ID and resubmit to the WG ...

No, not resubmit to the wg. Just create a new I-D so the work for the 
rfc-editor becomes easier.

    paf

> this is going to open up a whole can of worms but if we need to do so 
> then we can go to last call at the moment of issuance.
>
> Is this the consensus opinion of IETF Management as well? because I'm 
> going to have to send a note to the list explaining this.
>
>
>>    paf
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 05 Oct 2003 11:23:59 -0400

At .
>    and "publish" them as part of the ENUM Enumservice Registration tree

no BCP that is not necessary..

standards track, proposed draft or actual standard and Experimental.  BCP's 
are for other things

---

From: Michael Mealling <[email-masked]>
Date: 06 Oct 2003 10:10:42 -0400

> Michael, can you take my proposed changes and the text below and create 

I've made these changes plus the phone number changes plus the original
changes. If you go here: http://neonym.net/enum/ you can find the -07
document plus a diff between 06 and 07. I'll send it in once I get three
people to review it....

-MM

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Mon, 6 Oct 2003 18:57:29 +0100

>document plus a diff between 06 and 07. I'll send it in once I get three

Hi Michael, all,

Herewith my reading of the draft on your site.

Please could these be applied before it goes out?

-------------------------------------------------------------------

I knew there was a reason I prefer text...in the following, the line
numbers are the ones I got using VI on a CURL of the text file.
The ones labelled "o  " are pure typos. The others labelled "*  "
should really be changed.

I think that the references were mangled (and are still mangled).
Thus::
-  I believe that [6] rfc3402 (DDDS - Algorithm)
    should be a normative reference. One of the goals of this update
    is that ENUM uses the DDDS algorithm, so IMHO it's normative.

-  I'm not sure if the reference in SS2, sentence 1
    is to [6] (i.e. to RFC3402) or [1] (i.e. to RFC3403). This is
    shown in the following list as ??.

Many thanks for the change to Drama Numbers.
(No one need hear from Ted in the dead of night again :)
I've checked from inside the U.K. (both main wireline Operators)
and they all give NU.
Could someone check from outside the UK?

However::
-  The example in SS2.2 states that it takes the previous
    example, but doesn't. I'm assuming that it was meant to do this.

(Also, note that the "input" in S2.2 is an AUS, so there isn't any
punctuation, hence the dashes in the first number need to go).

--------------------
*   SS1.2 (para 1, sentence 3) on line 153 -
c/mechanisms/If these mechanisms/

??  S2 (para 1, sentence 1) on line 231 -
c/[1]/[6]/

*   S2 (para 1, sentence 2) on line 232 -
c/[2]/[1]/

*   S2.2 (para 2, sentence 1) on line 269 -
c/"+44-7700-900454"/"+441164960348"/

*   S2.2 (para 2, sentence 2) on line 271 -
c/"+447700900454"/"+441164960348"/

*   SS2.4 (para 1, sentence 2) on line 291 -
c/[2]/[1]/

o   S2.4.2.1 (para 1, sentence 4) on line 410 -
c/have/has/

o   SS3.1.3 (para 2, sentence 2) on line 524 -
c/associates/associated/

o   S5 (para 1, sentence 3) on line 736 -
c/.Names/. Names/

*   S5 (para 1, sentence 4) on line 739 -
c/should/should be/

*   S6.1 (para 4, sentence 2) on line 821 -
c/brut/brute/

--------------------
(Finally nit-on-a-nit-on-a-nit):
SS 4 (para 1, sentence 1) on line 678 -
c/which uses/that use/
--------------------

Those are all the typos I could find. Apart from that, it's fine, IMHO.
Good work.

all the best,
   Lawrence