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

["Richard Shockey" <[e-mail]>]

>  
>  Hi Richard, folks,
>    Maybe I wasn't clear in my March 3rd mail; IMHO, the original idea
>  using a separate Enumservice is irrecoverable.
>  I join the crowd asking the WG chairs to declare it dead.

OK ..its dead. Let me find the pearl handled revolver.

>  
>   From experience of Experiences in the IESG, this *new* item should be
>  Informational, NOT BCP.  Customers can pull this out the final doc as a
requirement regardless
>  of its track.

Ultimately I don't have a problem with Informational though technically I
think it falls under the sort of draft that is ultimately a  BCP but I don't
want to belabor the point. What is important is there is documentation on
this particular type of usage or operators and vendors will attempt to
implement all sorts of silly things.

>  
>  I asked this in March, and I repeat - why isn't this a candidate for
>  Individual or AD-sponsored?

Because it was a WG item to begin with and IMHO we should not, to use a US
colloquialism, be "buck-passers" as in the "buck stops here".






>  
>  all the best,
>     Lawrence
>  
>  On 13 May 2009, at 23:14, Richard Shockey wrote:
>  > No ..I wouldn't say that.
>  >
>  > This was always a very very specialized draft dealing with a very
>  > particular
>  > type of PSTN data and its obvious the WG members are off to other
>  > things.
>  >
>  > Of course some of us have had to deal with the Infrastructure ENUM
>  > issues
>  > ..but that is another sad story. Yes the liaison is coming.
>  >
>  > IMHO silence on this is consent and my strong advise to you is to go
>  > ahead
>  > and rewrite the document with all of the comments so far and submit
>  > it as a
>  > WG document. The chairs will have to approve that we'll come back to
>  > the
>  > list and see then if silence prevails we can kill the old draft and
>  > we'll
>  > just see what happens then. If not then you will have my personal
>  > support to
>  > submit it to the IESG as a individual submission.
>  >
>  >> -----Original Message-----
>  >> From: Daryl Malas [mailto:[e-mail]]
>  >> 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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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
>  >>> [e-mail]
>  >>> https://www.ietf.org/mailman/listinfo/enum
>  >>
>  >>
>  >> -----------------
>  >> Daryl Malas
>  >> CableLabs
>  >> (o) [phone]
>  >> (f) [phone]
>  >> mailto:[e-mail]
>  >>
>  >
>  >
>  > _______________________________________________
>  > enum mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/enum