[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
All,
After some thought, I think there is value in maneuvering this document toward a BCP. It will take some work -- in my opinion, the debate involving a draft service type should be removed. There is room to consider this a BCP because there exists the potential for different interpretations of the handling of trunk group information. Should such information be interpreted locally to the ENUM client or added to the RURI for downstream handling? Is this a matter of local policy?
Also consider that if application of the technique in actual networks is a litmus test, there is enough precedent out there to consider this a BCP.
Don
-----Original Message-----
From: Daryl Malas [mailto:d.malas at cablelabs.com]
Sent: Friday, May 15, 2009 1:14 PM
To: Richard Shockey; 'Alexander Mayrhofer'; enum at ietf.org; Don Troshynski
Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence
All,
I personally think it should be considered as a BCP. The main purpose is to
not simply "suggest" the use of the parameters in the SIP URI NAPTR, but
rather to say "it really, really should be done this way. In fact, if you
do not do it this way, then you will likely be out of compatibility with
most implementations." I think this is the best way to ensure industry
consistency. This being said, if there is consensus to push it forward as
Informational, it is better to be documented than not at all, in my opinion.
Don, you commented before on this draft, do you have a perspective on the
value of this draft moving forward relative to the discussion?
Regards,
Daryl
On 5/14/09 7:58 AM, "Richard Shockey" <richard at shockey.us> wrote:
>
>> 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.
>
> Well my original intent was to 'clear the queue' so to speak and I'm
> personally convinced this is an important draft to document. Its starting to
> deploy now. I apologize if I had to 'shake the tree' so to speak to get
> someone to finally answer the question on what to do.
>
>> 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.
>
> Its fine with me as well.
>
>>
>>> 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?
>
> IMHO it's a individual draft or a ENUM WG draft I would not suggest to the
> authors to go down the DISPATCH path. I currently have limited confidence in
> the way DISPATCH will operate until proven otherwise. I'm personally pretty
> disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats the
> difference except you have new chairs and not really new chairs at that.
>
>>
>>> 2) Do you agree to abandon the approach in draft-ietf-enum-
>> trunkgroup-00.txt?
>>
>> Yes
>
> As the co-author yes. As for Informational vs BCP I can live with
> informational but I'll let Daryl comment on that.
>
>>
>>> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better
>> start instead?
>>
>> Yes
>
> Yes Either would work but this malas 00 IMHO is a much simpler approach and
> would work equally as well. The document needs to be rewritten but that is a
> wordsmithing issue.
>
>>
>>> 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.
>
> Not going to happen. SPEERMINT wont take it and it the new RAI org is IMHO
> just a reshuffling of the deck chairs. Pick your ship.
>
> Its here or individual submission.
>
>
>>
>> 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.
>
> IMHO finishing the work here with a single document the right way to go.
> Lets clear the issue off the table. I don't like pushing off work to some
> other WG that we should have completed ourselves. That's not right. We
> agreed to do this in the first place, lets finish it.
>
>
>>
>> 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.
>
>
> Well it got caught is the process. It nothing new for WG's. You want bad
> process I can talk about my current discussions with the IAB over the
> liaison letter to SG2 over Infrastructure ENUM.
>
>>
>> Alex
>>
>> _______________________________________________
>> enum mailing list
>> enum at ietf.org
>> https://www.ietf.org/mailman/listinfo/enum
>
> _______________________________________________
> 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