Re: New Draft: Trunk Group Use in ENUM

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 protected]> 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.
> 
> 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-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> 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.
>> 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:
>> 
>>> 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:
>>> 
>>>> 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 protected] [mailto:[email protected]] On
>>>> Behalf Of
>>>> Daryl Malas
>>>> Sent: Wednesday, March 04, 2009 6:16 PM
>>>> To: [email protected]
>>>> Cc: Tom Creighton
>>>> Subject: [Enum] New Draft: Trunk Group Use in ENUM
>>>> 
>>>> 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 protected]
>>> _______________________________________________
>>> enum mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/enum
>> 
>> _______________________________________________
>> enum mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/enum


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