[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enum] 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