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

Daryl Malas <d.malas@cablelabs.com> Thu, 05 March 2009 17:30 UTC

Return-Path: <D.Malas@cablelabs.com>
X-Original-To: enum@core3.amsl.com
Delivered-To: enum@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6713A6879 for <enum@core3.amsl.com>; Thu, 5 Mar 2009 09:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.23
X-Spam-Level:
X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIFNhZ1L8LAu for <enum@core3.amsl.com>; Thu, 5 Mar 2009 09:30:17 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 211A528C460 for <enum@ietf.org>; Thu, 5 Mar 2009 09:30:17 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n25HUeqS029971; Thu, 5 Mar 2009 10:30:40 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 5 Mar 2009 10:30:40 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
Received: from 10.4.10.99 ([10.4.10.99]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Mar 2009 17:30:40 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 05 Mar 2009 10:30:40 -0700
From: Daryl Malas <d.malas@cablelabs.com>
To: Don Troshynski <DTroshynski@acmepacket.com>, Tom Creighton <Tom_Creighton@cable.comcast.com>, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, Lawrence Conroy <lconroy@insensate.co.uk>
Message-ID: <C5D55A50.278E%d.malas@cablelabs.com>
Thread-Topic: [Enum] New Draft: Trunk Group Use in ENUM
Thread-Index: AcmdeVr4XUckGISyTI+YLdxLvpJNMQAJ13tAAAXYY5k=
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC314C46BD645@mail>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Approved: ondar
Cc: IETF ENUM list <enum@ietf.org>
Subject: Re: [Enum] New Draft: Trunk Group Use in ENUM
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 17:30:18 -0000

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" <DTroshynski@acmepacket.com> 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: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] 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: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On
>>>> Behalf Of
>>>> Daryl Malas
>>>> Sent: Wednesday, March 04, 2009 6:16 PM
>>>> To: enum@ietf.org
>>>> 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:d.malas@cablelabs.com
>>> _______________________________________________
>>> enum mailing list
>>> enum@ietf.org
>>> https://www.ietf.org/mailman/listinfo/enum
>> 
>> _______________________________________________
>> enum mailing list
>> enum@ietf.org
>> https://www.ietf.org/mailman/listinfo/enum


-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas@cablelabs.com