[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence
Well at least I got someone on the list to finally comment .. :-)
Its not going into DISPATCH .it will never see the light of day.
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf
> Of Alexander Mayrhofer
> Sent: Thursday, May 14, 2009 4:35 AM
> To: enum at ietf.org
> Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART -
> Secondrequest for guidence
>
>
> Richard, fellow WG members,
>
> I agree with Peter, as i think the real question is whether the WG
> want
> to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not.
>
> The question whether the group wants to adopt the
> draft-malas-enum-trunk-sip is seperate from that - but i like the way
> that Peter proposed.
>
> > 1) Is anybody but the authors/editors of the respective drafts
> believes the WG
> > should say anything in this direction (trunk groups). [But see
> the "price tag"
> > under (4)]
>
> I think it is somehow *related* to ENUM because of the Enumservice
> that
> we are trying to get rid. Otherwise, i don't see why it would fit into
> ENUM. For example, it might well fit into DISPATCH as well?
>
> > 2) Do you agree to abandon the approach in draft-ietf-enum-
> trunkgroup-00.txt?
>
> Yes
>
> > 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better
> start instead?
>
> Yes
>
> > 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt?
>
> If it becomes an ENUM WG document, i might have to, being the
> secretary
> of the ENUM WG.
>
> > Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum-
> trunkgroup-01.txt,
> > changing the intended state to Informational.
>
> I would prefer if the WG concensus would be to remove
> draft-ietf-enum-trunkgroup from the WG "menu" entirely, and
> documenting
> the decision in draft-malas-enum-trunk-sip, but find a WG that suits
> better such SIP operational issues than the ENUM group.
>
> The solution that Peter proposed is also viable, if authors and chairs
> believe that's a faster way. I just don't think the WG should accept
> new
> work, given it's current status of being slowly move to the pathology
> department.
>
> Just to make clear: Content-wise, i definitely prefer the solution
> proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy
> with
> the sloppy process.
>
> Alex
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum