headers
Stastny Richard | 1 Oct 2003 10:09
Picon

RE: I'm looking for ideas on the Agenda for Minneapolis

Hi folks,

being relatively new to IETF and not knowing the inner procedures
of IETF and IAB well enough, a status report of the IDs in the queue
would be
nice, eventually by one of the responsible area directors.

I would be interested eg in getting answers to questions like:
Why is rfc2916bis not released yet as RFC?
What is the problem, if any?
How can it be solved?
When is the release planned?

From my working in other not so advanced bodies I am used to get
milestones for release dates and reasons if a date is shifted, not
the other way round (no dates and no reasons), but as I said above:
I am new here.

So maybe you could set aside 5 minutes?

Richard

> -----Original Message-----
> From: Richard Shockey [mailto:richard <at> shockey.us] 
> Sent: Monday, September 29, 2003 4:20 PM
> To: enum <at> ietf.org
> Subject: [Enum] I'm looking for ideas on the Agenda for Minneapolis..
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrik Fältström | 3 Oct 2003 15:33
Picon
Favicon

Re: refresh: IESG review of rfc2916bis

Suggested RFC-Editor notes, which if ok should make it possible to have 
2916bis become an RFC.

       paf

> Ted Hardie's Discuss comments:
>
> I went back forth as to whether these were serious nits
> or a mild discuss.  The tired lady mentioned in the nit
> related to section 2.1 was the deciding factor.  In other
> words, I think these should be fixed, but pushback is
> welcome.
>
>
> In the introduction:
>
>     "like delegation through NS records and NAPTR records, one can 
> look up
>     what services are available for a specific domain name"
>
> Would it not make more sense to say, "what services are associated 
> with a
> specific E.164 number"?  This is not general to all domain names.

Comment: I think it is ok to make this change. The reason it talks 
about domain names in the second part of this very long sentence is 
because ENUM really is a two-step process. But, of course the whole 
algorithm doesn't work if the input is an E.164 number.

[1] In the introduction:
(Continue reading)

Permalink | Reply | 18 comments |
headers
Michael Mealling | 3 Oct 2003 15:51

Re: refresh: IESG review of rfc2916bis

On Fri, 2003-10-03 at 09:33, Patrik Fältström wrote:
> Suggested RFC-Editor notes, which if ok should make it possible to have 
> 2916bis become an RFC.

I've looked these over and see no problems with any of the changes from
my end. Do you want to incorporate them and submit the new version?

-MM

> > Ted Hardie's Discuss comments:
> >
> > I went back forth as to whether these were serious nits
> > or a mild discuss.  The tired lady mentioned in the nit
> > related to section 2.1 was the deciding factor.  In other
> > words, I think these should be fixed, but pushback is
> > welcome.
> >
> >
> > In the introduction:
> >
> >     "like delegation through NS records and NAPTR records, one can 
> > look up
> >     what services are available for a specific domain name"
> >
> > Would it not make more sense to say, "what services are associated 
> > with a
> > specific E.164 number"?  This is not general to all domain names.
> 
> Comment: I think it is ok to make this change. The reason it talks 
> about domain names in the second part of this very long sentence is
(Continue reading)

Permalink | Reply | 14 comments |
headers
Patrik Fältström | 3 Oct 2003 17:00
Picon
Favicon

Re: refresh: IESG review of rfc2916bis

On 2003-okt-03, at 15:51, Michael Mealling wrote:

> On Fri, 2003-10-03 at 09:33, Patrik Fältström wrote:
>> Suggested RFC-Editor notes, which if ok should make it possible to 
>> have
>> 2916bis become an RFC.
>
> I've looked these over and see no problems with any of the changes from
> my end. Do you want to incorporate them and submit the new version?

I wrote them as RFC-Editor notes. I feel it is up to the AD whether 
they take them as RFC-Editor notes, or if they want a new version of 
the I-D.

     paf

>
> -MM
>
>>> Ted Hardie's Discuss comments:
>>>
>>> I went back forth as to whether these were serious nits
>>> or a mild discuss.  The tired lady mentioned in the nit
>>> related to section 2.1 was the deciding factor.  In other
>>> words, I think these should be fixed, but pushback is
>>> welcome.
>>>
>>>
>>> In the introduction:
>>>
(Continue reading)

Permalink | Reply | 13 comments |
headers
Richard Shockey | 3 Oct 2003 22:14
Picon

Re: Re: refresh: IESG review of rfc2916bis

At 11:00 AM 10/3/2003, Patrik Fältström wrote:

>On 2003-okt-03, at 15:51, Michael Mealling wrote:
>
>>On Fri, 2003-10-03 at 09:33, Patrik Fältström wrote:
>>>Suggested RFC-Editor notes, which if ok should make it possible to have
>>>2916bis become an RFC.
>>
>>I've looked these over and see no problems with any of the changes from
>>my end. Do you want to incorporate them and submit the new version?
>
>I wrote them as RFC-Editor notes. I feel it is up to the AD whether they 
>take them as RFC-Editor notes, or if they want a new version of the I-D.
>
>     paf
>

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.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrik Fältström | 3 Oct 2003 23:55
Picon
Favicon

Re: Re: refresh: IESG review of rfc2916bis


On 2003-okt-03, at 22:14, Richard Shockey wrote:

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

The diff was on version -06. I don't have it in front of me now, and I 
need to go to sleep. The clock is almost midnight here in Sweden.

I will have a look tomorrow, if noone else has looked before that.

    paf
Permalink | Reply | 0 comments |
headers
Peterson, Jon | 5 Oct 2003 04:20
Favicon

RE: Re: refresh: IESG review of rfc2916bis


> 
> 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.
Permalink | Reply | 9 comments |
headers
Conroy, Lawrence (SMTP | 5 Oct 2003 12:20
Picon

RE: Re: refresh: IESG review of rfc2916bis

At 9:20 pm -0500 4/10/03, Peterson, Jon wrote:
>  >
>>  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).
>

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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Patrik Fältström | 5 Oct 2003 12:26
Picon
Favicon

Re: Re: refresh: IESG review of rfc2916bis

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:

> At 9:20 pm -0500 4/10/03, Peterson, Jon wrote:
>>  >
>>>  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).
>>
>
> Hi folks,
>   (BCP is not standards track :).
> Many thanks to Jon for the reminder - someone with a memory.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Conroy, Lawrence (SMTP | 5 Oct 2003 12:58
Picon

Re: Re: refresh: IESG review of rfc2916bis

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.
>
>Can one of you do that please?
>
>    paf
>

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
(Continue reading)

Permalink | Reply | 6 comments |

Gmane