From rfc-editor@rfc-editor.org Tue Mar 3 16:04:10 2009 Return-Path: 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 35EAE28C2CA; Tue, 3 Mar 2009 16:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.122 X-Spam-Level: X-Spam-Status: No, score=-17.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 0Riozydi7qVC; Tue, 3 Mar 2009 16:04:09 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id A609128C2BB; Tue, 3 Mar 2009 16:02:43 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 2128F23D29A; Tue, 3 Mar 2009 16:01:49 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090304000149.2128F23D29A@bosco.isi.edu> Date: Tue, 3 Mar 2009 16:01:49 -0800 (PST) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5483 on ENUM Implementation Issues and Experiences X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:04:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5483 Title: ENUM Implementation Issues and Experiences Author: L. Conroy, K. Fujiwara Status: Informational Date: March 2009 Mailbox: lconroy@insensate.co.uk, fujiwara@jprs.co.jp Pages: 30 Characters: 72780 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-experiences-11.txt URL: http://www.rfc-editor.org/rfc/rfc5483.txt This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. This memo provides information for the Internet community. This document is a product of the Telephone Number Mapping Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From D.Malas@cablelabs.com Wed Mar 4 15:15:41 2009 Return-Path: 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 9964F28C330 for ; Wed, 4 Mar 2009 15:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 8OeEDOURG7xJ for ; Wed, 4 Mar 2009 15:15:40 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A927C28C30F for ; Wed, 4 Mar 2009 15:15:40 -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 n24NG5C2001089; Wed, 4 Mar 2009 16:16:06 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 4 Mar 2009 16:16:06 -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 ; Wed, 4 Mar 2009 23:16:05 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 04 Mar 2009 16:16:12 -0700 From: Daryl Malas To: Message-ID: Thread-Topic: [Enum] New Draft: Trunk Group Use in ENUM Thread-Index: AcmdHzVExhWudUQAA0iPM4Ov8Nc1iw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319028172_9328808" X-Approved: ondar Cc: Tom Creighton Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:15:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319028172_9328808 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 --B_3319028172_9328808 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable [Enum] New Draft: Trunk Group Use in ENUM All,

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

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

    Title        &nb= sp;  : Trunk Group Use in ENUM
    Author(s)       : D. = Malas, T. Creighton
    Filename        = : draft-malas-enum-trunk-sip-00.txt
    Pages        &nb= sp;  : 7
    Date        &nbs= p;   : 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.ma= las@cablelabs.com

 --B_3319028172_9328808-- From richard@shockey.us Wed Mar 4 16:30:59 2009 Return-Path: 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 DDD6E28C361 for ; Wed, 4 Mar 2009 16:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 hotE0zaz+npt for ; Wed, 4 Mar 2009 16:30:55 -0800 (PST) Received: from outbound-mail-315.bluehost.com (outbound-mail-315.bluehost.com [67.222.54.8]) by core3.amsl.com (Postfix) with SMTP id 3197728C36F for ; Wed, 4 Mar 2009 16:30:51 -0800 (PST) Received: (qmail 9353 invoked by uid 0); 5 Mar 2009 00:24:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 5 Mar 2009 00:24:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=F1dKJTBYvcQEMBhPGI+6DS5w+tLg4FRLCfiGB+w2oZZm/2qALxYpO7m367/dUdp/hX9kqUTSz4YZ+zI6FPUV43MZg/a75x5WfCcyxxlsDJI4KbS4pfwXJO0jVIpt+Edh; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lf1SM-0007Zq-Lr; Wed, 04 Mar 2009 17:28:59 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , References: In-Reply-To: Date: Wed, 4 Mar 2009 19:28:55 -0500 Message-ID: <046f01c99d29$5f228e90$1d67abb0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0470_01C99CFF.764C8690" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdHzVExhWudUQAA0iPM4Ov8Nc1iwACTzxQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'Tom Creighton' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:31:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0470_01C99CFF.764C8690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0470_01C99CFF.764C8690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Enum] New Draft: Trunk Group Use in ENUM

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.t= xt


Regards,

Daryl

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

------=_NextPart_000_0470_01C99CFF.764C8690-- From bernie@ietf.hoeneisen.ch Thu Mar 5 00:47:13 2009 Return-Path: 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 D7C9328C1AF for ; Thu, 5 Mar 2009 00:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 fcbZFZpJh-Rf for ; Thu, 5 Mar 2009 00:47:13 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id D78B928C19F for ; Thu, 5 Mar 2009 00:47:12 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Lf9Ew-00082Y-PH; Thu, 05 Mar 2009 09:47:38 +0100 Date: Thu, 5 Mar 2009 09:47:38 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <046f01c99d29$5f228e90$1d67abb0$@us> Message-ID: References: <046f01c99d29$5f228e90$1d67abb0$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-692550625-1236242858=:30758" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list , 'Daryl Malas' , 'Tom Creighton' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:47:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-692550625-1236242858=:30758 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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: >=20 > To the list .. >=20 > =A0 >=20 > FYI this draft essentially supersedes the previous draft that Tom Creight= on > and I co authored earlier. >=20 > =A0 >=20 > As far as I=A2m personally concerned this is still a legitimate WG item a= s it > describes, in another way , work we had already approved. It does have > significant applicability in the market today. >=20 > =A0 >=20 > I have no issues with this proceeding as a ENUM WG document unless there = are > objections.=A0 We are close to closure but fast tracking this to WGLC cou= ld be > of help to operators looking at this type of function. >=20 > =A0 >=20 > Comments? Any objections to a fast track? >=20 > =A0 >=20 > 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 >=20 > =A0 >=20 > All, >=20 > We have submitted a new draft describing another method for incorporating > trunk group information in an ENUM response. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > =A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Trunk Group Use in ENUM > =A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0: D. Malas, T. Creighton > =A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0=A0: draft-malas-enum-trunk-sip-00= =2Etxt > =A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 7 > =A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2009-03-04 >=20 > 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'. =A0Upon > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-malas-enum-trunk-sip-00.txt >=20 >=20 > Regards, >=20 > Daryl >=20 > ----------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com >=20 >=20 > --37663318-692550625-1236242858=:30758-- From lconroy@insensate.co.uk Thu Mar 5 02:00:57 2009 Return-Path: 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 391F028C37E for ; Thu, 5 Mar 2009 02:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 x-O05PMIaTJa for ; Thu, 5 Mar 2009 02:00:56 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id 0FCD228C37B for ; Thu, 5 Mar 2009 02:00:55 -0800 (PST) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8EA31FDCAD; Thu, 5 Mar 2009 10:01:21 +0000 (GMT) Message-Id: <95CBE4B6-A8B4-4348-A545-F02F658A4D9E@insensate.co.uk> From: Lawrence Conroy To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Mar 2009 10:01:22 +0000 References: <046f01c99d29$5f228e90$1d67abb0$@us> X-Mailer: Apple Mail (2.930.3) Cc: IETF ENUM list , 'Daryl Malas' , 'Tom Creighton' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:00:57 -0000 Hi Bernie, folks, Agreed. If there is a crucial reason to force this through the IETF on the old =20= 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 =20 > 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 =20 >> Creighton >> and I co authored earlier. >> >> As far as I=92m personally concerned this is still a legitimate WG =20= >> item as it >> describes, in another way , work we had already approved. It does =20 >> have >> significant applicability in the market today. >> >> I have no issues with this proceeding as a ENUM WG document unless =20= >> there are >> objections. We are close to closure but fast tracking this to WGLC =20= >> 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 =20 >> 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 =20 >> 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 From DTroshynski@acmepacket.com Thu Mar 5 06:54:09 2009 Return-Path: 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 14AA33A67FB for ; Thu, 5 Mar 2009 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 EOmcBnMQtmXK for ; Thu, 5 Mar 2009 06:54:08 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EB1003A67F5 for ; Thu, 5 Mar 2009 06:54:07 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 09:54:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 09:54:36 -0500 From: Don Troshynski To: 'Daryl Malas' , 'Tom Creighton' , Bernie Hoeneisen , Lawrence Conroy Date: Thu, 5 Mar 2009 09:53:58 -0500 Thread-Topic: [Enum] New Draft: Trunk Group Use in ENUM Thread-Index: AcmdeVr4XUckGISyTI+YLdxLvpJNMQAJ13tA Message-ID: References: <046f01c99d29$5f228e90$1d67abb0$@us> <95CBE4B6-A8B4-4348-A545-F02F658A4D9E@insensate.co.uk> In-Reply-To: <95CBE4B6-A8B4-4348-A545-F02F658A4D9E@insensate.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF ENUM list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:54:09 -0000 I believe the point of the draft is that it defines the usage of Trunk Grou= ps within SIP URIs without a unique service type. Therefore no additional = ENUM service is defined and the draft falls outside of the service registra= tion process. By comparing this method to a non-registered service type of= e2u+trunk, it creates some confusion. So, registration of the service typ= e 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 trea= tment of the Trunk Group parameters within the ENUM client. The options ar= e: 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 downs= tream 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 From root@core3.amsl.com Thu Mar 5 07:15:01 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 714173A6941; Thu, 5 Mar 2009 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090305151501.714173A6941@core3.amsl.com> Date: Thu, 5 Mar 2009 07:15:01 -0800 (PST) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-combined-09.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, et al. Filename : draft-ietf-enum-combined-09.txt Pages : 11 Date : 2009-03-05 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after approval and implementation of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-enum-combined-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-05071440.I-D@ietf.org> --NextPart-- From richard@shockey.us Thu Mar 5 07:17:53 2009 Return-Path: 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 E49523A6809 for ; Thu, 5 Mar 2009 07:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Q9H9RXrXvUkb for ; Thu, 5 Mar 2009 07:17:52 -0800 (PST) Received: from outbound-mail-148.bluehost.com (outbound-mail-148.bluehost.com [67.222.38.38]) by core3.amsl.com (Postfix) with SMTP id 784733A6899 for ; Thu, 5 Mar 2009 07:17:39 -0800 (PST) Received: (qmail 4374 invoked by uid 0); 5 Mar 2009 15:15:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 5 Mar 2009 15:15:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Content-language:Thread-Index:X-Identified-User; b=oSP/sIa0/SixW+xF38c09SeMuL9CYDZHcvUz3+uYA9yz1VHDgbpbHh5icbf5FZ9ObcZ5hQL04NvMVFNXmh9I1ZIUUV/IzQuN84Y25HTmrkGk+Xmv41kDoZY5tWHwV+Kh; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LfFKq-00007k-Ba; Thu, 05 Mar 2009 08:18:08 -0700 From: "Richard Shockey" To: "'Lawrence Conroy'" , "'Bernie Hoeneisen'" References: <046f01c99d29$5f228e90$1d67abb0$@us> <95CBE4B6-A8B4-4348-A545-F02F658A4D9E@insensate.co.uk> In-Reply-To: <95CBE4B6-A8B4-4348-A545-F02F658A4D9E@insensate.co.uk> Date: Thu, 5 Mar 2009 10:18:03 -0500 Message-ID: <012301c99da5$958ab530$c0a01f90$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AcmdeVdqaWCC33t8TaKYHrkXaOO4BAAK9Y3g X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'IETF ENUM list' , 'Daryl Malas' , 'Tom Creighton' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:17:54 -0000 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. > -----Original Message----- > From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Sent: Thursday, March 05, 2009 5:01 AM > To: Bernie Hoeneisen > Cc: Richard Shockey; 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 From alexander.mayrhofer@enum.at Thu Mar 5 07:39:29 2009 Return-Path: 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 890393A69E4 for ; Thu, 5 Mar 2009 07:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 njA5fjFrF2xh for ; Thu, 5 Mar 2009 07:39:27 -0800 (PST) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id 65BEA3A69C2 for ; Thu, 5 Mar 2009 07:39:26 -0800 (PST) Received: from [10.10.0.119] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 05 Mar 2009 16:39:52 +0100 id 0006C006.49AFF248.00002808 Message-ID: <49AFF23D.8040900@enum.at> Date: Thu, 05 Mar 2009 16:39:41 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: enum@ietf.org References: <8BC845943058D844ABFC73D2220D4665080715C8@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D4665080715C8@nics-mail.sbg.nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:39:29 -0000 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.us Thu Mar 5 09:29:52 2009 Return-Path: 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 ECEEE28C4E7 for ; Thu, 5 Mar 2009 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Ex1YxguK7T0K for ; Thu, 5 Mar 2009 09:29:51 -0800 (PST) Received: from outbound-mail-149.bluehost.com (outbound-mail-149.bluehost.com [67.222.38.39]) by core3.amsl.com (Postfix) with SMTP id 19AD928C4E9 for ; Thu, 5 Mar 2009 09:29:48 -0800 (PST) Received: (qmail 5946 invoked by uid 0); 5 Mar 2009 17:27:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 5 Mar 2009 17:27:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Content-language:Thread-Index:X-Identified-User; b=ScAhuj3lvq8N301so0QB8REJcO2YEKdlkIAVX5Nze7hE4wYlMPg8PCkzl6QAuWSjfJ8LotHPW4sVsbVJ6KB0D9CCRGF4mbF1Vur4G0yOz0rYPvDQJ0boIKGa7x1J2PAj; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LfHOK-00087p-Mw; Thu, 05 Mar 2009 10:29:53 -0700 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , References: <8BC845943058D844ABFC73D2220D4665080715C8@nics-mail.sbg.nic.at> <49AFF23D.8040900@enum.at> In-Reply-To: <49AFF23D.8040900@enum.at> Date: Thu, 5 Mar 2009 12:29:48 -0500 Message-ID: <019a01c99db7$fcb3af20$f61b0d60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AcmdqKSyFeytDZyJSCe9AqWZ4mPb7gAC63lw X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'Daryl Malas' , "'Livingood, Jason'" Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:29:53 -0000 > 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@ietf.org > https://www.ietf.org/mailman/listinfo/enum From D.Malas@cablelabs.com Thu Mar 5 09:30:18 2009 Return-Path: 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 ; 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 ; 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 ; 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 To: Don Troshynski , Tom Creighton , Bernie Hoeneisen , Lawrence Conroy Message-ID: Thread-Topic: [Enum] New Draft: Trunk Group Use in ENUM Thread-Index: AcmdeVr4XUckGISyTI+YLdxLvpJNMQAJ13tAAAXYY5k= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Cc: IETF ENUM list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 From jason_livingood@cable.comcast.com Thu Mar 5 11:32:01 2009 Return-Path: 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 D00DA28C11A for ; Thu, 5 Mar 2009 11:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[AWL=-1.344, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] 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 ZUd8XFwp28Rf for ; Thu, 5 Mar 2009 11:32:01 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C89B328C0DD for ; Thu, 5 Mar 2009 11:32:00 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.57557961; Thu, 05 Mar 2009 14:32:16 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 14:32:15 -0500 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Mar 2009 19:31:26 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Mar 2009 14:31:26 -0500 From: "Livingood, Jason" To: Richard Shockey , Alexander Mayrhofer , Message-ID: Thread-Topic: [Enum] WG: New Draft: Trunk Group Use in ENUM Thread-Index: AcmdqKSyFeytDZyJSCe9AqWZ4mPb7gAC63lwAAUps8g= In-Reply-To: <019a01c99db7$fcb3af20$f61b0d60$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2009 19:32:15.0273 (UTC) FILETIME=[16C47190:01C99DC9] Cc: Daryl Malas Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:32:01 -0000 >> "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? 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. :-) > Again rewrite this into the existing trunkgroup expired draft? Fine .. send > it to SPEERMINT? No thank you. If you can address it rapidly here in ENUM, you should, IMHO. Jason From richard@shockey.us Thu Mar 5 11:59:55 2009 Return-Path: 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 E81F13A6B6F for ; Thu, 5 Mar 2009 11:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 IWGk2VGhipzH for ; Thu, 5 Mar 2009 11:59:55 -0800 (PST) Received: from outbound-mail-304.bluehost.com (outbound-mail-304.bluehost.com [67.222.53.250]) by core3.amsl.com (Postfix) with SMTP id 029D03A6836 for ; Thu, 5 Mar 2009 11:59:54 -0800 (PST) Received: (qmail 20459 invoked by uid 0); 5 Mar 2009 19:55:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy6.bluehost.com with SMTP; 5 Mar 2009 19:55:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-language:X-Identified-User; b=Z239FCvMje5KevpCYYYTjf6QZ37Ysfl0JF5vDEhePeBbl/kDxo4vNrJa/z9q0JIVnIiziBJTRPUSbu8Wmu7rOEzMmWncR/9Si33WXBUdaMu6QLSTUvfcFSftcoNpnLTU; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LfJjz-0006Zd-Ik; Thu, 05 Mar 2009 13:00:23 -0700 From: "Richard Shockey" To: "'Livingood, Jason'" , "'Alexander Mayrhofer'" , References: <019a01c99db7$fcb3af20$f61b0d60$@us> In-Reply-To: Date: Thu, 5 Mar 2009 15:00:18 -0500 Message-ID: <005501c99dcd$035701a0$0a0504e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdqKSyFeytDZyJSCe9AqWZ4mPb7gAC63lwAAUps8gAAORvMA== Content-language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Cc: 'Daryl Malas' Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:59:56 -0000 > > 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. :-) > > > Again rewrite this into the existing trunkgroup expired draft? Fine > .. send > > it to SPEERMINT? No thank you. > > If you can address it rapidly here in ENUM, you should, IMHO. 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. From alexander.mayrhofer@enum.at Fri Mar 6 06:04:30 2009 Return-Path: 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 243DD3A6B65 for ; Fri, 6 Mar 2009 06:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Xb3csei9lNKU for ; Fri, 6 Mar 2009 06:04:29 -0800 (PST) Received: from kahua.nona.net (pahula.nona.net [193.80.224.123]) by core3.amsl.com (Postfix) with ESMTP id 2780E3A6B5A for ; Fri, 6 Mar 2009 06:04:28 -0800 (PST) Received: from [10.10.0.119] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 06 Mar 2009 15:04:56 +0100 id 0006C009.49B12D88.00006A10 Message-ID: <49B12D7F.4010706@enum.at> Date: Fri, 06 Mar 2009 15:04:47 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: enum@ietf.org, richard@shockey.us Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: d.malas@cablelabs.com, Jason.livingood@cable.comcast.com Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:04:30 -0000 notes inline. >> - 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. I understood that very well. However, the new draft is not the same work - it's some operational experience why we don't need the original work. Fine as well, but not the same work. > 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. I preferred to see it as a new draft anyway, because the subject of the draft changed quite a lot (from an Enumservice registration to an operational practice). What i meant is that i don't think we'd need to accept it as a WG item *just* to reason dropping the "trunk" registration work. Now if i hear people saying it contains important operational experience, *then* it's a different story. Whether it should be done in SPEERMINT or ENUM is a different question. > 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? > Well, if it's about finding the path of least resistance, then the sedated ENUM WG might work well :) [...] > 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. ok, ok, i'm convinced - i was just a bit reluctant to replace work that was expired anyway with new work. If it's the easiest way, the lets proceed it. Alex From lconroy@insensate.co.uk Fri Mar 6 06:21:36 2009 Return-Path: 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 D74003A6C2A for ; Fri, 6 Mar 2009 06:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7nAZid4R2OAc for ; Fri, 6 Mar 2009 06:21:36 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [213.152.49.123]) by core3.amsl.com (Postfix) with ESMTP id C45AB3A6BFE for ; Fri, 6 Mar 2009 06:21:35 -0800 (PST) Received: from [IPv6???1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 22A5CFE245; Fri, 6 Mar 2009 14:22:04 +0000 (GMT) Message-Id: <8D5AE895-AA40-4469-B7C1-08BACB5A16B5@insensate.co.uk> From: Lawrence Conroy To: Alexander Mayrhofer In-Reply-To: <49B12D7F.4010706@enum.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 14:22:03 +0000 References: <49B12D7F.4010706@enum.at> X-Mailer: Apple Mail (2.930.3) Cc: enum@ietf.org, d.malas@cablelabs.com, Jason.livingood@cable.comcast.com Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:21:36 -0000 Hi Folks, beware - *who* gets to decide if a WG draft is dead? From experience, some get vocally unhappy if the authors just state (the bl**din' obvious) that the draft is pining for the fjords. Thus shouldn't "the management" (Alex, Richard, Patrik) formally raise the proposal that the existing expired draft is dead, if it is? Also, why is putting this new stuff in the clutches of a sleeping WG (or an inchoate one) going to make it any faster getting any BCP through the IETF/IESG process? Does anyone remember IPTEL? all the best, Lawrence On 6 Mar 2009, at 14:04, Alexander Mayrhofer wrote: > notes inline. > >>> - 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. > > I understood that very well. However, the new draft is not the same > work - it's some operational experience why we don't need the > original work. Fine as well, but not the same work. > >> 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. > > I preferred to see it as a new draft anyway, because the subject of > the draft changed quite a lot (from an Enumservice registration to > an operational practice). > > What i meant is that i don't think we'd need to accept it as a WG > item *just* to reason dropping the "trunk" registration work. > > Now if i hear people saying it contains important operational > experience, *then* it's a different story. > > Whether it should be done in SPEERMINT or ENUM is a different > question. > >> 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? >> > > Well, if it's about finding the path of least resistance, then the > sedated ENUM WG might work well :) > > [...] > >> 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. > > ok, ok, i'm convinced - i was just a bit reluctant to replace work > that was expired anyway with new work. If it's the easiest way, the > lets proceed it. > > Alex > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From wwwrun@core3.amsl.com Wed Mar 18 06:18:45 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3E51828C16A; Wed, 18 Mar 2009 06:18:44 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090318131845.3E51828C16A@core3.amsl.com> Date: Wed, 18 Mar 2009 06:18:45 -0700 (PDT) Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Document Action: 'Combined User and Infrastructure ENUM in the e164.arpa tree' to Informational RFC X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:18:45 -0000 The IESG has approved the following document: - 'Combined User and Infrastructure ENUM in the e164.arpa tree ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-09.txt Technical Summary This memo defines an interim solution for Infrastructure ENUM to allow a combined User (i.e. RFC3761-based) ENUM and Infrastructure (draft-ietf-enum-infrastructure-based) ENUM implementation to exist in e164.arpa as a national choice. The solution is intended as a transition mechanism that would be phased out once a long-term Infrastucture ENUM solution has been put into place. Working Group Summary The ENUM WG supported the advancement of this memo as an Informational RFC in order to document a potential solution. Document Quality The IAB provided valuable Last Call comments on this document. Personnel Jon Peterson is the responsible Area Director. Richard Shockey is the document shepherd. From wwwrun@core3.amsl.com Wed Mar 18 06:20:15 2009 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5240828C17E; Wed, 18 Mar 2009 06:20:14 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090318132015.5240828C17E@core3.amsl.com> Date: Wed, 18 Mar 2009 06:20:15 -0700 (PDT) Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Document Action: 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM' to Informational RFC X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:20:15 -0000 The IESG has approved the following document: - 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-07.txt Technical Summary This document motivates the existence of a parallel namespace for "Infrastructure ENUM" outside of the so-called "User" namespace defined in RFC3761. In particular, this parallel namespace might be used by carriers who want to provision DNS records for telephone numbers independently of the records provisioned by end users (number assignees). Working Group Summary The ENUM WG supports the advancement of this memo to an Informational RFC to document its proposal. Document Quality The IAB provided valuable Last Call comments on this document. Personnel Jon Peterson is the responsible Area Director. Richard Shockey is the document shepherd. RFC Editor Note Please change the "Intended Status" in the header of this memo to "Informational". From lendl@nic.at Fri Mar 20 04:11:54 2009 Return-Path: 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 84A4B28C19E for ; Fri, 20 Mar 2009 04:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 HDFey6g6gOHx for ; Fri, 20 Mar 2009 04:11:53 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id C73933A6B8F for ; Fri, 20 Mar 2009 04:11:53 -0700 (PDT) Received: from [10.10.0.107] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 602B34C39A for ; Fri, 20 Mar 2009 12:12:37 +0100 (CET) Message-ID: <49C37A24.8050704@nic.at> Date: Fri, 20 Mar 2009 12:12:36 +0100 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "enum@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Enum] No session in SF? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 11:11:54 -0000 Given the lack of announcement here, plus the lack of any mention of enum on https://datatracker.ietf.org/meeting/74/agenda.html, can I conclude that there will be no formal enum session at next week's IETF meeting? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From pk@DENIC.DE Fri Mar 20 04:51:17 2009 Return-Path: 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 2479428C1C0 for ; Fri, 20 Mar 2009 04:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ZGYPt-lQ3jU1 for ; Fri, 20 Mar 2009 04:51:16 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id CB8D43A68BF for ; Fri, 20 Mar 2009 04:51:15 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.73]) by office.denic.de with esmtp id 1LkdGa-0002rI-9o; Fri, 20 Mar 2009 12:52:00 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 3627F15EA07; Fri, 20 Mar 2009 12:52:00 +0100 (CET) Date: Fri, 20 Mar 2009 12:51:59 +0100 From: Peter Koch To: IETF ENUM WG Message-ID: <20090320115159.GH12680@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG References: <49B12D7F.4010706@enum.at> <8D5AE895-AA40-4469-B7C1-08BACB5A16B5@insensate.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D5AE895-AA40-4469-B7C1-08BACB5A16B5@insensate.co.uk> User-Agent: Mutt/1.4.2.1i Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 11:51:17 -0000 Hi, I have no expertise on the subject matter, but would like to share some observations on process: On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote: > beware - *who* gets to decide if a WG draft is dead? usually that's a WG consensus, either explicitly or by lack of motion as to be determined by the chairs. In this case however, it seems that the WG (or those in the WG who actively follow the matter) have changed their mind about the direction of the draft. Posting a new I-D was one way, but if the WG consensus is that the solution proposed in "IANA Registration for an Enumservice Trunkgroup" is no longer the right one and instead a parameter to the SIP URI, as proposed in Trunk Group Use in ENUM will do better, then WG consensus could just direct the editors to re-write accordingly. Now, it seems that the editors change on the fly, too, but that's up to the chairs (well, and any new editors) anyway. > Also, why is putting this new stuff in the clutches of a sleeping > WG (or an inchoate one) going to make it any faster getting any BCP > through the IETF/IESG process? Does anyone remember IPTEL? I am a bit nervous about "fast tracking" in the last minute and the status of BCP. The former seldomly works out, but the current work item needs to get off the WG's plate anyway. The latter doesn't seem necessary, especially since we're about to re-classify all (or many of) those Proposed Standards anyway. A purely Informational document would do, and is definitely more lightweight. The draft would be an Informational addendum to RFC 3764, which it needs to reference normatively. The draft itself, however, isn't really clear about the intended status "IANA Registration for an Enumservice Trunkgroup". This document is a normative reference although it seems to have outlived its usefulness and actually the registration in there is kind of revoked. However, the "trunk" ENUM service doesn't yet appear in if my pattern matching skills suffice. So, instead of pursuing the old draft and immediately revoking the registration (or declaring it a no go), the new (well, "revised") draft should just state the new intended method of using trunk groups in ENUM and incorporate verbatim the relevant parts of the earlier draft (without suggesting there actually _is_ a valid ENUM servcie registration) in an appendix. It wouldn't be the first time an IETF WG started an effort to do FOO and the document ends with the title "Why not to FOO". I'm not sure I follow the rationale in the first paragraph of section 1.2, it feels like it's superseded by the newly born 5483 -- congratulations, by the way. -Peter From richard@shockey.us Fri Mar 20 05:33:25 2009 Return-Path: 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 711213A6C5E for ; Fri, 20 Mar 2009 05:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 WCsbk+jPXTsM for ; Fri, 20 Mar 2009 05:33:24 -0700 (PDT) Received: from outbound-mail-147.bluehost.com (outbound-mail-147.bluehost.com [67.222.38.37]) by core3.amsl.com (Postfix) with SMTP id 8D2103A6B24 for ; Fri, 20 Mar 2009 05:33:24 -0700 (PDT) Received: (qmail 7424 invoked by uid 0); 20 Mar 2009 12:30:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 20 Mar 2009 12:30:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=obVZgSCqQNGjWR/gJPR6zSiRt+s4GdWudHFK1TGgDzXjci6Ar7AmhE4NFe3Ut0fiajUJSCZwD1EQarCtc3+eVRNuAUMrg5V0a5TURddW/bBYN1P3GgfTtdptzG2uS/Oi; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LkdvM-0001CY-2l; Fri, 20 Mar 2009 06:34:08 -0600 From: "Richard Shockey" To: "'Peter Koch'" , "'IETF ENUM WG'" References: <49B12D7F.4010706@enum.at> <8D5AE895-AA40-4469-B7C1-08BACB5A16B5@insensate.co.uk> <20090320115159.GH12680@unknown.office.denic.de> In-Reply-To: <20090320115159.GH12680@unknown.office.denic.de> Date: Fri, 20 Mar 2009 08:34:03 -0400 Message-ID: <007101c9a958$280d3460$78279d20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmpUkn18LDs6jcbRDuU+5gveAaRQwAAuFZQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [Enum] WG: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 12:33:25 -0000 Thanks for your comments Peter ..comments in line. > usually that's a WG consensus, either explicitly or by lack of motion > as to > be determined by the chairs. In this case however, it seems that the > WG > (or those in the WG who actively follow the matter) have changed their > mind > about the direction of the draft. Posting a new I-D was one way, but > if the > WG consensus is that the solution proposed in > "IANA Registration for an Enumservice Trunkgroup" is no longer the > right one > and instead a parameter to the SIP URI, as proposed in Trunk Group Use > in ENUM > will do better, then WG consensus could just direct the editors to re- > write > accordingly. Now, it seems that the editors change on the fly, too, > but that's > up to the chairs (well, and any new editors) anyway. Well as one of the original document editors here I had no issue with the change of direction from a new Enumservice registration to a simpler BCP describing the use of 4904 in an existing E2U+SIP context. My larger issue here was that I did not want the usually dysfunctional IETF process issues to get in the way of a perfectly sensible technical solution to a very real problem and take the issue off the table and close the WG. > > > Also, why is putting this new stuff in the clutches of a sleeping > > WG (or an inchoate one) going to make it any faster getting any BCP > > through the IETF/IESG process? Does anyone remember IPTEL? > > I am a bit nervous about "fast tracking" in the last minute and the > status > of BCP. The former seldomly works out, but the current work item > needs to get off the WG's plate anyway. My basic point. The latter doesn't seem necessary, > especially since we're about to re-classify all (or many of) those > Proposed Standards anyway. A purely Informational document would do, and is > definitely more lightweight. The draft would be an Informational > addendum to RFC 3764, which it needs to reference normatively. Why informational vs BCP.. the technical issue raised strikes be a more appropriate for BCP. > > The draft itself, however, isn't really clear about the intended > status "IANA Registration for an Enumservice Trunkgroup". This document is a > normative reference although it seems to have outlived its usefulness and > actually the> registration in there is kind of revoked. The trunk group use draft will be re-written. > However, the "trunk" ENUM service doesn't yet appear in > if my pattern matching > skills > suffice. So, instead of pursuing the old draft and immediately > revoking the registration (or declaring it a no go), the new (well, "revised") > draft should just state the new intended method of using trunk groups in > ENUM and incorporate verbatim the relevant parts of the earlier draft > (without suggesting there actually _is_ a valid ENUM servcie registration) in > an appendix. > It wouldn't be the first time an IETF WG started an effort to do FOO > and the document ends with the title "Why not to FOO". Exactly. Which is really the issue here. Why register a new Enumservice for "trunk" when there is considerable evidence that is not needed. Demonstrate how to incorporate trunk group data in ENUM requests in a simple BCP. My intention was to consult with the AD on this in SF but my basic proposal would be to request WG consensus to drop the original 'trunk group Enumservice registration draft' and use the new 'trunk group use in ENUM' as the basis for the technical solution. The issue raised here is a real problem. We will assist service providers greatly by pushing this along. If we don't do it will end up as a individual draft and wander in the wilderness. I've polled the SPEERMINT WG chairs and they agree it would be better if the ENUM WG deals with this. > > I'm not sure I follow the rationale in the first paragraph of section > 1.2, > it feels like it's superseded by the newly born 5483 -- > congratulations, by > the way. > > -Peter > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum