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

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 06 Mar 2009 15:04:47 +0100

notes inline.

>>  - I'm not a big fan of accepting new work items in the ENUM working
>>  group.
> 
> A. this is not new work ..the original draft was an approved WG item. Its
> simply expired.
> 
> Shockey, R. and T. Creighton, "IANA Registration for an
>               Enumservice Trunkgroup", draft-ietf-enum-trunkgroup-00
>               (work in progress), July 2008.

I understood that very well. However, the new draft is not the same work 
- it's some operational experience why we don't need the original work. 
   Fine as well, but not the same work.

> Yes it's should be structured as a BCP. The idea is to actually document
> something that actually works vs waiting another year or whatever to try and
> create a new enum service. I personally had no objection to completely
> rewriting the existing 00 draft but the authors chose to submit a new draft.

I preferred to see it as a new draft anyway, because the subject of the 
draft changed quite a lot (from an Enumservice registration to an 
operational practice).

What i meant is that i don't think we'd need to accept it as a WG item 
*just* to reason dropping the "trunk" registration work.

Now if i hear people saying it contains important operational 
experience, *then* it's a different story.

Whether it should be done in SPEERMINT or ENUM is a different question.

> So you want to send this to SPEERMINT where again it will get lost in the
> shuffle?
> 
> Daryl, Jason ??  Do you want to do this?
>

Well, if it's about finding the path of least resistance, then the 
sedated ENUM WG might work well :)

[...]

> More stall and delay. I just don't see the point. Why do you want to get
> this draft bogged down in some IETF procedural issue?  Cant we just fix it
> and shut the WG down? This draft, again, has real and demonstrable
> applicability to internal SSP operator networks RIGHT NOW, unlike some RAI
> drafts I see floating around.

ok, ok, i'm convinced - i was just a bit reluctant to replace work that 
was expired anyway with new work. If it's the easiest way, the lets 
proceed it.

Alex

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 6 Mar 2009 14:22:03 +0000

Hi Folks,
  beware - *who* gets to decide if a WG draft is dead?
 From experience, some get vocally unhappy if the authors just state
(the bl**din' obvious) that the draft is pining for the fjords.
Thus shouldn't "the management" (Alex, Richard, Patrik) formally
raise the proposal that the existing expired draft is dead, if it
is?

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?

all the best,
   Lawrence

On 6 Mar 2009, at 14:04, Alexander Mayrhofer wrote:
> I understood that very well. However, the new draft is not the same  
> work - it's some operational experience why we don't need the  
> original work.   Fine as well, but not the same work.
>
> I preferred to see it as a new draft anyway, because the subject of  
> the draft changed quite a lot (from an Enumservice registration to  
> an operational practice).
>
> What i meant is that i don't think we'd need to accept it as a WG  
> item *just* to reason dropping the "trunk" registration work.
>
> ok, ok, i'm convinced - i was just a bit reluctant to replace work  
> that was expired anyway with new work. If it's the easiest way, the  
> lets proceed it.
>
> Alex
>
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum

---

From: Peter Koch <[email-masked]>
Date: Fri, 20 Mar 2009 12:51:59 +0100

Hi,

I have no expertise on the subject matter, but would like to share some
observations on process:

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

> 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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 20 Mar 2009 08:34:03 -0400

Thanks for your comments Peter ..comments in line.

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

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

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