Re: 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" <[email protected]> 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: [email protected] [mailto:[email protected]] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum


-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email protected]