Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence

[Daryl Malas <[e-mail]>]

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" <[e-mail]> wrote:

> 
>>  To: [e-mail]
>>  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
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/enum


-----------------
Daryl Malas
CableLabs
(o) [phone]
(f) [phone]
mailto:[e-mail]