Re: WG: New Draft: Trunk Group Use in ENUM

My (quick) 2c:

- I'm not a big fan of accepting new work items in the ENUM working group.

- This document does neither register nor modify nor delete a registered 
numservice. It's a mixture between arguments why we should stop working 
on something in progress plus operational recommendations on the *use* 
of some technology in the context of some SIP scenarios.

- As others mentioned, the Enumservice registration process is not 
appropriate for this document. However, the document recommends to drop 
some work that the ENUM WG has in progress.

(BTW, i can't find a single reference to the "trunk:" URI scheme that 
the draft mentions... Is that a new proposal, or a typo in the draft? 
The ENUM trunk group draft does not specify that URI scheme..)

- When i look at the SPEERMINT charter, the following paragraph fits the 
document quite well (Notice the word *trunking*):

"More specifically, SPEERMINT focuses on real-time session
routing architectures and their associated use cases.
Deliverables here include the specification of the various
types of application flows, such as signaling and media flows, in
such networks, and includes both trunking and peer-to-peer
flows."

Another thing that perfectly fits what is described in the documents is 
the SPEERMINT NAPTR use draft.

Granted, the use cases described might happen more within a SSPs network 
rather than between networks (unless SSPs are happy to expose their 
trunk group identifiers, which i doubt...)

(On the other hand, the item "3. The working group will continue examine 
and document various aspects of ENUM administrative and /or operational 
procedures irrespective of
whether e164.arpa domain is used." from the ENUM charter would probably 
work as well..)

- Therefore, i think that SPEERMINT / ENUM WGs should do the following:

a) Instead of "fast tracking" that document, the ENUM WG should rather 
agree whether or not they want to stop work on (and drop / expire) the 
existing trunk group draft (which was not too uncontroversial anyway). I 
don't think we need to accept that document as WG item to be able to 
decide that we stop work on the other item... if we accept that item as 
WG document, then we'd need to invest some effort into 
reviewing/clarifying etc work..

b) otoh, SPEERMINT is still active, and probably should discuss whether 
they want to either accept that draft as an additional WG item, or merge 
it's contents into the NAPTR Use draft..

comments?

Alex