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

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 05 Mar 2009 16:39:41 +0100

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

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 5 Mar 2009 12:29:48 -0500

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

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.

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

>  such networks, and includes both trunking and peer-to-peer

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.

>  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
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/enum

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 05 Mar 2009 14:31:26 -0500

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

Daryl is a co-author, so I can comment.  I'm willing to consider it but only
if the ENUM WG chairs feel strongly that this should come over to us.  If
you guys can process it rapidly, and feel it is within your scope, then go
for it.  If you are not sure it is totally in-scope and you expect to shut
down soon so that you cannot move the document ahead, then we could fit this
in as an "implementer-specific" document.  That's a long way of saying we
can help if you like, but it's really up to you and Patrik.  :-)

> it to SPEERMINT? No thank you.

If you can address it rapidly here in ENUM, you should, IMHO.

Jason

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 5 Mar 2009 15:00:18 -0500

>  
>  Daryl is a co-author, so I can comment.  I'm willing to consider it
>  but only  if the ENUM WG chairs feel strongly that this should come over
to us.
>  If  you guys can process it rapidly, and feel it is within your scope,
>  then go  for it.  If you are not sure it is totally in-scope and you
expect to
>  shut down soon so that you cannot move the document ahead, then we could
>  fit this  in as an "implementer-specific" document.  That's a long way of
saying
>  we  can help if you like, but it's really up to you and Patrik.  :-)
>  

Well thanks for your prompt response. 

I just did not want to see what is a pretty simple BCP that solves a real
internal SSP problem that defines no new protocol specification, distract
from ongoing progress in SPEERMINT.