-----Original Message-----
From: Daryl Malas [mailto:d.malas at cablelabs.com]
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" <richard at shockey.us> 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: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] 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
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum
-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com