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

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

Thanks for your comments Peter ..comments in line.


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

Well as one of the original document editors here I had no issue with the
change of direction from a new Enumservice registration to a simpler BCP
describing the use of 4904 in an existing E2U+SIP context. My larger issue
here was that I did not want the usually dysfunctional IETF process issues
to get in the way of a perfectly sensible technical solution to a very real
problem and take the issue off the table and close the WG.

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

My basic point.

 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.

Why informational vs BCP.. the technical issue raised strikes be a more
appropriate for BCP.

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

The trunk group use draft will be re-written. 

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

Exactly. Which is really the issue here. Why register a new Enumservice for
"trunk" when there is considerable evidence that is not needed. Demonstrate
how to incorporate trunk group data in ENUM requests in a simple BCP.

My intention was to consult with the AD on this in SF but my basic proposal
would be to request WG consensus to drop the original 'trunk group
Enumservice registration draft' and use the new 'trunk group use in ENUM' as
the basis for the technical solution. 

The issue raised here is a real problem. We will assist service providers
greatly by pushing this along. If we don't do it will end up as a individual
draft and wander in the wilderness. I've polled the SPEERMINT WG chairs and
they agree it would be better if the ENUM WG deals with this. 


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