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

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

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.
>  >