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