From richard@shockey.us Tue Apr 21 11:28:21 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 3F1273A6DAB for ; Tue, 21 Apr 2009 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.485, 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 pQ0epx+gy3if for ; Tue, 21 Apr 2009 11:28:20 -0700 (PDT) Received: from outbound-mail-107.bluehost.com (outbound-mail-107.bluehost.com [69.89.22.7]) by core3.amsl.com (Postfix) with SMTP id 3D2153A6D36 for ; Tue, 21 Apr 2009 11:28:20 -0700 (PDT) Received: (qmail 17016 invoked by uid 0); 21 Apr 2009 18:29:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 21 Apr 2009 18:29:36 -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=jMgL/RCsqDG5D1MssKgNu5Z3/T1BbqkrBgf4u3fx0tr7OW6Pe810dfUTBiX6qkfC27/Tu/NgnQ9P2Glm5qeLTFZtVV5y5AA/JnjsNyrE8qaaBGz1GSKn2n3fdu2eIx6j; 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 1LwKiu-0005ne-Cm; Tue, 21 Apr 2009 12:29:36 -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: Tue, 21 Apr 2009 14:29:19 -0400 Message-ID: <01ad01c9c2af$166c4730$4344d590$@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+5gveAaRQwZW8G/Q 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 RESTART 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: Tue, 21 Apr 2009 18:28:21 -0000 I'd like to take up where we left off on this subject and determine what the WG consensus is on dealing with this issue. There is consensus that this is a item we had on the WG plate that has real applicability to applications in use and clarification on how these parameters should be represented in ENUM queries is a "good thing". The first question is then do we essentially adopt this new draft as a WG item and quickly move it forward? The second is as what Informational or BCP? > 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 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From DTroshynski@acmepacket.com Tue Apr 21 12: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 46C0B28C2C8 for ; Tue, 21 Apr 2009 12:39:29 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JPK-7FYUpBQ4 for ; Tue, 21 Apr 2009 12:39:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 091763A6E2B for ; Tue, 21 Apr 2009 12:39:25 -0700 (PDT) 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.340.0; Tue, 21 Apr 2009 15:40:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 21 Apr 2009 15:40:41 -0400 From: Don Troshynski To: Hadriel Kaplan , "rwalter@netnumber.com" , "raja.gopal@nominum.com" , "tom_creighton@cable.comcast.com" Date: Tue, 21 Apr 2009 15:40:55 -0400 Thread-Topic: draft-kaplan-enum-source-uri-00 RESTART Thread-Index: AcnCuRYhjCWP81KgS2igvpG4qJH2SA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31518DF8C2Email_" MIME-Version: 1.0 Cc: "enum@ietf.org" , David Cullerot Subject: [Enum] draft-kaplan-enum-source-uri-00 RESTART 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: Tue, 21 Apr 2009 19:39:29 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31518DF8C2Email_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems like a day to bring up old drafts, so here goes... Where do we stand on draft-kaplan-enum-source-uri-00? Is there any interes= t in updating this draft and moving it forward? This would also make a gre= at way to convey trunk group information as part of the query (and, of cour= se, anything else that can be placed into a URI). If there is consideratio= n of an Informational or BCP on trunk groups in ENUM, this concept should b= e acknowledged, as well. I also think it would be a good idea make the URI= concept generic (not explicitly define it to be the source), and maybe ext= end the definition to include the header name(s). Thoughts? Don --_000_E6C2E8958BA59A4FB960963D475F7AC31518DF8C2Email_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems like a day to bring up old drafts, so here goes= 230;

 

Where do we stand on draft-kaplan-enum-source-uri-00? &n= bsp;Is there any interest in updating this draft and moving it forward?  This= would also make a great way to convey trunk group information as part of the quer= y (and, of course, anything else that can be placed into a URI).  If there is = consideration of an Informational or BCP on trunk groups in ENUM, this concept should be acknowledged, as well.  I also think it would be a good idea make the = URI concept generic (not explicitly define it to be the source), and maybe exte= nd the definition to include the header name(s).

 

Thoughts?


Don

--_000_E6C2E8958BA59A4FB960963D475F7AC31518DF8C2Email_-- From richard@shockey.us Tue Apr 21 13:03: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 022C63A7060 for ; Tue, 21 Apr 2009 13:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.465, 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 c203cugebH42 for ; Tue, 21 Apr 2009 13:03:13 -0700 (PDT) Received: from outbound-mail-33.bluehost.com (outbound-mail-33.bluehost.com [69.89.18.153]) by core3.amsl.com (Postfix) with SMTP id 49E2D3A705D for ; Tue, 21 Apr 2009 13:02:59 -0700 (PDT) Received: (qmail 24568 invoked by uid 0); 21 Apr 2009 19:03:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 21 Apr 2009 19:03:46 -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=fNwT9zux3IWETLAYYTgx48kKgwfAYaNio1iQMnPZbpJqOUew9gixdA8IcGZivCKMIIJN3O0K1O6Pxq0S1DtQoWFYRIjUgN0sgvua4XBwFJPPiNZYDxW6W1t+K0a+d6g0; 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 1LwMCV-0001ty-9Y; Tue, 21 Apr 2009 14:04:15 -0600 From: "Richard Shockey" To: "'Don Troshynski'" , "'Hadriel Kaplan'" , , , References: In-Reply-To: Date: Tue, 21 Apr 2009 16:03:57 -0400 Message-ID: <020101c9c2bc$4f4238f0$edc6aad0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0202_01C9C29A.C83098F0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnCuRYhjCWP81KgS2igvpG4qJH2SAAAdntw 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: enum@ietf.org, 'David Cullerot' , ogud@ogud.com Subject: Re: [Enum] draft-kaplan-enum-source-uri-00 RESTART 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: Tue, 21 Apr 2009 20:03:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0202_01C9C29A.C83098F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey no problem Don ..we are trying to clean things up around here. If I recall this discussion in Phili we were NOT going to do this in ENUM but strongly suggested to Hadriel that if he walked this over to the folks in DNSEXT he would have a reasonable hearing. IMHO given what this draft wants to do, it properly belongs there. I agree, in the context of ENUM usage, source URI makes a lot of sense since this is really not about THE DNS but only the use of DNS as a query technically locally cached. I think the DNSEXT folks will understand that. I recall and Olafur Gudmundsson the DNSEXT co-chair was in the room to hear Hadriel make his case and Patrik and I spoke to Olafur about this afterwards at some length. From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Don Troshynski Sent: Tuesday, April 21, 2009 3:41 PM To: Hadriel Kaplan; rwalter@netnumber.com; raja.gopal@nominum.com; tom_creighton@cable.comcast.com Cc: enum@ietf.org; David Cullerot Subject: [Enum] draft-kaplan-enum-source-uri-00 RESTART Seems like a day to bring up old drafts, so here goes. Where do we stand on draft-kaplan-enum-source-uri-00? Is there any interest in updating this draft and moving it forward? This would also make a great way to convey trunk group information as part of the query (and, of course, anything else that can be placed into a URI). If there is consideration of an Informational or BCP on trunk groups in ENUM, this concept should be acknowledged, as well. I also think it would be a good idea make the URI concept generic (not explicitly define it to be the source), and maybe extend the definition to include the header name(s). Thoughts? Don ------=_NextPart_000_0202_01C9C29A.C83098F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey no problem Don ..we are trying to clean things up = around here.

 

If I recall this discussion in Phili  we were NOT = going to do this in ENUM but strongly suggested to Hadriel that if he walked this = over to the folks in DNSEXT he would have a reasonable hearing.  IMHO given = what this draft wants to do,  it properly belongs = there.

 

I agree, in the context of ENUM usage,  source URI = makes a lot of sense since this is really not about THE DNS but only the use of DNS = as a query technically locally cached.  I think the DNSEXT folks will = understand that.

 

I recall and Olafur Gudmundsson the DNSEXT co-chair was = in the room to hear Hadriel make his case and Patrik and I spoke to Olafur = about this afterwards at some length.

 

From:= enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Don Troshynski
Sent: Tuesday, April 21, 2009 3:41 PM
To: Hadriel Kaplan; rwalter@netnumber.com; = raja.gopal@nominum.com; tom_creighton@cable.comcast.com
Cc: enum@ietf.org; David Cullerot
Subject: [Enum] draft-kaplan-enum-source-uri-00 = RESTART

 

Seems like a day to bring up old drafts, so here = goes…

 

Where do we stand on draft-kaplan-enum-source-uri-00?  Is there any = interest in updating this draft and moving it forward?  This would also make a = great way to convey trunk group information as part of the query (and, of = course, anything else that can be placed into a URI).  If there is = consideration of an Informational or BCP on trunk groups in ENUM, this concept should = be acknowledged, as well.  I also think it would be a good idea make = the URI concept generic (not explicitly define it to be the source), and maybe = extend the definition to include the header name(s).

 

Thoughts?


Don

------=_NextPart_000_0202_01C9C29A.C83098F0-- From rfc-editor@rfc-editor.org Wed Apr 22 16:48:43 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 B1A563A6FA3; Wed, 22 Apr 2009 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.213 X-Spam-Level: X-Spam-Status: No, score=-17.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 d-e-wA1UBIRW; Wed, 22 Apr 2009 16:48:42 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 14E8C3A7193; Wed, 22 Apr 2009 16:48:39 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 0679B28A7FA; Wed, 22 Apr 2009 16:47:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090422234741.0679B28A7FA@bosco.isi.edu> Date: Wed, 22 Apr 2009 16:47:41 -0700 (PDT) Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5526 on The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure 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, 22 Apr 2009 23:48:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5526 Title: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author: J. Livingood, P. Pfautz, R. Stastny Status: Informational Date: April 2009 Mailbox: jason_livingood@cable.comcast.com, ppfautz@att.com, richard.stastny@gmail.com Pages: 9624 Characters: 5 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-infrastructure-07.txt URL: http://www.rfc-editor.org/rfc/rfc5526.txt This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). 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 richard@shockey.us Tue Apr 28 18: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 B388E3A6B36 for ; Tue, 28 Apr 2009 18:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.448, 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 cd1FAzdRzPQk for ; Tue, 28 Apr 2009 18:04:29 -0700 (PDT) Received: from outbound-mail-114.bluehost.com (outbound-mail-114.bluehost.com [69.89.24.4]) by core3.amsl.com (Postfix) with SMTP id BC3403A6768 for ; Tue, 28 Apr 2009 18:04:29 -0700 (PDT) Received: (qmail 25263 invoked by uid 0); 29 Apr 2009 01:05:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 29 Apr 2009 01:05:51 -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=o88JkwpQYhovm+Pjm4ngB9D/Kl5Nhf+gVV1ZwiSWUlrkoD7KZFnC1h3zBAzFfnlUKEu8+KJW8CFgFuPjxyVgsE4eZQ3SSMsBQ6aT7Q1BQqPzCHI3QNISMQqJp/xnY55R; 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 1LyyFD-0006I0-Du; Tue, 28 Apr 2009 19:05:51 -0600 From: "Richard Shockey" To: "'IETF ENUM WG'" References: <49B12D7F.4010706@enum.at> <8D5AE895-AA40-4469-B7C1-08BACB5A16B5@insensate.co.uk> <20090320115159.GH12680@unknown.office.denic.de> <01ad01c9c2af$166c4730$4344d590$@us> In-Reply-To: <01ad01c9c2af$166c4730$4344d590$@us> Date: Tue, 28 Apr 2009 21:05:35 -0400 Message-ID: <00c101c9c866$9acf5c30$d06e1490$@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+5gveAaRQwZW8G/QAW3h/9A= 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: paf@cisco.com Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence 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, 29 Apr 2009 01:04:30 -0000 Second call .. what is WG consensus here? This is not a silence is consent issue. It requires a form of decision. (Chair hat off) I've made my personal sentiments clear. We all thought this was a useful WG item. Some folks have come to us with a cleaner form of dealing with the use case that does not require a formal enumservice registration. It has wide applicability. Better to create a BCP or Informational than let multiple implementations go off in all sorts of non interoperable directions. What does the WG want to do or do you want the chairs to decide? We are not going to have a meeting in Stockholm over this. > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf > Of Richard Shockey > Sent: Tuesday, April 21, 2009 2:29 PM > To: 'Peter Koch'; 'IETF ENUM WG' > Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART > > > I'd like to take up where we left off on this subject and determine > what the WG consensus is on dealing with this issue. > > There is consensus that this is a item we had on the WG plate that has > real applicability to applications in use and clarification on how these > parameters should be represented in ENUM queries is a "good thing". > > The first question is then do we essentially adopt this new draft as a > WG item and quickly move it forward? > > The second is as what Informational or BCP? > > > > 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. > >