From richard@shockey.us Thu May 13 18:20:32 2010 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 EC1393A6940 for ; Thu, 13 May 2010 18:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 QrlCG7Y74FQs for ; Thu, 13 May 2010 18:20:30 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 0FC0B3A68D5 for ; Thu, 13 May 2010 18:20:30 -0700 (PDT) Received: (qmail 22778 invoked by uid 0); 14 May 2010 01:20:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 14 May 2010 01:20:20 -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=B9SGg+FPztZjKMKzGzrpLtKPyFZne9ZYyDFSXBi1heGmeiEaWmxphJ98doc3H/fibJDSBwu5gyxatiebeckvv+Mjyl2ZIQxR33RoqU+qHlDjJz5jx0m6aaE7sb2WAnZ/; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OCjZc-0004Xf-Ap; Thu, 13 May 2010 19:20:20 -0600 From: "Richard Shockey" To: "'Ray Bellis'" , "'Dean Willis'" References: <4BEC7EDF.7000908@softarmor.com> In-Reply-To: Date: Thu, 13 May 2010 21:20:13 -0400 Message-ID: <00e501caf303$9b166cb0$d1434610$@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: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeAgAAUBoCAADL/AIAACXdg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' Subject: Re: [Enum] [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 01:20:32 -0000 So ... all in favor of re chartering the ENUM WG ..please hum on this list or the ENUM WG list now attached. Its time to force the issue. This is important work ultimately central to making SIP work better. Stall and delay is not a rational option here. SIP Service providers and IMS providers want clarity and direction on where the technical standards are moving, if at all. If the IETF doesn't do this it will be done privately and without proper community and peer review. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray Bellis Sent: Thursday, May 13, 2010 8:39 PM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement > Are the rest of the sentences true and consistent with the work we've proposed > to do? They're consistent with the approach in Bernie's draft. However on the last call the it was proposed that it might be a good idea to simply reboot the ENUM WG. In another message Richard has shown that much (if not all) of what we want to do is _already_ within charter. [[[ I first proposed E2M during the Dublin IETF, as a way to mitigate concerns that a particular ex-AD had over use of E2U for "non-communications data". AFAICR he was OK with this proposal, which then laid dormant until Bernie wrote it up. For my own Send-N draft, my plan had actually been to simply wait for the ENUM Services Guide draft to become an RFC, and the re-file under the expert review process. ]]] Ray _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Fri May 14 01:15:46 2010 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 2591C28C0F4; Fri, 14 May 2010 01:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.656, 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 Sb4Q89qbkLXw; Fri, 14 May 2010 01:15:45 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3A20A3A6A67; Fri, 14 May 2010 01:15:20 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OCq2y-0002vk-CQ; Fri, 14 May 2010 10:15:04 +0200 Date: Fri, 14 May 2010 10:15:04 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <00e501caf303$9b166cb0$d1434610$@us> Message-ID: References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 'Ray Bellis' , 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , 'Dean Willis' Subject: Re: [Enum] [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 08:15:46 -0000 As an individual I see it a viable way to work out at least parts of the E2MD cases in the ENUM WG (once we've sorted out which parts are suitable). In this case E2MD would continue to work on those parts that are not suitable for ENUM. As a co-chair of the ENUM WG the appropriate answer to this consultative hum from Rich is: abstention cheers, Bernie On Thu, 13 May 2010, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on this list > or the ENUM WG list now attached. > > Its time to force the issue. This is important work ultimately central to > making SIP work better. Stall and delay is not a rational option here. SIP > Service providers and IMS providers want clarity and direction on where the > technical standards are moving, if at all. If the IETF doesn't do this it > will be done privately and without proper community and peer review. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray > Bellis > Sent: Thursday, May 13, 2010 8:39 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement > > >> Are the rest of the sentences true and consistent with the work we've > proposed >> to do? > > They're consistent with the approach in Bernie's draft. > > However on the last call the it was proposed that it might be a good > idea to simply reboot the ENUM WG. In another message Richard has shown > that much (if not all) of what we want to do is _already_ within charter. > > [[[ > I first proposed E2M during the Dublin IETF, as a way to mitigate concerns > that a particular ex-AD had over use of E2U for "non-communications data". > AFAICR he was OK with this proposal, which then laid dormant until Bernie > wrote it up. > > For my own Send-N draft, my plan had actually been to simply wait for the > ENUM Services Guide draft to become an RFC, and the re-file under the expert > review process. > ]]] > > Ray > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From jim@rfc1035.com Fri May 14 05:18:41 2010 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 0BF8F3A6B09; Fri, 14 May 2010 05:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=1.276, 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 dsfQAdDf9wcp; Fri, 14 May 2010 05:18:40 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 1720E3A6BB5; Fri, 14 May 2010 05:17:28 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 7935D1542837; Fri, 14 May 2010 13:17:17 +0100 (BST) Message-Id: From: Jim Reid To: "Richard Shockey" In-Reply-To: <00e501caf303$9b166cb0$d1434610$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 13:17:17 +0100 References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@us> X-Mailer: Apple Mail (2.936) Cc: 'Ray Bellis' , 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' , 'Dean Willis' Subject: [Enum] Rechartering the ENUM WG 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, 14 May 2010 12:18:41 -0000 On 14 May 2010, at 02:20, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on > this list > or the ENUM WG list now attached. hum++ Apologies for a relevant SubjectL header. :-) From cdel@firsthand.net Fri May 14 05:50:46 2010 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 CCE8C3A6AA7; Fri, 14 May 2010 05:50:46 -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=[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 3Yn0oWFP21lh; Fri, 14 May 2010 05:50:45 -0700 (PDT) Received: from outmail28.go.net.mt (outmail50.go.net.mt [80.93.157.50]) by core3.amsl.com (Postfix) with ESMTP id 91AC03A6971; Fri, 14 May 2010 05:50:43 -0700 (PDT) Received: from [172.20.1.72] (helo=fender72.go.net.mt) by outmail28.go.net.mt with esmtp (Exim 4.67) (envelope-from ) id 1OCuLS-000752-4a; Fri, 14 May 2010 14:50:26 +0200 Received: from [195.158.93.136] (helo=[192.168.3.5]) by fender72.go.net.mt with esmtp (Exim 4.67) (envelope-from ) id 1OCuLR-0007JW-UM; Fri, 14 May 2010 14:50:26 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Christian Larrinaga In-Reply-To: <00e501caf303$9b166cb0$d1434610$@us> Date: Fri, 14 May 2010 14:50:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1078) Cc: 'Ray Bellis' , 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' , 'Dean Willis' Subject: Re: [Enum] [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 12:50:46 -0000 I don't believe IETF should be afraid if others decide to take IETF = stuff and do their own take with it. That is not a good reason to do = those carbuncle things In IETF. What is a good reason is if the WG is = taking the initiative and doing work that is for everyone, scales and = isn't just trying to satisfy a need in some walled garden.=20 So what would be the workplan? Apologies if I've missed a draft that = explains this. In which case I would be grateful for a pointer.=20 Christian On 14 May 2010, at 03:20, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on this = list > or the ENUM WG list now attached. >=20 > Its time to force the issue. This is important work ultimately central = to > making SIP work better. Stall and delay is not a rational option here. = SIP > Service providers and IMS providers want clarity and direction on = where the > technical standards are moving, if at all. If the IETF doesn't do this = it > will be done privately and without proper community and peer review.=20= >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Ray > Bellis > Sent: Thursday, May 13, 2010 8:39 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem = statement >=20 >=20 >> Are the rest of the sentences true and consistent with the work we've > proposed >> to do? >=20 > They're consistent with the approach in Bernie's draft. >=20 > However on the last call the it was proposed that it might be a good > idea to simply reboot the ENUM WG. In another message Richard has = shown > that much (if not all) of what we want to do is _already_ within = charter. >=20 > [[[ > I first proposed E2M during the Dublin IETF, as a way to mitigate = concerns > that a particular ex-AD had over use of E2U for "non-communications = data". > AFAICR he was OK with this proposal, which then laid dormant until = Bernie > wrote it up. >=20 > For my own Send-N draft, my plan had actually been to simply wait for = the > ENUM Services Guide draft to become an RFC, and the re-file under the = expert > review process. > ]]] >=20 > Ray >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri May 14 10:34:16 2010 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 324833A6BFC for ; Fri, 14 May 2010 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=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 ef5ISflvqiTf for ; Fri, 14 May 2010 10:34:14 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E861E3A6BFD for ; Fri, 14 May 2010 10:33:31 -0700 (PDT) Received: (qmail 10545 invoked by uid 0); 14 May 2010 17:33:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 14 May 2010 17:33:22 -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=GgTtgtnDx/yvJSTo+0/64GzHZxfUzyzMfiwoPmpjouPEY6A1e4Byc1kkgCmTqHmAPNhIWEYQQejqN2rAG/aREcLOMaBcxyFoB30AJLzWnhvgdwTbsINC3ISTsxC72qV1; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OCylG-0000Ma-HG; Fri, 14 May 2010 11:33:22 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <4BED7940.20405@softarmor.com> In-Reply-To: <4BED7940.20405@softarmor.com> Date: Fri, 14 May 2010 13:33:16 -0400 Message-ID: <00aa01caf38b$89ffd910$9dff8b30$@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: Acrzg5M97ghUoucvR5a/pFhdlAk3zwABX9qw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'IETF ENUM list' Subject: Re: [Enum] [e2md] E2MD and Indirection -- a new problem statement 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, 14 May 2010 17:34:16 -0000 DNS technology Dean !!! ..stop this "It's the DNS" thing. Its not about the DNS it never was. You are perpetuating the problem once again. If you note the ENUM charter we never ever used the word DNS. That was deliberate and calculated when I wrote it. Delete the word DNS from your text and it closer to the reality here. Now of course the solution is really the two variants of 3761 in deployment the public trees and the private closed ones. The use cases would reflect that matrix of options. Indirection is NOT needed in closed systems its simply interjects a redundant look up into the system that causes delay is session set up. Goal of the E2MD Work (see how much better it reads when you don't talk about the DNS :-) --------------------- An easily extensible framework for using the DNS to discover data that is related to an E.164 number. The framework's organizational model is expected to be based as closely as possible on the existing ENUM [RFC 3761 framework] . The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is expected to provide for storing some data types directly, and in other cases to store a reference to the data, with that determination based on the nature of the data type and its use cases. The framework is NOT expected to provide a selective query mechanism; rather, a query for framework data associated with an E.164 number is expected to return all such data and data. The framework's query mechanism will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework's mechanism is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets. Where such considerations are significant, the framework is expected to provide guidance on the use of other protocols that will be used to retrieve the framework data referenced , and such other protocols are expected to provide needed considerations for authentication, authorization, selective response based on the identity of the querying node, network congestion, reliability, integrity, privacy, and large responses. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type, using the existing ENUM service registration model. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, May 14, 2010 12:25 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] E2MD and Indirection -- a new problem statement I've heard Ray and Richard say that indirection might be appropriate in some cases. If we're willing to factor that into the work, we might have an opportunity. If we amended our problem statement to say that we would analyze the initial use cases, determine which cases need to be "in the database" and which need to be indirectly referenced, show how to indirectly reference where needed, and provide guidance for future users on how to make this determination and provide future guidance on dereferencing, then I predict our problem statement would be MUCH more palatable to the opposition. Let's try a re-write of my proxy-shill version and see if it gets friendlier looking. This one's a bit rough, but it should convey the basics: Goal of the E2MD Work --------------------- An easily extensible framework for using the DNS to discover data that is related to an E.164 number also resolvable in the DNS. The framework's organizational model is expected to be based as closely as possible on the existing ENUM framework. The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is expected to provide for storing some data types directly in the DNS, and in other cases to store a reference to the data in the DNS, with that determination based on the nature of the data type and its use cases. The framework is NOT expected to provide a selective query mechanism; rather, a DNS query for framework data associated with an E.164 number is expected to return all such data and data references known by the DNS to the querying node. The framework's expected query mechanism is expected to be straight-up DNS, and as such will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework's query mechanism is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets beyond the inherent mechanisms of the DNS. Where such considerations are significant, the framework is expected to provide guidance on the use of other protocols that will be used to retrieve the framework data referenced from the DNS, and such other protocols are expected to provide needed considerations for authentication, authorization, selective response based on the identity of the querying node, network congestion, reliability, integrity, privacy, and large responses. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type, using the existing ENUM service registration model. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Fri May 14 22:33:10 2010 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 835473A6970; Fri, 14 May 2010 22:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_50=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 pVMwzDhTNhFm; Fri, 14 May 2010 22:33:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2246A3A6983; Fri, 14 May 2010 22:29:29 -0700 (PDT) Received: from [192.168.2.2] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4F5TCWq001548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 May 2010 00:29:19 -0500 Message-ID: <4BEE3123.80509@softarmor.com> Date: Sat, 15 May 2010 00:29:07 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Richard Shockey References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> In-Reply-To: <00aa01caf38b$89ffd910$9dff8b30$@us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [Enum] [e2md] E2MD and Indirection -- a new problem statement 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: Sat, 15 May 2010 05:33:10 -0000 Richard Shockey wrote: > DNS technology Dean !!! ..stop this "It's the DNS" thing. Its not about the > DNS it never was. You are perpetuating the problem once again. Dude! Slow down and get this through your head: As far as the "rest of the IETF" is concerned, ENUM is about putting phone numbers in the DNS, and as long as ENUM relies on the core protocol of the DNS, any extension to ENUM is an extension to the DNS. Failure to understand this very fundamental concept is why we don't understand the objections that Olaf and Peter and John and Jon and other DNS people keep bringing up. And it's why "just restarting the ENUM working group" will not solve the E2MD problem: the same people that are objecting to E2MD as a standalone working group will object to restarting ENUM. This is also why the CNAM draft that "had consensus in ENUM" did NOT advance through the IETF and is not currently "a standard." If the approach was ever going to fly, it would have migrated south for the winter years ago! Either solve the problem in a way that is acceptable to "the DNS people" by using the DNS consistently with their guidelines, or move the problem outside the DNS. Trying to shove it down their throats is just going to perpetuate further non-progress. -- Dean From trutkowski@netmagic.com Sat May 15 04:31:45 2010 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 60B733A6A39; Sat, 15 May 2010 04:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_40=-0.185] 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 xJ0y-tzq7DUG; Sat, 15 May 2010 04:31:44 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 12E683A67DB; Sat, 15 May 2010 04:31:43 -0700 (PDT) Received: from [192.168.0.28] ([unknown] [173.71.223.14]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2G003C4LCINP30@vms173003.mailsrvcs.net>; Sat, 15 May 2010 06:31:33 -0500 (CDT) Message-id: <4BEE8612.1050907@netmagic.com> Date: Sat, 15 May 2010 07:31:30 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Dean Willis References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> <4BEE3123.80509@softarmor.com> In-reply-to: <4BEE3123.80509@softarmor.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [Enum] [e2md] E2MD and Indirection -- a new problem statement X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 11:31:45 -0000 On 5/15/2010 1:29 AM, Dean Willis wrote: > Either solve the problem in a way that is acceptable to "the DNS people" > by using the DNS consistently with their guidelines, or move the > problem outside the DNS. Trying to shove it down their throats is just > going to perpetuate further non-progress. > > Well said. The OID Resolution Sytem (ORS) folks ran into the same pushback from the "DNS people," even when a similar instantiation occurred with ONS. --tony From bmanning@karoshi.com Sat May 15 15:58:38 2010 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 E21D43A67C2; Sat, 15 May 2010 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_50=0.001, 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 yFem8QelVGMQ; Sat, 15 May 2010 15:58:38 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 0E3963A63C9; Sat, 15 May 2010 15:58:33 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o4FMvDXb009848; Sat, 15 May 2010 22:57:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o4FMulIF009847; Sat, 15 May 2010 22:56:47 GMT Date: Sat, 15 May 2010 22:56:42 +0000 From: bmanning@vacation.karoshi.com To: Tony Rutkowski Message-ID: <20100515225642.GA9833@vacation.karoshi.com.> References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> <4BEE3123.80509@softarmor.com> <4BEE8612.1050907@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEE8612.1050907@netmagic.com> User-Agent: Mutt/1.4.1i Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , Dean Willis Subject: Re: [Enum] [e2md] E2MD and Indirection -- a new problem statement 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: Sat, 15 May 2010 22:58:39 -0000 hum, as a "DNS person"... I spent a fair number of hours ~70% of my time, working on something almost identical to the VSGN-ONS platform ... with the AutoID labs folks in Japan. We never called it anything other than what it was, DNS with extentions. Never remember any public pushback from the "DNS people" on ONS. Archives? --bill On Sat, May 15, 2010 at 07:31:30AM -0400, Tony Rutkowski wrote: > On 5/15/2010 1:29 AM, Dean Willis wrote: > >Either solve the problem in a way that is acceptable to "the DNS people" > > by using the DNS consistently with their guidelines, or move the > >problem outside the DNS. Trying to shove it down their throats is just > >going to perpetuate further non-progress. > > > > > > Well said. The OID Resolution Sytem (ORS) folks ran into > the same pushback from the "DNS people," even when a > similar instantiation occurred with ONS. > > --tony > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From bernie@ietf.hoeneisen.ch Wed May 19 01:06:25 2010 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 91C6B3A6821 for ; Wed, 19 May 2010 01:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_50=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 4ss4SASOX1Az for ; Wed, 19 May 2010 01:06:24 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3E94D3A68B0 for ; Wed, 19 May 2010 01:06:21 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OEeI8-0007ZB-07; Wed, 19 May 2010 10:06:12 +0200 Date: Wed, 19 May 2010 10:06:11 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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 Subject: [Enum] Section 1.2 & 2 of 3761bis 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, 19 May 2010 08:06:25 -0000 Moved from E2MD: On Tue, 18 May 2010, Lawrence Conroy wrote (in context of E2MD): > [Assuming we can roll back some of the more arcane restrictions > in section 1.2 of rfc3761bis and the bit moved into the second > paragraph of the intro of section 2]. As Gonzalo already pointed out this part of 3761bis needs revision before it goes to IESG. Section 1.2. appears at best "confusing"...or should I rather say "broken", as it mixes up private ENUM instances that are based on the E.164 dial plan and those private instances that do not use E.164 numbers. If these mechanisms are re-used, the suffix used for the private dialing plan MUST NOT be e164.arpa, to avoid conflict with this specification. Parties to the private dialing plan will need to know the suffix used by their private dialing plan for correct operation of these mechanisms. Further, the application unique string used SHOULD be the full number as specified, but without the leading '+', and such private use MUST NOT be called "ENUM" because the leading "E" in this acronym explicitly stands for "E.164". Section 2 on the other hand makes it practically impossible to use ENUM with non-E.164 numbering plans: To mitigate this risk, the "E2U" token MUST NOT provisioned in domains associated with non-E.164 numbers. Furthermore I am not sure if the introcuction section is the right place to make mandatory statements. IMHO It should be rather an applicability statement section or similar. Note: I understand you inherited this part from RFC 3761. cheers, Bernie From patrik@frobbit.se Wed May 19 01:27:50 2010 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 B4C933A6B9F for ; Wed, 19 May 2010 01:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Mtt1tIUmfIY5 for ; Wed, 19 May 2010 01:27:50 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 63E043A6C21 for ; Wed, 19 May 2010 01:23:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3C31BB79EFD3; Wed, 19 May 2010 10:23:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9d9FOAGZHjO; Wed, 19 May 2010 10:23:43 +0200 (CEST) Received: from [90.235.205.185] (host-90-235-205-185.mobileonline.telia.com [90.235.205.185]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A7612B79EFCF; Wed, 19 May 2010 10:23:43 +0200 (CEST) References: Message-Id: From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 19 May 2010 11:23:39 +0300 Cc: IETF ENUM list , Lawrence Conroy Subject: Re: [Enum] Section 1.2 & 2 of 3761bis 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, 19 May 2010 08:27:50 -0000 On 19 maj 2010, at 11.06, Bernie Hoeneisen wrote: > Section 2 on the other hand makes it practically impossible to use > ENUM with non-E.164 numbering plans: > > To mitigate this risk, the "E2U" token MUST NOT > provisioned in domains associated with non-E.164 numbers. It all depends on what we mean by ENUM. We do not agree if ENUM stands only for the technology (look things up in dns, given some root) or only when the root is e164.arpa. I thought we had this discussion in the enum wg, and concluded that enum (without any prefix or suffix) always implies use of e164.arpa. Other things are called infrastructure enum, enum-like, use of enum technology, private enum or such. Which I think is what the text quoted says. Patrik From lconroy@insensate.co.uk Wed May 19 03:52:42 2010 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 60C213A6782 for ; Wed, 19 May 2010 03:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 s7XgpF1tLcyM for ; Wed, 19 May 2010 03:52:41 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id D31EB28C0F5 for ; Wed, 19 May 2010 03:50:22 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C8EAA13B622; Wed, 19 May 2010 11:50:11 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: Date: Wed, 19 May 2010 11:50:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78D243C6-4F9F-489E-8720-CB6861DD34F7@insensate.co.uk> References: To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1078) Cc: IETF ENUM list , Bernie Hoeneisen Subject: Re: [Enum] Section 1.2 & 2 of 3761bis 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, 19 May 2010 10:52:42 -0000 Hi Patrik, folks, That's my problem -- there are two elements: the technology (mapping = phone numbers to domain names within SOME apex) and the IAB/ITU-T+IANA = agreement on e164.arpa. The technology is usable regardless of whether it's in public or within = a private federated net, or using an alternative root, or ... This is not just a name (ENUM =3D=3D use of this technology in public = within the e164.arpa apex). It's also who or what can use the = technology. This matters for Send-N and Unused, where there may be records elsewhere = that in leaf zones associated with E.164 numbers. The technology is common; the restrictions on E.164 numbers are tied to = the IAB agreement. We have a mixture of the two. all the best, Lawrence On 19 May 2010, at 09:23, Patrik F=E4ltstr=F6m wrote: > On 19 maj 2010, at 11.06, Bernie Hoeneisen = wrote: >=20 >> Section 2 on the other hand makes it practically impossible to use = ENUM with non-E.164 numbering plans: >>=20 >> To mitigate this risk, the "E2U" token MUST NOT >> provisioned in domains associated with non-E.164 numbers. >=20 > It all depends on what we mean by ENUM. We do not agree if ENUM stands = only for the technology (look things up in dns, given some root) or only = when the root is e164.arpa. >=20 > I thought we had this discussion in the enum wg, and concluded that = enum (without any prefix or suffix) always implies use of e164.arpa. >=20 > Other things are called infrastructure enum, enum-like, use of enum = technology, private enum or such. >=20 > Which I think is what the text quoted says. >=20 > Patrik >=20 From lconroy@insensate.co.uk Wed May 19 15:57:48 2010 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 7D8253A6AAD for ; Wed, 19 May 2010 15:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 YTHV2lIEc5Tn for ; Wed, 19 May 2010 15:57:47 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id D63F13A6A9D for ; Wed, 19 May 2010 15:57:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B815813BD11; Wed, 19 May 2010 23:57:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: <78D243C6-4F9F-489E-8720-CB6861DD34F7@insensate.co.uk> Date: Wed, 19 May 2010 23:57:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60EB6E5B-AFBC-40DB-BCBF-D7E04260888C@insensate.co.uk> References: <78D243C6-4F9F-489E-8720-CB6861DD34F7@insensate.co.uk> To: Lawrence Conroy , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Bernie Hoeneisen X-Mailer: Apple Mail (2.1078) Cc: IETF ENUM list Subject: Re: [Enum] Section 1.2 & 2 of 3761bis 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, 19 May 2010 22:57:48 -0000 Hi again Patrik, Bernie, folks, Patrik? -- help needed. The issue in section 2 of RFC 3761 (bis) that it doe not have the = intended effect as specified. It is perfectly possible to have E2U NAPTRs in other domains -- an ENUM = domain can hold a non-terminal NAPTR that points to any other domain. = That domain can hold E2U NAPTRs. Thus: $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 100 50 "" "" "" . $ORIGIN example.com. NAPTR 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . ... This seems valid, BUT it doesn't match the text -- example.com. is = certainly NOT associated with an E.164 number, but could hold NAPTRs = that were discovered as part of an ENUM query on the E.164 number = +44-1632-960083 I would like to re-write this paragraph, as I do not believe that this = block on reasonable use was the intention of the last sentence. i.e. I think it's wrong as written. I've looked back through the ML archives, and I didn't get the = impression that this was was was intended. (I sure don't remember it = that way). I also think this paragraph is broken in other ways; it conflates ENUM = domains (i.e. input is an E.164 number, key is within the e164.arpa = apex) with E2U NAPTRs, dialling plans with number plans, and diallable = numbers with assigned numbers in a number plan, and ...) Comments? all the best, Lawrence On 19 May 2010, at 11:50, Lawrence Conroy wrote: > Hi Patrik, folks, > That's my problem -- there are two elements: the technology (mapping = phone numbers to domain names within SOME apex) and the IAB/ITU-T+IANA = agreement on e164.arpa. > The technology is usable regardless of whether it's in public or = within a private federated net, or using an alternative root, or ... >=20 > This is not just a name (ENUM =3D=3D use of this technology in public = within the e164.arpa apex). It's also who or what can use the = technology. > This matters for Send-N and Unused, where there may be records = elsewhere that in leaf zones associated with E.164 numbers. >=20 > The technology is common; the restrictions on E.164 numbers are tied = to the IAB agreement. We have a mixture of the two. >=20 > all the best, > Lawrence >=20 >=20 > On 19 May 2010, at 09:23, Patrik F=E4ltstr=F6m wrote: >=20 >> On 19 maj 2010, at 11.06, Bernie Hoeneisen = wrote: >>=20 >>> Section 2 on the other hand makes it practically impossible to use = ENUM with non-E.164 numbering plans: >>>=20 >>> To mitigate this risk, the "E2U" token MUST NOT >>> provisioned in domains associated with non-E.164 numbers. >>=20 >> It all depends on what we mean by ENUM. We do not agree if ENUM = stands only for the technology (look things up in dns, given some root) = or only when the root is e164.arpa. >>=20 >> I thought we had this discussion in the enum wg, and concluded that = enum (without any prefix or suffix) always implies use of e164.arpa. >>=20 >> Other things are called infrastructure enum, enum-like, use of enum = technology, private enum or such. >>=20 >> Which I think is what the text quoted says. >>=20 >> Patrik >>=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed May 19 18:15:37 2010 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 506453A6B0A for ; Wed, 19 May 2010 18:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_20=-0.74] 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 ukMGzN2G20KA for ; Wed, 19 May 2010 18:15:37 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id A87E23A6AE2 for ; Wed, 19 May 2010 18:15:32 -0700 (PDT) Received: (qmail 23344 invoked by uid 0); 20 May 2010 01:15:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 May 2010 01:15:25 -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=Oseq/g6DjEETlNYlb37+xdxaLenO0EcOiieFNKt5UnBZEMa3F7S4DtcNfbRdnnDuWJgdxOJaV1Tqf2+Rl2oYhaMPAq5XP/R9uFkJ6lGrInVvDDiWtJ0upz4kPV4aaCYc; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OEuM9-0000mw-Io; Wed, 19 May 2010 19:15:25 -0600 From: "Richard Shockey" To: "'Sumanth Channabasappa'" , "'Cartwright, Kenneth'" , , "'PFAUTZ, PENN L \(ATTCORP\)'" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> Date: Wed, 19 May 2010 21:15:18 -0400 Message-ID: <000801caf7b9$e9de9790$bd9bc6b0$@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: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAC9pR4A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [Enum] [e2md] Problem statement, Requirements and Use Cases 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, 20 May 2010 01:15:37 -0000 Well .. as far as I'm concerned the discussion of what is the namespace is charming but ultimately another discussion. What is important is the definition of the use case and why opaque carrier identification methodologies is important (vs edge URI identification) and I'd like to call for volunteers to help me or someone to write this up as a ID. There is no possible doubt that this is important to the global telecommunications industry and IMHO is principally utilized principally in private-carrier-infrastructure ENUM instantiations. Not to say that, by some for form of indirection, this could live in e164.arpa but either way it makes sense. It's the right thing to do and the timing is right now. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/see them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164 > to a globally defined identifier, specifically an IANA Enterprise > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From patrik@frobbit.se Wed May 19 21:49:29 2010 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 CE69B3A694A for ; Wed, 19 May 2010 21:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 xufRi61OeyZP for ; Wed, 19 May 2010 21:49:28 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id EF0D73A6AFC for ; Wed, 19 May 2010 21:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 8BBF9B7E43FD; Thu, 20 May 2010 06:49:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 055QUlLMz1iB; Thu, 20 May 2010 06:49:08 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::dead:beef] (unknown [IPv6:2a02:80:3ffc::dead:beef]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id A51E0B7E43EB; Thu, 20 May 2010 06:49:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--328999905" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <60EB6E5B-AFBC-40DB-BCBF-D7E04260888C@insensate.co.uk> Date: Thu, 20 May 2010 06:49:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <78D243C6-4F9F-489E-8720-CB6861DD34F7@insensate.co.uk> <60EB6E5B-AFBC-40DB-BCBF-D7E04260888C@insensate.co.uk> To: Lawrence Conroy X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: IETF ENUM list , Bernie Hoeneisen Subject: Re: [Enum] Section 1.2 & 2 of 3761bis 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, 20 May 2010 04:49:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--328999905 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 maj 2010, at 00.57, Lawrence Conroy wrote: > I also think this paragraph is broken in other ways; it conflates ENUM = domains (i.e. input is an E.164 number, key is within the e164.arpa = apex) with E2U NAPTRs, dialling plans with number plans, and diallable = numbers with assigned numbers in a number plan, and ...) >=20 > Comments? It is an example, and it says it is possible to have E2U NAPTR in other = domains, which is true. Examples are non-normative. I do not see any problems with the text. Patrik --Apple-Mail-10--328999905 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFL9L8/rMabGguI180RAurvAJ9MMlJsESrrA9zY/eGUzI+T6FmJVwCeJOEd hKun8QCvP3aBurcfTTzNg8M= =Fyyj -----END PGP SIGNATURE----- --Apple-Mail-10--328999905-- From kcartwright@tnsi.com Thu May 20 07:16:11 2010 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 6A87F3A6CCD; Thu, 20 May 2010 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=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 kDEXluBBPNRO; Thu, 20 May 2010 07:16:08 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id BAE1D3A6919; Thu, 20 May 2010 07:15:24 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43814285; Thu, 20 May 2010 10:14:51 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 20 May 2010 10:14:51 -0400 From: "Cartwright, Kenneth" To: Richard Shockey , 'Sumanth Channabasappa' , "trutkowski@netmagic.com" , "'PFAUTZ, PENN L (ATTCORP)'" Date: Thu, 20 May 2010 10:14:49 -0400 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAC9pR4AAbqJww Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446D2C44A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> <000801caf7b9$e9de9790$bd9bc6b0$@us> In-Reply-To: <000801caf7b9$e9de9790$bd9bc6b0$@us> 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 X-Mailman-Approved-At: Fri, 21 May 2010 08:23:42 -0700 Cc: "drinks@ietf.org" , 'IETF ENUM list' , list' , 'E.164 Subject: Re: [Enum] [e2md] Problem statement, Requirements and Use Cases 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, 20 May 2010 14:16:11 -0000 Rich, fwiw, I can contribute to this effort. Ken -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Wednesday, May 19, 2010 9:15 PM To: 'Sumanth Channabasappa'; Cartwright, Kenneth; trutkowski@netmagic.com; = 'PFAUTZ, PENN L (ATTCORP)' Cc: drinks@ietf.org; 'E.164 To MetaData BOF discussion list'; 'IETF ENUM li= st' Subject: RE: [e2md] Problem statement, Requirements and Use Cases Well .. as far as I'm concerned the discussion of what is the namespace is charming but ultimately another discussion. What is important is the definition of the use case and why opaque carrier identification methodologies is important (vs edge URI identification) and I'd like to cal= l for volunteers to help me or someone to write this up as a ID. There is no possible doubt that this is important to the global telecommunications industry and IMHO is principally utilized principally in private-carrier-infrastructure ENUM instantiations. Not to say that, by some for form of indirection, this could live in e164.arpa but either way it makes sense. It's the right thing to do and the timing is right now. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/se= e them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID= , or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164 > to a globally defined identifier, specifically an IANA Enterprise > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it als= o has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From bernie@ietf.hoeneisen.ch Fri May 21 13:47:44 2010 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 0863A3A69C6 for ; Fri, 21 May 2010 13:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=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 q2MJGVrVuQji for ; Fri, 21 May 2010 13:47:42 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id D6F5E3A6ED2 for ; Fri, 21 May 2010 13:39:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OFYxg-0003Fb-HD; Fri, 21 May 2010 22:36:52 +0200 Date: Fri, 21 May 2010 22:36:52 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: <60EB6E5B-AFBC-40DB-BCBF-D7E04260888C@insensate.co.uk> Message-ID: References: <78D243C6-4F9F-489E-8720-CB6861DD34F7@insensate.co.uk> <60EB6E5B-AFBC-40DB-BCBF-D7E04260888C@insensate.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-856037498-1274474212=:11947" 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 , =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Section 1.2 & 2 of 3761bis 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, 21 May 2010 20:47:44 -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-856037498-1274474212=:11947 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Lawrence IMHO whatever makes the text more clear and/or understandable is worth a=20 revision (as we have more than enough confusion in the ENUM field...).=20 Besides this also Gonzalo found an issue there during his AD review. I suggest you to send your proposed changes to the ENUM list and give=20 others a couple of days for feedback on it. cheers, Bernie On Wed, 19 May 2010, Lawrence Conroy wrote: > Hi again Patrik, Bernie, folks, > > Patrik? -- help needed. > > The issue in section 2 of RFC 3761 (bis) that it doe not have the=20 > intended effect as specified. > > It is perfectly possible to have E2U NAPTRs in other domains -- an ENUM d= omain can hold a non-terminal NAPTR that points to any other domain. That d= omain can hold E2U NAPTRs. Thus: > $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. > NAPTR 100 50 "" "" "" . > > $ORIGIN example.com. > NAPTR 100 50 "u" "E2U+sip" > "!^(\\+441632960083)$!sip:\\1@example.com!" . > ... > > This seems valid, BUT it doesn't match the text -- example.com. is=20 > certainly NOT associated with an E.164 number, but could hold NAPTRs=20 > that were discovered as part of an ENUM query on the E.164 number=20 > +44-1632-960083 > > I would like to re-write this paragraph, as I do not believe that this=20 > block on reasonable use was the intention of the last sentence. i.e. I=20 > think it's wrong as written. > > I've looked back through the ML archives, and I didn't get the=20 > impression that this was was was intended. (I sure don't remember it=20 > that way). > > I also think this paragraph is broken in other ways; it conflates ENUM=20 > domains (i.e. input is an E.164 number, key is within the e164.arpa=20 > apex) with E2U NAPTRs, dialling plans with number plans, and diallable=20 > numbers with assigned numbers in a number plan, and ...) > > Comments? > > all the best, > Lawrence > > > On 19 May 2010, at 11:50, Lawrence Conroy wrote: > >> Hi Patrik, folks, >> That's my problem -- there are two elements: the technology (mapping pho= ne numbers to domain names within SOME apex) and the IAB/ITU-T+IANA agreeme= nt on e164.arpa. >> The technology is usable regardless of whether it's in public or within = a private federated net, or using an alternative root, or ... >> >> This is not just a name (ENUM =3D=3D use of this technology in public wi= thin the e164.arpa apex). It's also who or what can use the technology. >> This matters for Send-N and Unused, where there may be records elsewhere= that in leaf zones associated with E.164 numbers. >> >> The technology is common; the restrictions on E.164 numbers are tied to = the IAB agreement. We have a mixture of the two. >> >> all the best, >> Lawrence >> >> >> On 19 May 2010, at 09:23, Patrik F=E4ltstr=F6m wrote: >> >>> On 19 maj 2010, at 11.06, Bernie Hoeneisen w= rote: >>> >>>> Section 2 on the other hand makes it practically impossible to use ENU= M with non-E.164 numbering plans: >>>> >>>> To mitigate this risk, the "E2U" token MUST NOT >>>> provisioned in domains associated with non-E.164 numbers. >>> >>> It all depends on what we mean by ENUM. We do not agree if ENUM stands = only for the technology (look things up in dns, given some root) or only wh= en the root is e164.arpa. >>> >>> I thought we had this discussion in the enum wg, and concluded that enu= m (without any prefix or suffix) always implies use of e164.arpa. >>> >>> Other things are called infrastructure enum, enum-like, use of enum tec= hnology, private enum or such. >>> >>> Which I think is what the text quoted says. >>> >>> Patrik >>> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www.ietf.org/mailman/listinfo/enum > > --37663318-856037498-1274474212=:11947-- From richard@shockey.us Mon May 24 13:48:06 2010 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 E08A13A687C for ; Mon, 24 May 2010 13:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_50=0.001, 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 QU4wb4ZFcGpe for ; Mon, 24 May 2010 13:48:03 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id DE9FA3A67EF for ; Mon, 24 May 2010 13:48:02 -0700 (PDT) Received: (qmail 21897 invoked by uid 0); 24 May 2010 20:47:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 May 2010 20:47:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=YXL0F3tMoK4O8ALS/Ps33/++FRSNJQLogWqWXd0hyzIiwGQ+W2aya9fyU/TrgsCveF40Tg4UiG0fAjOtYlThC0zAR7z+5BlXd81rifW8SNpbT9X+EFYKgGalv/0hhLR3; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGeYx-0001bX-4q; Mon, 24 May 2010 14:47:51 -0600 From: "Richard Shockey" To: "'E.164 To MetaData BOF discussion list'" Date: Mon, 24 May 2010 16:47:43 -0400 Message-ID: <00dc01cafb82$5c85e700$1591b500$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01CAFB60.D5744700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7glu2pEX3hlx4SJmiAT9DU/trww== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: drinks@ietf.org, 'IETF ENUM list' , speermint@ietf.org Subject: [Enum] On the issue of G-SPN's 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: Mon, 24 May 2010 20:48:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01CAFB60.D5744700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Though the use case for a G-SPN has been identified by this list and is on the TWKI, I want to make it abundantly clear that I do not believe that ENUM or a E2MD WG should actually define what is the appropriate namespace for G-SPN's. It is a requirement for DRINKS ( by ITU liaison) and touches on SPEERMINT ( which IMHO should shut down ). Consequently the logical thing to do is a individual submission. I've offered to try and rough cut a Use Case and Requirements document, which I will do in the not to distant future in collaboration with several others who have offered to help. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_00DD_01CAFB60.D5744700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though the use case for a G-SPN has been identified = by this list and is on the TWKI, I want to make it abundantly clear that I do = not believe that ENUM or a E2MD WG should actually define what is the appropriate = namespace for G-SPN’s.

 

It is a requirement for DRINKS ( by ITU liaison) = and touches on SPEERMINT ( which IMHO should shut down ). Consequently the logical = thing to do is a individual submission.

 

I’ve offered to try and rough cut a Use Case = and Requirements document, which I will do in the not to distant future in collaboration with several others who have offered to help. =

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_00DD_01CAFB60.D5744700-- From trutkowski@netmagic.com Mon May 24 14:07:58 2010 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 144F03A6D10; Mon, 24 May 2010 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_50=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 WLbd-gLcLxEb; Mon, 24 May 2010 14:07:57 -0700 (PDT) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by core3.amsl.com (Postfix) with ESMTP id 0D2BB3A6D01; Mon, 24 May 2010 14:07:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2Y00JXY00AT1D0@vms173013.mailsrvcs.net>; Mon, 24 May 2010 16:07:27 -0500 (CDT) Message-id: <4BFAEA8A.4010005@netmagic.com> Date: Mon, 24 May 2010 17:07:22 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 To: Richard Shockey References: <00dc01cafb82$5c85e700$1591b500$@us> In-reply-to: <00dc01cafb82$5c85e700$1591b500$@us> Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [Enum] [e2md] On the issue of G-SPN's X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 21:07:58 -0000 Hi Richard, Could you amplify on the "by ITU liaision" parenthetical? Considering the G-SPN notion is being driven by a NeuStar input into ITU-T, that creates a substantial NeuStar new revenue opportunity/impact on providers, chaired by a NeuStar staff member in ITU-T, and sprinkled with NeuStar people in IETF, some care seems appropriate about the assertions and process. I'll offer to help as well. cheers, tony On 5/24/2010 4:47 PM, Richard Shockey wrote: > > Though the use case for a G-SPN has been identified by this list and > is on the TWKI, I want to make it abundantly clear that I do not > believe that ENUM or a E2MD WG should actually define what is the > appropriate namespace for G-SPN’s. > > It is a requirement for DRINKS ( by ITU liaison) and touches on > SPEERMINT ( which IMHO should shut down ). Consequently the logical > thing to do is a individual submission. > > I’ve offered to try and rough cut a Use Case and Requirements > document, which I will do in the not to distant future in > collaboration with several others who have offered to help. > From richard@shockey.us Tue May 25 07:06:32 2010 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 392123A6F08 for ; Tue, 25 May 2010 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_50=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 Z9Mm3+mB8UQ3 for ; Tue, 25 May 2010 07:06:30 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id A12223A6CEB for ; Tue, 25 May 2010 07:06:30 -0700 (PDT) Received: (qmail 1230 invoked by uid 0); 25 May 2010 14:06:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 25 May 2010 14:06:22 -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=IV4wFNLWwthEAvQ3xR64xbZuiquSbCPKN8Idxl71VXCu7UkMsaCSmWjzIJ754sRjNPnyoxGbQQZQz1vJEWcsx34VR+0OSWlY3ElaC+MZqv5zxj1zTItPDwJQcrccUcZh; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGulx-00045H-Kr; Tue, 25 May 2010 08:06:22 -0600 From: "Richard Shockey" To: References: <00dc01cafb82$5c85e700$1591b500$@us> <4BFAEA8A.4010005@netmagic.com> In-Reply-To: <4BFAEA8A.4010005@netmagic.com> Date: Tue, 25 May 2010 10:06:14 -0400 Message-ID: <015b01cafc13$71043600$530ca200$@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: Acr7hSOa0+g1vYQ0QSmDxtExSPc2QgAjVSiw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [Enum] [e2md] On the issue of G-SPN's 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, 25 May 2010 14:06:32 -0000 -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Monday, May 24, 2010 5:07 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list'; drinks@ietf.org; 'IETF ENUM list'; speermint@ietf.org Subject: Re: [e2md] On the issue of G-SPN's Hi Richard, Could you amplify on the "by ITU liaision" parenthetical? I'ts simple ITU wanted to make sure the DRINKS WG left open a field for SPN use. http://www.itu.int/md/T09-SG02-090324-TD-PLEN-0071/en Considering the G-SPN notion is being driven by a NeuStar input into ITU-T, that creates a substantial NeuStar new revenue opportunity/impact on providers, chaired by a NeuStar staff member in ITU-T, and sprinkled with NeuStar people in IETF, some care seems appropriate about the assertions and process. Well whether it creates any revenue for some company especially the one you mention is none of my concern. :-) Whatever form the SPN takes, its self evident that SPN create operational efficiencies for service providers both for internal as well as external session establishment. I'll offer to help as well. cheers, tony On 5/24/2010 4:47 PM, Richard Shockey wrote: > > Though the use case for a G-SPN has been identified by this list and > is on the TWKI, I want to make it abundantly clear that I do not > believe that ENUM or a E2MD WG should actually define what is the > appropriate namespace for G-SPN's. > > It is a requirement for DRINKS ( by ITU liaison) and touches on > SPEERMINT ( which IMHO should shut down ). Consequently the logical > thing to do is a individual submission. > > I've offered to try and rough cut a Use Case and Requirements > document, which I will do in the not to distant future in > collaboration with several others who have offered to help. > From trutkowski@netmagic.com Tue May 25 08:11:05 2010 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 9D5B23A713E; Tue, 25 May 2010 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] 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 ZoGt32CSp6R1; Tue, 25 May 2010 08:11:04 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 3E7073A712B; Tue, 25 May 2010 08:11:03 -0700 (PDT) Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2Z00JVGE5BEJ00@vms173017.mailsrvcs.net>; Tue, 25 May 2010 10:10:29 -0500 (CDT) Message-id: <4BFBE85F.7050609@netmagic.com> Date: Tue, 25 May 2010 11:10:23 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Richard Shockey References: <00dc01cafb82$5c85e700$1591b500$@us> <4BFAEA8A.4010005@netmagic.com> <015b01cafc13$71043600$530ca200$@us> In-reply-to: <015b01cafc13$71043600$530ca200$@us> Content-type: multipart/mixed; boundary=------------070708080107010805030604 Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [Enum] [e2md] On the issue of G-SPN's X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:11:05 -0000 This is a multi-part message in MIME format. --------------070708080107010805030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That's not really what the document says. Since many people may not be able to access the site and view it, the attached copy is edifying. Note particularly the highlighted text. It helps provide context and concern. --tony On 5/25/2010 10:06 AM, Richard Shockey wrote: > I'ts simple ITU wanted to make sure the DRINKS WG left open a field for SPN > use. > > http://www.itu.int/md/T09-SG02-090324-TD-PLEN-0071/en > --------------070708080107010805030604 Content-Type: application/pdf; name="T09-SG02-090324-TD-PLEN-0071!!MSW-E.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="T09-SG02-090324-TD-PLEN-0071!!MSW-E.pdf" JVBERi0xLjUNJeLjz9MNCjE0IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDEzMTU2L08gMTYv RSA3NDQxL04gMi9UIDEyODQzL0ggWyA0NTUgMTY2XT4+DWVuZG9iag0gICAgICAgICAgICAg ICAgICAgDQoyMCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3Ig MTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEQ2QkYxM0MzRkQyQzBFQTY3MDlCMTA0NDdG NDhCQUQyPjxCRjcyOEM5RDgwMDE1QTQ1QUMzNjYwNzVERjcwMUMwMD5dL0luZGV4WzE0IDE1 XS9JbmZvIDEzIDAgUi9MZW5ndGggNTIvUHJldiAxMjg0NC9Sb290IDE1IDAgUi9TaXplIDI5 L1R5cGUvWFJlZi9XWzEgMiAxXT4+c3RyZWFtDQpo3mJiZBBgYGJgigUSDAFAgrEJxN0LJHgn Aol3zxmYGBnmgmQZGHET/xm3/QIIMAACqAfoDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJl Zg0KMA0KJSVFT0YNCiAgICAgICAgDQoyOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUv SSA5NS9MIDc5L0xlbmd0aCA4Mi9TIDQ4Pj5zdHJlYW0NCmjeYmBgYGZgYBJnYGRgYElh4GVA AF6gGCMDCwNHw/oGBoYDDgwgCgmwQDEDQxMDDwOT9YFfTFBh211AGmggQycQszMw+PpD+IxK AAEGANn7CWcNCmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNPDwvTWV0YWRhdGEgNSAwIFIv UGFnZUxhYmVscyAxMCAwIFIvUGFnZXMgMTIgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9iag0x NiAwIG9iag08PC9Db250ZW50cyAxOCAwIFIvQ3JvcEJveFswIDAgNTk1IDg0Ml0vTWVkaWFC b3hbMCAwIDU5NSA4NDJdL1BhcmVudCAxMiAwIFIvUmVzb3VyY2VzIDIxIDAgUi9Sb3RhdGUg MC9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0Zp cnN0IDQ4L0xlbmd0aCA2MDYvTiA3L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjepFRta9swEP4r 93H7kOnFtuxACSRp0xXWLtRmHYR80BItMTh2sFXW/vvdSVZeWspYi1DudM/p9Jz0OFIABylB 8ARkBAKnjEFkaBKIhQKpIIuHIFNMSRVcXLBpUzVtvtcrQ4tO0XYO96MRu3qy17nVloDrXFBB D8ya2mKsKCSVxRi6MdX08LxtVrmxCza/nLHCPNnlaLRgN9PpRHdmDWJIeUss8H0Ov3XVGXRu QbB83C/zW+BfuGTF894cWbBm7/HRCPeOu5WpLWRDwaZ6/9WUm63Fnjhnl8ZDAykUm1V600EU O86TSfO0GCRJBoOIpyAxG7dItXToTO/K6vlTUe5MB3fmD9w3O11/dtid3hnmEARcfJ4PJk21 vi0cntvW2NWW3TXtTlcu9OAppcjoxuqqXI3rTWWAs9ya3Q8QkfL9US5Rbsu9bVr286QV1yhd GuW8dfxVvWrWZb1hD2U9rrvysJ6VbWenW91CJF+cQqKgZ/um+wwh8foff1kiVLSPxjE70MPS a7vtFjLhcD6iKHLzuEL5pRkkeLNhhuF9+j3u8CNFySmVOht8JQSkWAmzMxIM+RQfxrHPo3Wf Q+skUYca3N3eSeHTwxwtTI6xULBEKMSlOzR4GSHoB5T7fKQUnSB93eVHlanOlcnT9ynzn6KM 3xBlJj+myXfLUb2QY6w+KMdE4R9S4iNkX4vytUfTv34YQyl6QQVpkeTo1X3UnxXiGaoiSDjk 0D4nTREqkYD52f6esePiVMnP7UGdPb/QC9n0RV/h8yKFnvbsOPV+7Bj8z8CKqO2/AgwATZqo 5g0KZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDMxNDY+PnN0cmVhbQ0KaN6UWdt2m0gWffdX1COasQi3EpCnccfuLE3iS2y8emU6/YBQ WaKDQAFkj/sz5otnnzoFAqL09KysREhUnTrXffapvHn/4IpNc/ZTcvYmSTzhiuTpLBYO/sRC enYQiEVsh4Hji2R35ojN2dx2HCcUSYZvycvZr9ZF26rZ3LelVbZ5Vb6d/Zb8k4QFLCyw/WgR Ql5yeUZbfdpq60/aLZJt3ojZwl5Y+Cyrlp9TsT+sZqFV5FlKUsUuXSst2fVsP+jFuTGJI52k ZwSmz2kOGYFVpKtZBFnFbG77lhJtJWZzEt5u9e/KfKWT9Lo8m0k7tM7F6gA1jBnGJ65ru+ZY 7YFFZ0bMx6alyMtW1WVasAXL5HGeiMsqO+xU2U6cQkZI3/+xV0hWuYYD1FpUZfEqnqpaHBol yCmvpHdgiXarWM154NieJ+bQkaQa13QquiELvZ4FtmshVq7tWTso6VqrmUuOqMUD3gVWC0/B 961qZq5jR5ao4BjfesIq3xKw6BzLYkus9M9QQ0KGWM5C/Jhgb2zBZvgQO1mgytqq1q/Fn5yu FzT6vUjLtbjgZ/630ouyPIXcTsNOv3NarnUROqaIcm6OqxVv3/MZenPGh7f5M68VvMRY/fTE O3uRmd7E5xdIJmNJCpOMsnlpDtfmbPmovB57BKpoQUXKy4wL1jpy0rXjPhGcvqosMUt+P5t3 bymwAYqIA+ubJHmp6q+2WLai2aZFgdqB+NBqxUrpajGFhGqA7oX52lbnnDIuouQPMzA22eIF XUIj/bCDsm7Nm1f6Bx129v3wOy+pEIdQOxw6x1Yt9qOv+OIhrj75tWwEchq1kbc5BxQeZd1g RzzUTXa6RcbyvN1WqFF9mIdA7mucHll5xZ/ipc6BSiXrlOEoHGMUfBK6Mm0+KbR/4Pur5CyI AV0iRCiFHUT0F7WEaJ49DV8FMcR6o7cykDbgyOwM4/jU5mBBOEaCfdeWi+9fkWA3OCW426ol D3afej3cDpDvoR0uFn5kuxEjOxuNGDieXsFPelUopR0veBmhiYkFBYVisbxJAElXyH3Xur9B XSysi2SJz9C61d9uLj4iSohtcsUPV+/4xTXyIDb/Pt4s381gvHVBmRKgdmilEcNSxSOL4wWj E/j9FLEXvTH6KfAcO0RUJLBy0fWzPugPyePlZ+0Dv9+mn4JQ0sdwm3HWVH4Y2ZN17+9vH+9O CZU+tgR/Qaj0Y0L20ULvpEQdKg99zCyjLuXqYFlwPHx+fU1ORmxub/RRDvcLz+17WtD1UsfU 2UNycXN5cX+5/NfMpbrSwQktLeLh6l1yey+mje1UBi1iOVILBpluF3bnPF7O5hTEz+Lu6l7D 5BIZJRFg/fPljGIuPMchsPGseE6/S8tzXP7B+y76sY3s14rop8AJtSM9z3a9PpkHRMZKLkXo ii/W3cermzfel5nxcidFPwWhZ8ceDDr6ucdObZmWdFVuirzZ6satcRxnujImf8swDrr+rGNz W+ebHKThrTC79LHGhZ3/JLruQOlowL4+HVRDBAk1+MVqvszeTiMCAQADx+2w9BhkA/TuGzhv 7sZhIK33qlTP6blAE7hO62w798TFvs4L8nysBQMXpW9H8AFcAU0IpeByW/YQM4hBb4bnoQNi jy9778+HtKfjPcnV9d3t/cX9Z3F5++7x+grYAmbpm9qeu4EN4gU3LqTBbKrc6lBn6q3O6f/D 7IumqcAqWiXugTWBlaJbR9Z+X9WtOtTn4pOtHTPOqrkWSwos+qqRgxTK20K9HSsCpjdsMVzm 4EZup50uVE6cj3maNyC7YKrLq+RncXm/vPnwIH41Er2+xuKgF4ltl+MTCeXGbX1unrA2bVPN JcciPZAB+V0jvP+BXEul2TZd5UXevgo01LEseVy3nAjw40lPt4gyv2nrdD6W4aNWh/oA4n9s ok4iS7XgQ1OrvKhfxqBDngjZ2R/AUUdCkcTRkeG7/tERy7vfmJB5se0yHZPd6b1YU/y/gJXl 5Ua8r6vDHhAgUnEo828H1c0HVK0YEsAKqdLBjtyjKX2WEnmHsEbntg7YpqhW2Pag6uccP93V 1XO+VhzIOYvp9ZoPSmq5Jor1xHMUiKhvlQC5h7vl5ZfZNL1BZjFFkNvkd4OOs2B5H5cXywfC f0JgatSEzBcoXBSrGEOElKEdRiLyiNT0EOGKXJx9Ey5jA4CVAETKmIKV7fSvu7PA1RIcUXSP BJ745nQPT2efCG0mUCnR5KMBVLp9dFxW/2e4Ms30SNlWAI2577jSGlbbOIDaIueIOSexhIRm 1W6nQEQ85LQR7S4iaaAr+dugsHhDXiKsu3SginQHy/vMhpdlrBuldbHfI+zULHTYzSqXV4V+ bGbRS5Wui7wEJt5Uz2q3oiwJMMNbhOIDi7zwGGbvmO3vqrKFi/4HovaeNY79kNYg3NeHYjWj ma5+nXWUzJkk5uJ41I06PLQpJ7GL7AMqDGvreIYhCoki2+GqWNKs9XdXyNCdSy+chx6Y9PQ4 KvtFX/Ymga92NGsA8HPtR10B75qFyBqTkU1WAoD8aVma0H0lO+0dBj/PgrFk6T9KdWhghr3K /zAqbOjCIPCOcMJwJ7rZ4sSJaKTxQgSuZqmuHxJBtGVMJF7XDQnlugrwMjjVekfsPnDoUmDC GsgjhrjfFSptlFhX5X802TYDEpC93CgerSTNyG190I9Ze6gVwb15lTeixWDZzVHh6D4j7A4z TlfnLP13OAqZ39DQT4M3cTwWGOCskj9nRJisTDVNWpvrDmtYLnqVPQusCd4ETqTHp79ESXgC CgM7CgaExD3m5k9p9nUDDCjXk0JgNAhGjWxu7qJ0+R1qwg+6ndEkSpMnseM7B9Xi3bn4Zmhb I14UvFqn2hKAlx8N+96RjMPdGMNrtUnrdSc9qxXDB4LSdxnuUyxo1Kj8ScFO25HpNeAeK8VD /6jtcJwjEBc5aJLm0m3Sk6Y9Jxj0HFuIpFqnr4JIRMfrWGyvLkb2Q9nWr/o2KG8bUe1Vre9d xDZ9Rs4qQ869gS4eE5xnVWD1WjSmUe47pWCMEaM3A6k7S0Zt3NWYbgGfjREKp7bbtBUpBUpl 1abM/1Br42ik4uJHjuYWTDcp7E+6tshLbdQKdEUBL0tNW7422td0okHC2DuhmmO83bu2FPtD va8a1ZxT3JBiRGNdCm2amwvJrCpLxQ2vd3bsjTUO+/nF4Gxa10ABfRuqKHEBBGWLQ1TZEAhk lX5VwxutQIlQTmuzzFrVdtkigwmKDphEZ7xI12ukX0NCavXtkNeK4ZXOtMUvM1ADaztDFuUF 3XxGdJe7VY06GiQDviM7NhlTi11aN0L9O9fQo3Wka0VUI37gTMsVxVi96hjTJTQsYxNiO4gH Sdaxqi4JuDwKbGy4BJ+RLqiXLmEp68hMjZhkq1GZxY76ouTEO6adLY5z+kIOeSlNPe89CFbr hgKPGCMERDFRK3n5DGzhMdKOFkPlu7m7S6R8w1k0hpW10jW045s7sBmCFwSXjtN5mpbi5v1N Bw3GIj6rt2jIdqjwh0Fusq0i6VF3F0oGNFSk9PY5rfPqYAKWd7gYDP4LYULqLGxaJo/iGOuU YLUoujst71jnbl9MC+OD1HiMr5fzDdqUhympcwZb5+umPD/JTTo83VctRQ4eGTgw7h0I9730 k8AgxhMK7hyny/Fwib6SN9kBHkQDpIve6aA/aUvTuWSUMBjyiwPNvuv86QkNiHTccz/iC2MD Q0EgT7ndoATdKlM+DJKGhoLYGlt+zBZ+S+2EMuKI/cGfIyiCNE2eiC/S6b4+L7Pi0CfvE0hN fhxNs7or4272HMy3isPMoekr2cSob4hpUWERYbeZtbSskb49BeguRUmTtLtgWCP3ufvnfH9W IrGBDsAKsUfaSatmIlQR5dH3mmRaaDUdHHZoGnpjJBrdnawpsDg035QGiwlzUhZdpuB0zQEd N+0ts4U4xoDTe3GCeh/TB4wvLZqK+wowBpYBT8lW+p+pDGyy0Sej5Xb5M2yxUS/SeCmjqrMa NeivA6e9oJuR08EOpcZ8zDLgSeQelLae2E6zh1MQYWY73W6obRIpoEqi+CNN1qnhBCO8dHlv m+qS4dbHmpavJl8MwkTOEGb5Zo+TvKmKg8ZY8EhV90DHuMsUQtqL8M+1X72Kof+zqiK0Zi/B RR3WOyf5DMdPh0mbrxV5AQGDIeRFu5tJ/ivAAFJEiKkNCmVuZHN0cmVhbQ1lbmRvYmoNMTkg MCBvYmoNPDwvQWx0ZXJuYXRlL0RldmljZVJHQi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDI1OTcvTiAzPj5zdHJlYW0NCmjenJZ3VFTXFofPvXd6oc0w0hl6ky4wgPQuIB0EURhmBhjK AMMMTWyIqEBEEREBRZCggAGjoUisiGIhKKhgD0gQUGIwiqioZEbWSnx5ee/l5ffHvd/aZ+9z 99l7n7UuACRPHy4vBZYCIJkn4Ad6ONNXhUfQsf0ABniAAaYAMFnpqb5B7sFAJC83F3q6yAn8 i94MAUj8vmXo6U+ng/9P0qxUvgAAyF/E5mxOOkvE+SJOyhSkiu0zIqbGJIoZRomZL0pQxHJi jlvkpZ99FtlRzOxkHlvE4pxT2clsMfeIeHuGkCNixEfEBRlcTqaIb4tYM0mYzBXxW3FsMoeZ DgCKJLYLOKx4EZuImMQPDnQR8XIAcKS4LzjmCxZwsgTiQ7mkpGbzuXHxArouS49uam3NoHty MpM4AoGhP5OVyOSz6S4pyalMXjYAi2f+LBlxbemiIluaWltaGpoZmX5RqP+6+Dcl7u0ivQr4 3DOI1veH7a/8UuoAYMyKarPrD1vMfgA6tgIgd/8Pm+YhACRFfWu/8cV5aOJ5iRcIUm2MjTMz M424HJaRuKC/6386/A198T0j8Xa/l4fuyollCpMEdHHdWClJKUI+PT2VyeLQDf88xP848K/z WBrIieXwOTxRRKhoyri8OFG7eWyugJvCo3N5/6mJ/zDsT1qca5Eo9Z8ANcoISN2gAuTnPoCi EAESeVDc9d/75oMPBeKbF6Y6sTj3nwX9+65wifiRzo37HOcSGExnCfkZi2viawnQgAAkARXI AxWgAXSBITADVsAWOAI3sAL4gWAQDtYCFogHyYAPMkEu2AwKQBHYBfaCSlAD6kEjaAEnQAc4 DS6Ay+A6uAnugAdgBIyD52AGvAHzEARhITJEgeQhVUgLMoDMIAZkD7lBPlAgFA5FQ3EQDxJC udAWqAgqhSqhWqgR+hY6BV2ArkID0D1oFJqCfoXewwhMgqmwMqwNG8MM2An2hoPhNXAcnAbn wPnwTrgCroOPwe3wBfg6fAcegZ/DswhAiAgNUUMMEQbigvghEUgswkc2IIVIOVKHtCBdSC9y CxlBppF3KAyKgqKjDFG2KE9UCIqFSkNtQBWjKlFHUe2oHtQt1ChqBvUJTUYroQ3QNmgv9Cp0 HDoTXYAuRzeg29CX0HfQ4+g3GAyGhtHBWGE8MeGYBMw6TDHmAKYVcx4zgBnDzGKxWHmsAdYO 64dlYgXYAux+7DHsOewgdhz7FkfEqeLMcO64CBwPl4crxzXhzuIGcRO4ebwUXgtvg/fDs/HZ +BJ8Pb4LfwM/jp8nSBN0CHaEYEICYTOhgtBCuER4SHhFJBLVidbEACKXuIlYQTxOvEIcJb4j yZD0SS6kSJKQtJN0hHSedI/0ikwma5MdyRFkAXknuZF8kfyY/FaCImEk4SXBltgoUSXRLjEo 8UISL6kl6SS5VjJHslzypOQNyWkpvJS2lIsUU2qDVJXUKalhqVlpirSptJ90snSxdJP0VelJ GayMtoybDFsmX+awzEWZMQpC0aC4UFiULZR6yiXKOBVD1aF6UROoRdRvqP3UGVkZ2WWyobJZ slWyZ2RHaAhNm+ZFS6KV0E7QhmjvlygvcVrCWbJjScuSwSVzcopyjnIcuUK5Vrk7cu/l6fJu 8onyu+U75B8poBT0FQIUMhUOKlxSmFakKtoqshQLFU8o3leClfSVApXWKR1W6lOaVVZR9lBO Vd6vfFF5WoWm4qiSoFKmclZlSpWiaq/KVS1TPaf6jC5Ld6In0SvoPfQZNSU1TzWhWq1av9q8 uo56iHqeeqv6Iw2CBkMjVqNMo1tjRlNV01czV7NZ874WXouhFa+1T6tXa05bRztMe5t2h/ak jpyOl06OTrPOQ12yroNumm6d7m09jB5DL1HvgN5NfVjfQj9ev0r/hgFsYGnANThgMLAUvdR6 KW9p3dJhQ5Khk2GGYbPhqBHNyMcoz6jD6IWxpnGE8W7jXuNPJhYmSSb1Jg9MZUxXmOaZdpn+ aqZvxjKrMrttTjZ3N99o3mn+cpnBMs6yg8vuWlAsfC22WXRbfLS0suRbtlhOWWlaRVtVWw0z qAx/RjHjijXa2tl6o/Vp63c2ljYCmxM2v9ga2ibaNtlOLtdZzllev3zMTt2OaVdrN2JPt4+2 P2Q/4qDmwHSoc3jiqOHIdmxwnHDSc0pwOub0wtnEme/c5jznYuOy3uW8K+Lq4Vro2u8m4xbi Vun22F3dPc692X3Gw8Jjncd5T7Snt+duz2EvZS+WV6PXzAqrFetX9HiTvIO8K72f+Oj78H26 fGHfFb57fB+u1FrJW9nhB/y8/Pb4PfLX8U/z/z4AE+AfUBXwNNA0MDewN4gSFBXUFPQm2Dm4 JPhBiG6IMKQ7VDI0MrQxdC7MNaw0bGSV8ar1q66HK4RzwzsjsBGhEQ0Rs6vdVu9dPR5pEVkQ ObRGZ03WmqtrFdYmrT0TJRnFjDoZjY4Oi26K/sD0Y9YxZ2O8YqpjZlgurH2s52xHdhl7imPH KeVMxNrFlsZOxtnF7YmbineIL4+f5rpwK7kvEzwTahLmEv0SjyQuJIUltSbjkqOTT/FkeIm8 nhSVlKyUgVSD1ILUkTSbtL1pM3xvfkM6lL4mvVNAFf1M9Ql1hVuFoxn2GVUZbzNDM09mSWfx svqy9bN3ZE/kuOd8vQ61jrWuO1ctd3Pu6Hqn9bUboA0xG7o3amzM3zi+yWPT0c2EzYmbf8gz ySvNe70lbEtXvnL+pvyxrR5bmwskCvgFw9tst9VsR23nbu/fYb5j/45PhezCa0UmReVFH4pZ xde+Mv2q4quFnbE7+0ssSw7uwuzi7Rra7bD7aKl0aU7p2B7fPe1l9LLCstd7o/ZeLV9WXrOP sE+4b6TCp6Jzv+b+Xfs/VMZX3qlyrmqtVqreUT13gH1g8KDjwZYa5ZqimveHuIfu1nrUttdp 15UfxhzOOPy0PrS+92vG140NCg1FDR+P8I6MHA082tNo1djYpNRU0gw3C5unjkUeu/mN6zed LYYtta201qLj4Ljw+LNvo78dOuF9ovsk42TLd1rfVbdR2grbofbs9pmO+I6RzvDOgVMrTnV3 2Xa1fW/0/ZHTaqerzsieKTlLOJt/duFczrnZ86nnpy/EXRjrjup+cHHVxds9AT39l7wvXbns fvlir1PvuSt2V05ftbl66hrjWsd1y+vtfRZ9bT9Y/NDWb9nffsPqRudN65tdA8sHzg46DF64 5Xrr8m2v29fvrLwzMBQydHc4cnjkLvvu5L2key/vZ9yff7DpIfph4SOpR+WPlR7X/aj3Y+uI 5ciZUdfRvidBTx6Mscae/5T+04fx/Kfkp+UTqhONk2aTp6fcp24+W/1s/Hnq8/npgp+lf65+ ofviu18cf+mbWTUz/pL/cuHX4lfyr468Xva6e9Z/9vGb5Dfzc4Vv5d8efcd41/s+7P3EfOYH 7IeKj3ofuz55f3q4kLyw8JsAAwD3hPP7DQplbmRzdHJlYW0NZW5kb2JqDTEgMCBvYmoNPDwv Q29udGVudHMgMiAwIFIvQ3JvcEJveFswIDAgNTk1IDg0Ml0vTWVkaWFCb3hbMCAwIDU5NSA4 NDJdL1BhcmVudCAxMiAwIFIvUmVzb3VyY2VzIDkgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+ DWVuZG9iag0yIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzU1Pj5zdHJl YW0NCmjebFRbb9owFH7PrziPjrS4zj153eiqblNVjexpnSYDBryldmcHUPfrd2wngbYDRBLw Of5ux1c3yxR2NnrfRVddV0AK3TZqgeG7haxlNK2gbmvaFCyH7jFisIsoYyyDbu1uciw4Rd9J AhkkcUVLAvGP7lOUZLQs8xySlKZFVUO38GXtWJYVoaxbQJ3CA7mPc1qTL9d3V1lc04o8xHjJ xl5p5vHgpaxoDXWFqFiAM0NJxjvX9Lb7lnSwvMnAiD8HYQcLt9ddXJGPcUoLAouvt3eflzBo eDL6KDcC5GD9ThmjLCtxL4TrOzahI+gnqaRWgJ9hL2CrTZxUtCGPcUP44J6Bw67XK973z7jt Wu+U/Cs2kxihrxOjnKQoZtijFsv72wVwCyfR9+7K1bMnII3AbVANoZDJsMf99vwoYCWECvq0 dMTsuqVT39z3JbARR9HrJwTja0/60COu7lfUoowXheUMqAyAVkKJrUR2RjsAOYHBsa7JPkaf xch3otjQil1QTOaWzMNw7KjfFnOWhZwxwJhgwC6Rkw9arfuDdWqPq4t5dUqrYlpd+bZnr6WF tVaDVAepds5RZGp+o8snbjbW2+b6pQ2t8wuHfX7J2gg+eIO3aORBSczNu4mgN8YKc5RrMUXG +GZJ6PbC13ySMfUyElyMqLYSS7z+a67QuouMeFQZbdr/eJjWwUOuNnCwaOFJDnup/PNKDCeM AEg1dWjKN8QGYZRnhjwUFjhJMAuGD9rY4EeSlbSuX6XzzVCNQ3MOJBFxkhIXSQfGy+JMc+Ij UqRpBVoQxgo7pwEam5n5vsSHEeXgcOT9ga96AVYfTIhnVl/Es54r24AIzdBbf25gxAcu+zHf sp8ymTOaN6+INTOxcba5tdLGJcFs+9PBZ0mdA6TjEgddxfjl9hHGzUJF8DxQ/p+dj5bTxT9K M80kenemzMJmKByepWGSR0/ti9MjhO2cGTpSCf3cAHgmJGS5ouGIHX/8+fLl11x30T8BBgCe zI89DQplbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0Zp cnN0IDQvTGVuZ3RoIDgxL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3rJUMFCwsdF3rShx Dy5JLEkFst2DDRWMjIHiQXZ2+m75eSVAsZAQIwUjU5AYkGmiYGQOlQ4oyk8OTi2J1g9wcdMP Sa0oibWzAwgwAIvzFmENCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvRmlyc3QgMTEvTGVuZ3RoIDQ0L04gMi9UeXBlL09ialN0bT4+c3RyZWFtDQpo 3jI0UDBQMDRUMLRUsLHR9yvNLY4G8w0UgmLt7IBCwfoudnYAAQYAoaAIuQ0KZW5kc3RyZWFt DWVuZG9iag01IDAgb2JqDTw8L0xlbmd0aCAzNjI5L1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRh dGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0 az0iQWRvYmUgWE1QIENvcmUgNC4yLjEtYzA0MyA1Mi4zNzI3MjgsIDIwMDkvMDEvMTgtMTU6 MDg6MDQgICAgICAgICI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9k Yzpmb3JtYXQ+CiAgICAgICAgIDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+TWljcm9zb2Z0IFdv cmQgLSBUMDktU0cwMi0wOTAzMjQtVEQtUExFTi0wMDcxISFNU1ctRS5kb2M8L3JkZjpsaT4K ICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8 ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6 bGk+dHJ1dGtvd3NraTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAg IDwvZGM6Y3JlYXRvcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhtcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDEwLTA1 LTI1VDExOjA3OjMxLTA0OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpDcmVh dG9yVG9vbD5QU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMjwveG1wOkNyZWF0b3JUb29sPgog ICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxMC0wNS0yNVQxMTowNzozMS0wNDowMDwveG1w Ok1vZGlmeURhdGU+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2Ny aXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlz dGlsbGVyIDkuMy4yIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNj cmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg ICAgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAg ICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOjg5MmU1MmI5LTA1YjgtNDVlOS04YmYxLTM4 NmI5ZGVlNzZlNzwveG1wTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNl SUQ+dXVpZDpmZjA3ZjIyMC02NmYwLTQ5YTUtYjA1Ni0zNzZmMTFkNjJhMzg8L3htcE1NOklu c3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4 bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNNiAwIG9iag08PC9G aWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNS9MZW5ndGggNTQvTiAxL1R5cGUvT2JqU3RtPj5z dHJlYW0NCmjeMjRSMFCwsdF3zi/NK1Ew0vfOTCmONjQDCgYpGILIWP2QyoJU/YDE9NRiOzuA AAMAJDMM8A0KZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9GaXJzdCA1L0xlbmd0aCAxOTcvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjefI6xasMw EEB/5TJFGiSf5JjgEgKhDl3qYrCplyyupVIRkSvnM/39eujc/b3HcyUgnE7FZZUvYiW8yp1+ lnvSxTPHSRI9mkmiap48OsTKV87hsXQGD3vE/R+1mV0/c/qWyoac4T3ysplQWW+9LloK/0c6 prDOkdVlZvqYBJq0SMo5MtS2tB5uakyPsI3dtC6GJDmqNm3sQp8CI3EAAwPWpn9Bb7DG0h/M 0Jju9fpmEI9ut2v70VxtoFmfz78CDAAI2Ed6DQplbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoN PDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0ZsYXRl RGVjb2RlL0lEWzxENkJGMTNDM0ZEMkMwRUE2NzA5QjEwNDQ3RjQ4QkFEMj48QkY3MjhDOUQ4 MDAxNUE0NUFDMzY2MDc1REY3MDFDMDA+XS9JbmZvIDEzIDAgUi9MZW5ndGggNTgvUm9vdCAx NSAwIFIvU2l6ZSAxNC9UeXBlL1hSZWYvV1sxIDIgMV0+PnN0cmVhbQ0KaN5iYgACJkZZQQYm BoZ6IMFsASQY14K4nUCCvwrEnQQilIDqzl0HSTCCCAZGIMH0H8wFCDAAw70GJg0KZW5kc3Ry ZWFtDWVuZG9iag1zdGFydHhyZWYNCjExNg0KJSVFT0YNCjEgMCBvYmoNPDwvQW5ub3RzIDI5 IDAgUi9Db250ZW50cyAyIDAgUi9Dcm9wQm94WzAgMCA1OTUgODQyXS9NZWRpYUJveFswIDAg NTk1IDg0Ml0vUGFyZW50IDEyIDAgUi9SZXNvdXJjZXMgOSAwIFIvUm90YXRlIDAvVHlwZS9Q YWdlPj4NZW5kb2JqDTUgMCBvYmoNPDwvTGVuZ3RoIDM3MDEvU3VidHlwZS9YTUwvVHlwZS9N ZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlI enJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA0LjIuMS1jMDQzIDUyLjM3MjcyOCwgMjAwOS8wMS8x OC0xNTowODowNCAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9y Zy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9w ZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFs dD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3Nv ZnQgV29yZCAtIFQwOS1TRzAyLTA5MDMyNC1URC1QTEVOLTAwNzEhIU1TVy1FLmRvYzwvcmRm OmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAg ICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAg PHJkZjpsaT50cnV0a293c2tpPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAg ICAgICAgPC9kYzpjcmVhdG9yPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRw Oi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIw MTAtMDUtMjVUMTE6MDc6MzEtMDQ6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1w OkNyZWF0b3JUb29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94bXA6Q3JlYXRvclRv b2w+CiAgICAgICAgIDx4bXA6TW9kaWZ5RGF0ZT4yMDEwLTA1LTI1VDExOjA4OjAxLTA0OjAw PC94bXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhtcDpNZXRhZGF0YURhdGU+MjAxMC0wNS0y NVQxMTowODowMS0wNDowMDwveG1wOk1ldGFkYXRhRGF0ZT4KICAgICAgPC9yZGY6RGVzY3Jp cHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAg IHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxw ZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0aWxsZXIgOS4zLjIgKFdpbmRvd3MpPC9wZGY6UHJv ZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6ODky ZTUyYjktMDViOC00NWU5LThiZjEtMzg2YjlkZWU3NmU3PC94bXBNTTpEb2N1bWVudElEPgog ICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOmJiMzBhYzhjLThiNTctNDg5Ny05Y2Zk LTg2YzE0MGU1YmI0YjwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRp b24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3Ry ZWFtDWVuZG9iag0yOSAwIG9iag1bMzAgMCBSIDMxIDAgUiAzMiAwIFIgMzMgMCBSXQ1lbmRv YmoNMzAgMCBvYmoNPDwvQVA8PC9OIDM3IDAgUj4+L0NbMS4wIDEuMCAwLjBdL0NyZWF0aW9u RGF0ZShEOjIwMTAwNTI1MTEwNzQ3LTA0JzAwJykvRiA0L00oRDoyMDEwMDUyNTExMDc0Ny0w NCcwMCcpL05NKGYyZGIwNzcyLThlMjItNDFmYy1hMGJhLWFhNDk1MWJlYmVjMCkvUCAxIDAg Ui9Qb3B1cCAzMSAwIFIvUXVhZFBvaW50c1s1Ni43IDc3Mi4xODQgNTI3LjY0OSA3NzIuMTg0 IDU2LjcgNzU2LjQxNiA1MjcuNjQ5IDc1Ni40MTYgNTYuNyA3NTguMzg0IDk1LjcyMzggNzU4 LjM4NCA1Ni43IDc0Mi42MTYgOTUuNzIzOCA3NDIuNjE2XS9SZWN0WzUyLjQ5MDggNzQyLjEy NCA1MzEuODU4IDc3Mi42NzddL1N1YmooSGlnaGxpZ2h0KS9TdWJ0eXBlL0hpZ2hsaWdodC9U KHRydXRrb3dza2kpL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMzEgMCBvYmoNPDwvRiAyOC9PcGVu IGZhbHNlL1BhcmVudCAzMCAwIFIvUmVjdFs1OTUuMCA2NTIuMTg0IDc3NS4wIDc3Mi4xODRd L1N1YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag0zMiAwIG9iag08PC9BUDw8L04g MzQgMCBSPj4vQ1sxLjAgMS4wIDAuMF0vQ3JlYXRpb25EYXRlKEQ6MjAxMDA1MjUxMTA3NTkt MDQnMDAnKS9GIDQvTShEOjIwMTAwNTI1MTEwNzU5LTA0JzAwJykvTk0oZDgyNDYzOWQtNjE3 Zi00YWE0LWExZGMtZWVmZWQ1NWNlMGFlKS9QIDEgMCBSL1BvcHVwIDMzIDAgUi9RdWFkUG9p bnRzWzk4LjcyODYgNzU4LjM4NCA1MTAuMzY1IDc1OC4zODQgOTguNzI4NiA3NDIuNjE2IDUx MC4zNjUgNzQyLjYxNiA1Ni43IDc0NC41ODQgODUuNjc5OCA3NDQuNTg0IDU2LjcgNzI4Ljgx NiA4NS42Nzk4IDcyOC44MTYgNTYuNyA3MTguODkyIDExNC4wNiA3MTguODkyIDU2LjcgNzAy Ljg5NiAxMTQuMDYgNzAyLjg5NiA1Ni43IDY5OC45ODQgNTIyLjc5NyA2OTguOTg0IDU2Ljcg NjgzLjIxNiA1MjIuNzk3IDY4My4yMTYgNTYuNyA2ODUuMTg0IDUxMC4zMzQgNjg1LjE4NCA1 Ni43IDY2OS40MTYgNTEwLjMzNCA2NjkuNDE2IDU2LjcgNjcxLjM4NCA1MTcuMzQ5IDY3MS4z ODQgNTYuNyA2NTUuNjE2IDUxNy4zNDkgNjU1LjYxNiA1Ni43IDY1Ny41ODQgNTAxLjk1IDY1 Ny41ODQgNTYuNyA2NDEuODE2IDUwMS45NSA2NDEuODE2XS9SZWN0WzUyLjQyOTkgNjQxLjMy NCA1MjcuMDA3IDc1OC44NzddL1N1YmooSGlnaGxpZ2h0KS9TdWJ0eXBlL0hpZ2hsaWdodC9U KHRydXRrb3dza2kpL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMzMgMCBvYmoNPDwvRiAyOC9PcGVu IGZhbHNlL1BhcmVudCAzMiAwIFIvUmVjdFs1OTUuMCA2MzguMzg0IDc3NS4wIDc1OC4zODRd L1N1YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag0zNCAwIG9iag08PC9CQm94WzAu MCAwLjAgNDc0LjU3NyAxMTcuNTUzXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlT IGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hP YmplY3Q8PC9NV0ZPRm9ybSAzNSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+ PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMzUgMCBv YmoNPDwvQkJveFswLjAgMC4wIDQ3NC41NzcgMTE3LjU1M10vRm9ybVR5cGUgMS9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAg MC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDM2IDAgUj4+ Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0 cmVhbQ1lbmRvYmoNMzYgMCBvYmoNPDwvQkJveFs1Mi40Mjk5IDY0MS4zMjQgNTI3LjAwNyA3 NTguODc3XS9GaWx0ZXJbL0ZsYXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAzNTYvTWF0 cml4WzEuMCAwLjAgMC4wIDEuMCAtNTIuNDI5OSAtNjQxLjMyNF0vUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckjty xTAIRXuvQitghPgI1pOZpHlp0mT7QbYFfmnP+MIxutiw9fbzdXRwE2m/hxvMYdomD1BUbt+H C3QcGEiBaHhLIAyqc7YMiQEZj/ZxCHYgZSv2CsbQDamCRfbsym2Bj+PzEIXZYgXYpSQjfEna pAFyxjbgDnZOPhPMIJePCeh0K/Q6zIFcqTIJ9tQM7c3LJU7lPuNU14o+wDylxvq6a/ydzpYA BeJefkthDPOxpHD9vrgWewWbYMO9UkX24Mrt7bfY9YbnGjWC8X4tNQV/XkvjJUdeS+MZ/X69 MWD65GLxekNBkPyRSlKDd25vz9dTdeB/PpMA33wMgcsnzo+PNhFzsbtN0v2RSpKDM7e3l4/I 6pekjwbyu4Qb6Lx7eiYmVrsnEJsXW/dB6Cr8SCXJwZnb28uHcXXszYclekilI/Qot8rc5ZaO 4NKpWOh0WWWxRyrJnpuxvXvZ/AkwAPcUzOgNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoN PDwvQkJveFswLjAgMC4wIDQ3OS4zNjcgMzAuNTUzM10vRm9ybVR5cGUgMS9MZW5ndGggMjAv TWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1Nl dFsvUERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gMzggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlw ZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5k b2JqDTM4IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCA0NzkuMzY3IDMwLjU1MzNdL0Zvcm1UeXBl IDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAu MCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9y bSAzOSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0g RG8KDQplbmRzdHJlYW0NZW5kb2JqDTM5IDAgb2JqDTw8L0JCb3hbNTIuNDkwOCA3NDIuMTI0 IDUzMS44NTggNzcyLjY3N10vRmlsdGVyWy9GbGF0ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5n dGggMTQwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTUyLjQ5MDggLTc0Mi4xMjRdL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCkiJXI47EgIhEAVzTjEneMUwX86zVZqsiYnXF0sBNSFoqt80E1Ol+7VU9DSjRzFHUIxX 2ZVuxdr4EaPwCpbWaYOEegS9jWjgVKZjGAHX7JudxYQhbvplbbKGpzevH+Xy6dEG/+tRh/z0 mMJ3jyUktY2NbogmudFZeodqle0sMFeXNC+/Wp4CDAA0UjtaDQplbmRzdHJlYW0NZW5kb2Jq DTQwIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCAyMDEvTiAx L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeZI6xasMwFAB/5WWKNEh+kmNShxAIdchSF4NNvWRx LIWIiKg8P5Pfr4dCh+53x5kcEPb77DjzPZFgmvmRXtMjyOyd/MAhPauBvah2Fg1iYQtjcJsb hZs14vqXWsymHSl8c6FdjPDlaVpMKLTVVmZ1cv8jb/gXaSi5efQkjiOl68BQhYlDjJ6g1Lm2 cBF9eLpl7CJl1gWOXtRhYad0Y+gTOVDQYanaM1qFJeZ2o7pKNR+nT4W4NatV3fbqpF0a5eHw I8AAB+VHeA0KZW5kc3RyZWFtDWVuZG9iag00MSAwIG9iag08PC9EZWNvZGVQYXJtczw8L0Nv bHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEQ2QkYxM0Mz RkQyQzBFQTY3MDlCMTA0NDdGNDhCQUQyPjwwRkM2RTRFNzVENERGNjQ5OEJEM0E5MDE2Q0Ex RTQ4Mj5dL0luZGV4WzEgMSA1IDEgMTMgMSAyOSAxM10vSW5mbyAxMyAwIFIvTGVuZ3RoIDU4 L1ByZXYgMTE2L1Jvb3QgMTUgMCBSL1NpemUgNDIvVHlwZS9YUmVmL1dbMSAyIDBdPj5zdHJl YW0NCmjeYmI0TmFiYOhlYjxrzvTfqRvI1mNiYJoBpPOYGJj3MDEwAmlGaSB+BRS3RbAZU4FY HSDAAFVyCVYNCmVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDQoyMDcwOA0KJSVFT0YNCg== --------------070708080107010805030604-- From root@core3.amsl.com Thu May 27 04:00:01 2010 Return-Path: X-Original-To: enum@ietf.org Delivered-To: enum@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9317C3A6A87; Thu, 27 May 2010 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100527110001.9317C3A6A87@core3.amsl.com> Date: Thu, 27 May 2010 04:00:01 -0700 (PDT) Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-07.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, 27 May 2010 11:00: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 : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-07.txt Pages : 21 Date : 2010-05-27 This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-07.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-3761bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-27035435.I-D@ietf.org> --NextPart-- From lconroy@insensate.co.uk Fri May 28 04:13:46 2010 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 7CEE13A6870 for ; Fri, 28 May 2010 04:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 UouYh4-uADAZ for ; Fri, 28 May 2010 04:13:44 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 4B2143A67B3 for ; Fri, 28 May 2010 04:13:44 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 2A14D169FD5 for ; Fri, 28 May 2010 12:13:33 +0100 (BST) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 May 2010 12:13:32 +0100 Message-Id: <328AFAAB-D292-42A7-865F-604F4002D468@insensate.co.uk> To: IETF ENUM list Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Enum] About RFC 3761bis-07 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, 28 May 2010 11:13:47 -0000 Hi Folks, To explain why we've issued a new version of 3761bis ... Gonzalo provided a detailed review of the current (-6) draft. I do not believe that we have made any changes to the formal text. These changes are intended to clear up some of the text to make it easier to understand (and make it shorter). In response, we produced this new version.=20 - (very slightly) tweaked the text of 1 (intro) to reflect what ENUM does (or doesn't do). i.e. changed the statements that "ENUM stores E.164 numbers in DNS" to "providing storage in DNS associated with E.164 numbers". - changed the Abstract to reflect that. - tweaked the text of 1.2 to try to meet Gonzalo's review comment on it and to make it a bit clearer what is required for non-E.164 numbers - moved the arcane text that was paragraph 2 of section 2's = introduction into its own sub-section at the *end* of section 2 ("Collision = Avoidance"). - removed some text copied from RFC 5483 and replaced with an = informative reference to that RFC. We've also: - swapped around a couple of the items so the ORDER/PREF ones are all together, - have tried to answer Gonzalo's question "why is ORDER/PREF a = problem?" by splitting out the proposed default value as a separate item and putting the (expanded) rest into an indented explanation following = that, - tagged on two items to nail down that you MUST sort using ORDER and PREF, and you SHOULD NOT discard NAPTRs before they have been = considered (unless you have already selected one). - corrected an bad typo in one of the items on ORDER/PREF = (c/highest/lowest/) If there are any outstanding comments, please mail to the list (or the = authors). all the best, Lawrence From bernie@ietf.hoeneisen.ch Fri May 28 08:03:59 2010 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 5A45B3A69FB for ; Fri, 28 May 2010 08:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 ea0bQqOhkCrR for ; Fri, 28 May 2010 08:03:58 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 351D53A6A3E for ; Fri, 28 May 2010 08:03:58 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OI0QK-0006J2-Eq; Fri, 28 May 2010 16:20:32 +0200 Date: Fri, 28 May 2010 16:20:32 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF ENUM list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: 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: Gonzalo Camarillo Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-07.txt (fwd) 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, 28 May 2010 15:03:59 -0000 Hi ENUM:ers As Lawrence already indicated, draft-ietf-enum-3761bis has undergone quite some changes while implementing the AD review feedback. Although these changes are considered editorial only, the ENUM WG should have chance to look over these changes and to object, if needed, before it goes to the IESG. http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-07.txt Please indicate any objections you might have to the latest version of draft-ietf-enum-3761bis no later than Wed, 2 June 2010 noon UT. [In case you need more time, this deadline could be extended on well-grounded request. Beware, that this would add further overall delay in processing the 3 main ENUM WG documents in the AD queue.] cheers, Bernie, Co-chair of the ENUM WG ---------- Forwarded message ---------- Date: Thu, 27 May 2010 13:00:01 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: enum@ietf.org Subject: [Enum] I-D Action:draft-ietf-enum-3761bis-07.txt 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 : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-07.txt Pages : 21 Date : 2010-05-27 This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-07.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. From gonzalo.camarillo@ericsson.com Mon May 31 06:52:45 2010 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 7717B3A697A for ; Mon, 31 May 2010 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.689 X-Spam-Level: X-Spam-Status: No, score=-100.689 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 WSomDW-qZgPL for ; Mon, 31 May 2010 06:52:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id ACED128C0E0 for ; Mon, 31 May 2010 06:52:43 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-5e-4c03bf1f8364 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.57.06817.F1FB30C4; Mon, 31 May 2010 15:52:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 15:52:30 +0200 Received: from [131.160.126.212] ([131.160.126.212]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 15:52:30 +0200 Message-ID: <4C039D12.8080208@ericsson.com> Date: Mon, 31 May 2010 14:27:14 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Lawrence Conroy References: <328AFAAB-D292-42A7-865F-604F4002D468@insensate.co.uk> In-Reply-To: <328AFAAB-D292-42A7-865F-604F4002D468@insensate.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2010 13:52:30.0207 (UTC) FILETIME=[830938F0:01CB00C8] X-Brightmail-Tracker: AAAAAA== Cc: IETF ENUM list Subject: Re: [Enum] About RFC 3761bis-07 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: Mon, 31 May 2010 13:52:45 -0000 Hi Lawrence, thanks for putting this new revision together. I will give the WG a few days to have a look at it in case somebody has comments (I will of course also review this new version). After that, I will advance the three documents in parallel. Thanks, Gonzalo On 28/05/2010 2:13 PM, Lawrence Conroy wrote: > Hi Folks, > To explain why we've issued a new version of 3761bis ... > Gonzalo provided a detailed review of the current (-6) draft. > > I do not believe that we have made any changes to the formal text. > These changes are intended to clear up some of the text > to make it easier to understand (and make it shorter). > > In response, we produced this new version. > - (very slightly) tweaked the text of 1 (intro) to reflect what ENUM > does (or doesn't do). i.e. changed the statements that "ENUM stores > E.164 numbers in DNS" to "providing storage in DNS associated with > E.164 numbers". > - changed the Abstract to reflect that. > - tweaked the text of 1.2 to try to meet Gonzalo's review comment on it > and to make it a bit clearer what is required for non-E.164 numbers > - moved the arcane text that was paragraph 2 of section 2's introduction > into its own sub-section at the *end* of section 2 ("Collision Avoidance"). > - removed some text copied from RFC 5483 and replaced with an informative > reference to that RFC. > > We've also: > - swapped around a couple of the items so the ORDER/PREF ones are all > together, > - have tried to answer Gonzalo's question "why is ORDER/PREF a problem?" > by splitting out the proposed default value as a separate item and > putting the (expanded) rest into an indented explanation following that, > - tagged on two items to nail down that you MUST sort using ORDER and > PREF, and you SHOULD NOT discard NAPTRs before they have been considered > (unless you have already selected one). > - corrected an bad typo in one of the items on ORDER/PREF (c/highest/lowest/) > > > If there are any outstanding comments, please mail to the list (or the authors). > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum >