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

[Lawrence Conroy <lconroy at insensate.co.uk>]

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:
> 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
>
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum