Re: 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.
>  
>  -Peter
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www.ietf.org/mailman/listinfo/enum