[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence
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:d.malas at cablelabs.com]
> 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" <richard at shockey.us> 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: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] 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
> > enum at ietf.org
> > https://www.ietf.org/mailman/listinfo/enum
>
>
> -----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> mailto:d.malas at cablelabs.com
>