[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