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

From: Daryl Malas <[email-masked]>
Date: Wed, 04 Mar 2009 16:16:12 -0700

All,

We have submitted a new draft describing another method for incorporating
trunk group information in an ENUM response.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : Trunk Group Use in ENUM
    Author(s)       : D. Malas, T. Creighton
    Filename        : draft-malas-enum-trunk-sip-00.txt
    Pages           : 7
    Date            : 2009-03-04

This document concludes that incorporating trunk group parameters
into an Electronic Number (ENUM) response for the Session Initiation
Protocol (SIP) [RFC3261] service URI is a more effective approach
compared to defining a new ENUM service type for a 'trunk'.  Upon
further review of the existing ENUM trunk group draft
[I-D.ietf-enum-trunkgroup] and practical operator experience, this
draft recommends the use of the current trunk group contexts as
defined in [RFC4904] as additional parameters in the E2U+SIP
enumservice NAPTR record [RFC3403] URI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-enum-trunk-sip-00.txt

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 4 Mar 2009 19:28:55 -0500

To the list ..

FYI this draft essentially supersedes the previous draft that Tom Creighton
and I co authored earlier.

As far as I'm personally concerned this is still a legitimate WG item as it
describes, in another way , work we had already approved. It does have
significant applicability in the market today.

I have no issues with this proceeding as a ENUM WG document unless there are
objections.  We are close to closure but fast tracking this to WGLC could be
of help to operators looking at this type of function.

Comments? Any objections to a fast track?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daryl Malas
Sent: Wednesday, March 04, 2009 6:16 PM
To: [email-masked]
Cc: Tom Creighton
Subject: [Enum] New Draft: Trunk Group Use in ENUM

All,

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 5 Mar 2009 09:47:38 +0100 (CET)

Hi Rich

Why don't we use the new process as decribed in

   http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide

for Trunk Group? So, the document does not need to be WG item.
I believe it is not worth doing anything according to the old process at
this point in time.

cheers,
  Bernie

On Wed, 4 Mar 2009, Richard Shockey wrote:

> As far as I’m personally concerned this is still a legitimate WG item as it

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 5 Mar 2009 10:01:22 +0000

Hi Bernie, folks,
  Agreed.
If there is a crucial reason to force this through the IETF on the old  
track, then let's discuss this at the ENUM WG meeting :).
all the best,
   Lawrence

On 5 Mar 2009, at 08:47, Bernie Hoeneisen wrote:

> _______________________________________________
> enum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum

---

From: Don Troshynski <[email-masked]>
Date: Thu, 5 Mar 2009 09:53:58 -0500

I believe the point of the draft is that it defines the usage of Trunk Groups within SIP URIs without a unique service type.  Therefore no additional ENUM service is defined and the draft falls outside of the service registration process.  By comparing this method to a non-registered service type of e2u+trunk, it creates some confusion.  So, registration of the service type or removal of the reference might also be appropriate.

I think the draft is should be fast tracked as there is a need to document the use of trunk groups within ENUM.

One other more specific comment is that the document should define the treatment of the Trunk Group parameters within the ENUM client.  The options are:

a. Override the URI host and route based on embedded trunk group.
b. Route based on the URI host and forward the trunk group parameters downstream for further processing.
c. Define either behavior as acceptable or a matter of local policy.

Don

>-----Original Message-----
>Lawrence Conroy
>Sent: Thursday, March 05, 2009 5:01 AM
>To: Bernie Hoeneisen
>Cc: IETF ENUM list; 'Daryl Malas'; 'Tom Creighton'
>Subject: Re: [Enum] New Draft: Trunk Group Use in ENUM
>
>Hi Bernie, folks,
>  Agreed.

---

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

As Don said the purpose of this draft is to describe a method for trunkgroup
that does not require a new Enumservice type.... a BGP essentially. Which is
why I have no objection to a fast track.

However should someone want to have a E2U+SIP:TRUNK then yes the new
registration method could create that...if and when we can get the document
approved by the IESG this century.

>  From: Lawrence Conroy [mailto:[email-masked]]
>  Cc: Richard Shockey; IETF ENUM list; 'Daryl Malas'; 'Tom Creighton'

---

From: Daryl Malas <[email-masked]>
Date: Thu, 05 Mar 2009 10:30:40 -0700

Don,

Your assumption is correct.  We are not proposing a new service type.  This
draft suggests something quite to the contrary.  It proposes a method of
including trunk information without a new service type.  Based on this, I do
not think it falls within the scope of this process:
http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide

Regarding the treatment of the trunk group parameters within the ENUM
client, I think this would be a good addition to the draft and would like to
work with you further on some language when the working group decides how to
move forward.

Regards,

Daryl

On 3/5/09 7:53 AM, "Don Troshynski" <[email-masked]> wrote:

> I believe the point of the draft is that it defines the usage of Trunk Groups
> within SIP URIs without a unique service type.  Therefore no additional ENUM
> service is defined and the draft falls outside of the service registration
> process.  By comparing this method to a non-registered service type of
> e2u+trunk, it creates some confusion.  So, registration of the service type or
> removal of the reference might also be appropriate.
> 
> One other more specific comment is that the document should define the
> treatment of the Trunk Group parameters within the ENUM client.  The options
> are:
> 

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199