Re: 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