Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence

[Lawrence Conroy <[e-mail]>]

Hi Richard, folks,
Maybe I wasn't clear in my March 3rd mail; IMHO, the original idea  
using a separate Enumservice is irrecoverable.
I join the crowd asking the WG chairs to declare it dead.

 From experience of Experiences in the IESG, this *new* item should be  
Informational, NOT BCP.
Customers can pull this out the final doc as a requirement regardless  
of its track.

I asked this in March, and I repeat - why isn't this a candidate for  
Individual or AD-sponsored?

all the best,
  Lawrence

On 13 May 2009, at 23:14, Richard Shockey wrote:
> No ..I wouldn't say that.
>
> This was always a very very specialized draft dealing with a very  
> particular
> type of PSTN data and its obvious the WG members are off to other  
> things.
>
> Of course some of us have had to deal with the Infrastructure ENUM  
> issues
> ..but that is another sad story. Yes the liaison is coming.
>
> IMHO silence on this is consent and my strong advise to you is to go  
> ahead
> and rewrite the document with all of the comments so far and submit  
> it as a
> WG document. The chairs will have to approve that we'll come back to  
> the
> list and see then if silence prevails we can kill the old draft and  
> we'll
> just see what happens then. If not then you will have my personal  
> support to
> submit it to the IESG as a individual submission.
>
>> -----Original Message-----
>> From: Daryl Malas [mailto:[e-mail]]
>> Sent: Tuesday, May 12, 2009 6:32 PM
>> To: Richard Shockey; 'IETF ENUM WG'
>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART -
>> Second request for guidence
>>
>> Richard,
>>
>> Well, I guess I will throw my hat in the ring.  As an author of the
>> proposed
>> draft, I think this is a valuable draft for the industry.  If I am  
>> the
>> only
>> one, then I guess the draft is irrelevant.
>>
>> Regards,
>>
>> Daryl
>>
>>
>> On 4/28/09 7:05 PM, "Richard Shockey" <[e-mail]> wrote:
>>
>>> Second call .. what is WG consensus here?
>>>
>>> This is not a silence is consent issue. It requires a form of
>> decision.
>>>
>>> (Chair hat off) I've made my personal sentiments clear. We all
>> thought this
>>> was a useful WG item. Some folks have come to us with a cleaner form
>> of
>>> dealing with the use case that does not require a formal enumservice
>>> registration. It has wide applicability. Better to create a BCP or
>>> Informational than let multiple implementations go off in all sorts
>> of non
>>> interoperable directions.
>>>
>>> What does the WG want to do or do you want the chairs to decide? We
>> are not
>>> going to have a meeting in Stockholm over this.
>>>
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>>>> Of Richard Shockey
>>>> Sent: Tuesday, April 21, 2009 2:29 PM
>>>> To: 'Peter Koch'; 'IETF ENUM WG'
>>>> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART
>>>>
>>>>
>>>> I'd like to take up where we left off on this subject and
>> determine
>>>> what the  WG consensus is on dealing with this issue.
>>>>
>>>> There is consensus that this is a item we had on the WG plate that
>> has
>>>> real applicability to applications in use and clarification on how
>> these
>>>> parameters should be represented in ENUM queries is a "good
>> thing".
>>>>
>>>> The first question is then do we essentially adopt this new draft
>> as a
>>>> WG item and quickly move it forward?
>>>>
>>>> The second is as what Informational or BCP?
>>>>
>>>>
>>>>> I have no expertise on the subject matter, but would like to
>> share
>>>>> some observations on process:
>>>>>
>>>>> On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote:
>>>>>
>>>>>> beware - *who* gets to decide if a WG draft is dead?
>>>>>
>>>>> usually that's a WG consensus, either explicitly or by lack of
>>>> motion
>>>>> as to
>>>>> be determined by the chairs.  In this case however, it seems that
>>>> the
>>>>> WG
>>>>> (or those in the WG who actively follow the matter) have changed
>>>> their
>>>>> mind
>>>>> about the direction of the draft.  Posting a new I-D was one way,
>>>> but
>>>>> if the
>>>>> WG consensus is that the solution proposed in
>>>>> "IANA Registration for an Enumservice Trunkgroup" is no longer
>> the
>>>>> right one
>>>>> and instead a parameter to the SIP URI, as proposed in Trunk
>> Group
>>>> Use
>>>>> in ENUM
>>>>> will do better, then WG consensus could just direct the editors
>> to
>>>> re-
>>>>> write
>>>>> accordingly.  Now, it seems that the editors change on the fly,
>>>> too,
>>>>> but that's
>>>>> up to the chairs (well, and any new editors) anyway.
>>>>>
>>>>>> Also, why is putting this new stuff in the clutches of a sleeping
>>>>>> WG (or an inchoate one) going to make it any faster getting any
>>>> BCP
>>>>>> through the IETF/IESG process? Does anyone remember IPTEL?
>>>>>
>>>>> I am a bit nervous about "fast tracking" in the last minute and
>> the
>>>>> status  of BCP.  The former seldomly works out, but the current
>>>> work item
>>>>> needs to get off the WG's plate anyway.  The latter doesn't seem
>>>> necessary,
>>>>> especially since we're about to re-classify all (or many of)
>> those
>>>>> Proposed Standards anyway.  A purely Informational document would
>>>> do, and
>>>> is
>>>>> definitely more lightweight.  The draft would be an Informational
>>>>> addendum to RFC 3764, which it needs to reference normatively.
>>>>>
>>>>> The draft itself, however, isn't really clear about the intended
>>>>> status
>>>>> "IANA Registration for an Enumservice Trunkgroup".  This document
>>>> is a
>>>>> normative
>>>>> reference although it seems to have outlived its usefulness and
>>>>> actually the
>>>>> registration in there is kind of revoked.
>>>>> However, the "trunk" ENUM service doesn't yet appear in
>>>>> <http://www.iana.org/assignments/enum-services> if my pattern
>>>> matching
>>>>> skills
>>>>> suffice.  So, instead of pursuing the old draft and immediately
>>>>> revoking the
>>>>> registration (or declaring it a no go), the new (well, "revised")
>>>>> draft
>>>>> should just state the new intended method of using trunk groups
>> in
>>>>> ENUM
>>>>> and incorporate verbatim the relevant parts of the earlier draft
>>>>> (without
>>>>> suggesting there actually _is_ a valid ENUM servcie registration)
>>>> in
>>>>> an
>>>>> appendix.
>>>>> It wouldn't be the first time an IETF WG started an effort to do
>>>> FOO
>>>>> and the
>>>>> document ends with the title "Why not to FOO".
>>>>>
>>>>> I'm not sure I follow the rationale in the first paragraph of
>>>> section
>>>>> 1.2,
>>>>> it feels like it's superseded by the newly born 5483 --
>>>>> congratulations, by
>>>>> the way.
>>>>>
>>>
>>> _______________________________________________
>>> enum mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/enum
>>
>>
>> -----------------
>> Daryl Malas
>> CableLabs
>> (o) [phone]
>> (f) [phone]
>> mailto:[e-mail]
>>
>
>
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/enum