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

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

>  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