Re: WG: New Draft: Trunk Group Use in ENUM

Hi,

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