Re: [Enum] WG: New Draft: Trunk Group Use in ENUM

["Richard Shockey" <richard at shockey.us>]

>  My (quick) 2c:
>  
>  - I'm not a big fan of accepting new work items in the ENUM working
>  group.

A. this is not new work ..the original draft was an approved WG item. Its
simply expired.

Shockey, R. and T. Creighton, "IANA Registration for an
              Enumservice Trunkgroup", draft-ietf-enum-trunkgroup-00
              (work in progress), July 2008.

>  
>  - 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.

Yes it's should be structured as a BCP. The idea is to actually document
something that actually works vs waiting another year or whatever to try and
create a new enum service. I personally had no objection to completely
rewriting the existing 00 draft but the authors chose to submit a new draft.

>  
>  - 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."

So you want to send this to SPEERMINT where again it will get lost in the
shuffle?

Daryl, Jason ??  Do you want to do this?


Cant we in the IETF actually DO something?  This was the last piece of ENUM
work that got left by the wayside.

I know we should be shutting down the ENUM WG but this is IMHO pretty
simple, it's a real application that has immediate use in operators network.
Its not complicated and IMHO a successor draft should eliminate the
discussion of :trunk and focus specifically on the BCP of [RFC4904] within
the existing context of the E2U+SIP enumservice NAPTR record [RFC3403] URI. 

The point of this draft IMHO is that you don't need a new Enumservice to
accomplish the requirement. That is a good thing. Why should internal SSP
network elements parse through a specific "trunk" NAPTR record when it can
simply look for E2U+SIP and execute accordingly. 

>  
>  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...)

IMHO the authors should have been more explicit in describing the use case
that exposure of this data is typically only within a SSP network. NO TCAP.


>  
>  (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..


Again rewrite this into the existing trunkgroup expired draft? Fine .. send
it to SPEERMINT? No thank you.

>  
>  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?


More stall and delay. I just don't see the point. Why do you want to get
this draft bogged down in some IETF procedural issue?  Cant we just fix it
and shut the WG down? This draft, again, has real and demonstrable
applicability to internal SSP operator networks RIGHT NOW, unlike some RAI
drafts I see floating around.

In any event this would require some review by the AD's so given the
transition we'll have to check with them. 


>  
>  Alex
>  _______________________________________________
>  enum mailing list
>  enum at ietf.org
>  https://www.ietf.org/mailman/listinfo/enum