[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