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

["Richard Shockey" <[e-mail]>]

Chair hat off ..

>  Hi Don et al.
>  
>  IMHO it doesn't matter at this point in time whether it will be BCP or
>  informational at the end of the day.

Yes it is important Bernie. BCP has a greater weight than Informational the
burden of proof is very different. BCP clearly requires extensive community
review.

>  
>  The more important question is find a proper home for this work: I
>  propose this home to be SPEERMINT. 

NO .. Bernie you did not listen the SPEERMINT chairs do not want it there.
Its not in their charter.

This work, YMMV, is much closer to
>  the
>  SPEERMINT WG charter than to the ENUM WG charter. In case SPEERMINT
>  won't  take it, it's up to DISPATCH to decide on this.

NO again. Why do you want to kill this? The WG agreed to do it. I don't
understand this procedure argument at all. DISPATCH right now is a black
hole that no one understands how it will work. This is a perfectly simple
draft with a perfectly simple solution that needs to be clarified so people
can deploy it correctly.

IMHO the expertise is here in ENUM not in DISPATCH ..or SPEERMINT. 


>  
>  cheers,
>    Bernie
>  
>  
>  On Thu, 21 May 2009, Don Troshynski wrote:
>  
>  > 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:[e-mail]]
>  > Sent: Friday, May 15, 2009 1:14 PM
>  > To: Richard Shockey; 'Alexander Mayrhofer'; [e-mail]; 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" <[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]
>  >
>  >
>  > _______________________________________________
>  > enum mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/enum
>  >
>  _______________________________________________
>  enum mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/enum