Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART

["Richard Shockey" <richard at shockey.us>]

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
>  enum at ietf.org
>  https://www.ietf.org/mailman/listinfo/enum