From enum-bounces@ietf.org Wed Aug 02 16:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8NBP-000058-5f; Wed, 02 Aug 2006 16:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8NBJ-0008Lf-Rz; Wed, 02 Aug 2006 16:19:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8NBJ-0002EA-QJ; Wed, 02 Aug 2006 16:19:05 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8Mjg-0008M0-Bs; Wed, 02 Aug 2006 15:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 276DF17631; Wed, 2 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G8MjB-00010q-PZ; Wed, 02 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 02 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-branch-location-record-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-ietf-enum-branch-location-record-00.txt Pages : 7 Date : 2006-8-2 This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the infrastructure ENUM tree location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-branch-location-record-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-branch-location-record-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-2135853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-branch-location-record-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-branch-location-record-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-2135853.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Aug 03 21:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ox6-0001EY-E3; Thu, 03 Aug 2006 21:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8ox5-0001EM-I1; Thu, 03 Aug 2006 21:58:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8m6e-0002Yt-Fl; Thu, 03 Aug 2006 18:55:56 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8m1Q-00082S-SB; Thu, 03 Aug 2006 18:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9CE8A1766C; Thu, 3 Aug 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G8m0w-0002bE-8t; Thu, 03 Aug 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 03 Aug 2006 18:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-03.txt Pages : 10 Date : 2006-8-3 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3761. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-vcard-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-vcard-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-3170251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-3170251.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Aug 04 08:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zFJ-0001oT-FP; Fri, 04 Aug 2006 08:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zFI-0001o4-8x for enum@ietf.org; Fri, 04 Aug 2006 08:57:44 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8zFG-0002y0-Sh for enum@ietf.org; Fri, 04 Aug 2006 08:57:44 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k74Cw0dr014571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Aug 2006 05:58:01 -0700 From: "Richard Shockey" To: Date: Fri, 4 Aug 2006 08:57:34 -0400 Message-ID: <017901c6b7c5$8f4bfd00$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: Aca3xY1iIc3tIYqQTKyYngbYZG9Jtg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM Working Group Last Call on document draft-ietf-enum-vcard-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-03.txt Pages : 10 Date : 2006-8-3 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3761. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-03.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks or so from today August 4 until at least August 21 though we can modify that if new issues come up. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 07 16:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABIm-0005Xp-BN; Mon, 07 Aug 2006 16:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GABIk-0005Wk-CE; Mon, 07 Aug 2006 16:02:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABIk-0002IL-AG; Mon, 07 Aug 2006 16:02:14 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAB7Q-0001Qu-SH; Mon, 07 Aug 2006 15:50:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A731E175A6; Mon, 7 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAB6w-0006Gg-Aa; Mon, 07 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 07 Aug 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-combined-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-ietf-enum-combined-00.txt Pages : 11 Date : 2006-8-7 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after deployment of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-combined-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-combined-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-7140839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-combined-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-combined-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-7140839.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Aug 07 17:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACyx-0007um-LC; Mon, 07 Aug 2006 17:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACyv-0007uc-Mr for enum@ietf.org; Mon, 07 Aug 2006 17:49:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABnt-0002qL-J6 for enum@ietf.org; Mon, 07 Aug 2006 16:34:25 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GABj5-0003IM-Mv for enum@ietf.org; Mon, 07 Aug 2006 16:29:29 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k77Kcl8x008344; Mon, 7 Aug 2006 16:38:47 -0400 Received: from trutkowski-desk.verisign.com ([10.169.65.98]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 16:29:24 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.4 (Beta) Date: Mon, 07 Aug 2006 16:29:23 -0400 To: mah@inode.at, richard.stastny@oefeg.at From: Tony Rutkowski Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-combined-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2006 20:29:25.0035 (UTC) FILETIME=[2C59D7B0:01C6BA60] X-Spam-Score: -2.6 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Curious minds want to know, 1) since E.164 is the ITU-T's namespace at the top level, and 2) the requirement is for a pointer to infrastructure provider resolvers of that namespace pursuant to national law, why isn't this treated like the countless other ITU-T namespaces where the ITU TSB simply publishes pointers to the authoritative infrastructure resolvers for the infrastructure community? Or is that the intent? --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 07 17:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAD3k-0003vx-Nz; Mon, 07 Aug 2006 17:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAD3h-0003qI-Hh; Mon, 07 Aug 2006 17:54:49 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAD3h-0007SO-AX; Mon, 07 Aug 2006 17:54:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EE19D26E15; Mon, 7 Aug 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAB6v-0006Fr-Ru; Mon, 07 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 07 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-pstn-05.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 : IANA Registration for an Enumservice Containing PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-ietf-enum-pstn-05.txt Pages : 12 Date : 2006-8-7 This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-pstn-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-pstn-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-7130103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-pstn-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-pstn-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-7130103.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Aug 08 03:22:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GALug-0006Id-Aw; Tue, 08 Aug 2006 03:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GALue-0006IY-8y for enum@ietf.org; Tue, 08 Aug 2006 03:22:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GALuc-0002gk-SZ for enum@ietf.org; Tue, 08 Aug 2006 03:22:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-combined-00.txt Date: Tue, 8 Aug 2006 09:21:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C50A7@oefeg-s04.oefeg.loc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-combined-00.txt Thread-Index: Aca6a1ayA+zKvE5lRX+xVzRad2m3rQAT1Dqw From: "Stastny Richard" To: "Tony Rutkowski" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony, as you mention in your point 2, the split and its location is a national matter. The introduction of the BLR is also a national matter, because it is on the level of tier 1. So the ITU TSB is not involved at all Of course it would be nice and useful if the ITU TSB publishes the data also on a website. But it would be not necessary. Richard > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Monday, August 07, 2006 10:29 PM > To: mah@inode.at; Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-combined-00.txt >=20 > Curious minds want to know, >=20 > 1) since E.164 is the ITU-T's namespace at the > top level, and > 2) the requirement is for a pointer to infrastructure > provider resolvers of that namespace pursuant to > national law, >=20 > why isn't this treated like the countless other ITU-T > namespaces where the ITU TSB simply publishes pointers > to the authoritative infrastructure resolvers for the > infrastructure community? Or is that the intent? >=20 > --tony >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 08 15:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXam-00036X-Cj; Tue, 08 Aug 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXaV-0002Xn-Cl; Tue, 08 Aug 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0001vA-5G; Tue, 08 Aug 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1FCF726E2E; Tue, 8 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAXaT-0005dg-VP; Tue, 08 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 : Infrastrucure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-enum-reqs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-8131207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-enum-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-8131207.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Aug 08 15:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXgb-0002TF-Dc; Tue, 08 Aug 2006 15:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXga-0002T5-7N for enum@ietf.org; Tue, 08 Aug 2006 15:56:20 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GAXgX-0002wC-QS for enum@ietf.org; Tue, 08 Aug 2006 15:56:20 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1155066974!11394312!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11018 invoked from network); 8 Aug 2006 19:56:14 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 8 Aug 2006 19:56:14 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44BA63B2003915AC for enum@ietf.org; Tue, 8 Aug 2006 15:56:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-03.txt Date: Tue, 8 Aug 2006 15:56:12 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0D6477A3@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-03.txt Thread-Index: Aca7I+7odL7hAb8qShiLsPMsO1gqUAAAE1bg From: "Pfautz, Penn L, GBLAM" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This draft reflects the changes agreed to in Montreal as well as some comments from A-D review (note it is now Informational) Penn -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, August 08, 2006 3:50 PM To: i-d-announce@ietf.org Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-03.txt=20 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 : Infrastrucure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 =09 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum- reqs-03.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-infrastructure-enum-reqs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-03.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 08 16:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYPQ-0005hX-Ml; Tue, 08 Aug 2006 16:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAYPP-0005hS-H3 for enum@ietf.org; Tue, 08 Aug 2006 16:42:39 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAYPM-0005E7-8S for enum@ietf.org; Tue, 08 Aug 2006 16:42:39 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k78Kq66R019543; Tue, 8 Aug 2006 16:52:07 -0400 Received: from trutkowski-desk.verisign.com ([10.169.65.98]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 16:42:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.4 (Beta) Date: Tue, 08 Aug 2006 16:42:32 -0400 To: "Pfautz, Penn L, GBLAM" , From: Tony Rutkowski Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-enum-reqs-03.txt In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0D6477A3@ACCLUST02EVS1.ugd .att.com> References: <34DA635B184A644DA4588E260EC0A25A0D6477A3@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2006 20:42:32.0627 (UTC) FILETIME=[2C349830:01C6BB2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mdolly@att.com, faynberg@bell-labs.com X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Penn, Would you be amenable to adding a bullet 4bis in section 3 that reads: 4bis Infrastructure ENUM MUST be able to support an E.115-2006 [6] capability that allows qualified parties to obtain information regarding any specific E.164 numbering resource and associated subscriber information for the resource. Determination of what information, if any, shall be available to which parties is a national matter. and section 6 that reads: [6] International Telecommunication Union-Telecommunication Standardization Sector, "Computerized directory assistance," Recommendation E.115 (Feb 2006), as corrected or amended. See also, Rec. Y.2071, "Security Requirements for NGN Release 1." The new version of E.115 is a highly flexible XML based query-response mechanism for controlled access to authoritative subscriber information that is essential to meet new Identity Management requirements that have emerged in Q.15/13's new Rec. Y.2071. This change is compatible with the IRIS requirement - which provides for the ability to discover authoritative provider information. E.115 in turn provides for the ability to discover authoritative subscriber information while protecting privacy. best, tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 09 12:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArD1-0007zB-QQ; Wed, 09 Aug 2006 12:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArCz-0007xB-Lf; Wed, 09 Aug 2006 12:47:05 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GArCx-0006es-7x; Wed, 09 Aug 2006 12:47:05 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k79GlDOb003233; Wed, 9 Aug 2006 09:47:18 -0700 From: "Richard Shockey" To: , Date: Wed, 9 Aug 2006 12:46:51 -0400 Message-ID: <00ee01c6bbd3$6d09f320$7b201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca702mENXL9DZxEQ/2M5JBgNzpfYg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , 'Jon Peterson' Subject: [Enum] Request for Publication - draft-ietf-enum-validation-token-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-02.txt Pages : 16 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-02.txt This document has been extensively discussed in the WG in 2005 and 2006 This is a request for publication for one IETF ENUM WG working group document. A two week WG last call on this document concluded on August 1, 2006. There were no additional comments from the last call. The document listed above is intended to be a Proposed Standard. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 14 13:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfsD-0003fr-QF; Mon, 14 Aug 2006 13:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfsC-0003fl-5h; Mon, 14 Aug 2006 13:05:08 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCfsA-0001pA-La; Mon, 14 Aug 2006 13:05:08 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7EH5IID021415; Mon, 14 Aug 2006 10:05:24 -0700 From: "Richard Shockey" To: , Date: Mon, 14 Aug 2006 13:04:43 -0400 Message-ID: <004601c6bfc3$c2206a30$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca/w7xVc6RKk0RyTM6DI0paNIyt7g== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , 'Jon Peterson' Subject: [Enum] Request for Publication - draft-ietf-enum-calendar-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-ietf-enum-calendar-service-01.txt Pages : 6 Date : 2006-7-6 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt This is a request for publication for one IETF ENUM WG working group document. A three week WG last call on this document concluded on August 14, 2006. The document above is intended to be a Proposed Standard. There were no additional comments from the last call. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 14 13:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCft0-00045D-BY; Mon, 14 Aug 2006 13:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfsy-000456-DY; Mon, 14 Aug 2006 13:05:56 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCfsx-0001qj-0X; Mon, 14 Aug 2006 13:05:56 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7EH5xbJ021466; Mon, 14 Aug 2006 10:06:04 -0700 From: "Richard Shockey" To: , Date: Mon, 14 Aug 2006 13:05:26 -0400 Message-ID: <004701c6bfc3$d9c23830$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca/w9YdMF5vyrP8RPGUeGsHS7APZg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: fluffy@cisco.com, =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Peterson, Jon'" Subject: [Enum] Request for Publication - draft-ietf-enum-im-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-01.txt This is a request for publication for one IETF ENUM WG working group document. A three week WG last call on this document concluded on August 14, 2006. The document above is intended to be a Proposed Standard. There were no additional comments from the last call. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 14 15:45:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiNM-00087A-5v; Mon, 14 Aug 2006 15:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiNK-000874-GI for enum@ietf.org; Mon, 14 Aug 2006 15:45:26 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCiNI-00082b-2d for enum@ietf.org; Mon, 14 Aug 2006 15:45:26 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7EJjagl009460 for ; Mon, 14 Aug 2006 12:45:42 -0700 From: "Richard Shockey" To: Date: Mon, 14 Aug 2006 15:45:06 -0400 Message-ID: <009e01c6bfda$28892490$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawI6XhEuv/FUYCQ5C5CmYwZUTg0gPtdAlg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Enum] Wanting to go to WGLC on draft-ietf-enum-cnam-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I'm readying one more iteration of this draft that includes several useful but minor editorial comments. To those who have commented in the past thanks! I would appreciate it anyone who has additional comments on this draft please do so here on the list ASAP. I'd like to go to Working Group Last call pretty soon. > 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 : IANA Registration for an Enumservice Calling > Name Delivery (CNAM) Information and IANA > Registration for Media type application/cnam > Author(s) : R. Shockey, et al. > Filename : draft-ietf-enum-cnam-02.txt > Pages : 13 > Date : 2006-7-25 > > This document registers the Enumservice 'pstn' and the compound > subtype 'cnam' using the URI scheme 'data:', as per the IANA > registration process defined in the ENUM specification, RFC 3761 and > creates a new media type application/cnam.. > > This data is used to facilitate the transfer of Calling Name Delivery > (CNAM) data for calls that originate on the Public Switched Telephone > Network (PSTN) that may be displayed on VoIP or other Real-time > Client User Agents (CUA). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 16 10:33:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDMQN-0007X5-MK; Wed, 16 Aug 2006 10:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDMQM-0007Wx-Kl for enum@ietf.org; Wed, 16 Aug 2006 10:31:14 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDMQK-0004fq-48 for enum@ietf.org; Wed, 16 Aug 2006 10:31:14 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 16 Aug 2006 16:30:45 +0200 id 0007C091.44E32C16.00006BA3 Message-ID: <44E32BD6.5090109@enum.at> Date: Wed, 16 Aug 2006 16:29:42 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: enum@ietf.org, Richard Shockey , "Livingood, Jason" , kmccandless@verisign.com, mmaharashi@verisign.com References: <447ADA13.2000900@enum.at> In-Reply-To: <447ADA13.2000900@enum.at> X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Subject: [Enum] review of draft-ietf-enum-cnam-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org [I'm quoting my previous review because a lot of issues still apply to t= he 02 version - _please_ either fix them or at least comment on them] Alexander Mayrhofer wrote: > - NITS: the online idnitsw checker reports two problems: > - page breaks (pages don't break properly) > - usage of FQDNs which are not "example.(com|net.org)" > (and a few experimental warnings) The FQDNs are fixed - however, a lot of non-ASCII characters have been introduced (=B4 and `), one of the pages is too long, the pages still do= n't break properly. please see the online idnits checker & fix accordingly. There are a few unused references as well. The abstract still says "compound subtype", but the Enumservice now uses= a "common" (?) subtype. The ToC contains two lines without section numbers - looks like a format= ting problem. There's some "funny numbering": sub-sections "12.1" and "12.2"= are grouped under section "11", and section "12" follows those two sub-secti= ons... > - Minor formatting issues: Personally, i'd prefer to have eg. the medi= a type > always surrounded by single quotes (eg. at the end of the first senten= ce of > the abstract, i got confused whether the first of the two dots is to b= e part > of the media type...). Same applies to Enumservice types, subtypes, > parameter names, parameter values still applies to the media type in the abstract. i'm still confused whet= her one or both of the dots are part of the media type. "NAPTR" in the Introduction should be expanded on its first use. > - Section 4: This specifies the length of "Caller Display Name" to 15 > digits, and calls it "CNAM Data" in the section title. However, later = in the > document, the contents of the data-URI is recommended to be shorter th= an 64 > digits. Therefore, there is a definition clash what "CNAM data" is - i= s it > the "Caller Display Name" as defined in the PSTN, or is it the content= s of > the URI? Especially with section 6, which specifies a different format= for > "structure of CNAM data" - probably that should be renamed to "structu= re of > CNAM data URI" or something like this... is now section 3 and section 4 - the terminology clash still applies. "Definition of CNAM data" does not fit "Structure of CNAM data" - so, on= e of those has to be renamed. > - Section 6: I don't think that the ABNF of the "data:" URI adds any v= alue > here (btw, the normative reference to ABNF is missing). However, an AB= NF of > a valid "application/cnam" URI would definitely add value here (which = means > fixing the media type, and proably add a length limit to the data itse= lf). > That would also provide a definition of a "CNAM data URI", which could= be > used to distinguish NAPTR payload from the "Caller Name Display" type = of > definition (as mentioned above). still applies, but now section 4. Section 4: > ... In addition, the "options" defined here seem to be "parameter > values" for the "unavailable" parameter - terminology problem. A sente= nce > that no other parameter values for unavailable as well as no other > parameters are allowed could be added, and the parameter definition co= uld be > provided in ABNF (and referenced in the ABNF above). The text still says twice "this parameter ..." when it actually talks ab= out the "options" or "values" 'p' and 'u' to the single "unavailable" URI parameter. > Generally, i'd go for a section like > > x. The 'CNAM' data URI > x.1 Formal Definition > (abnf) > x.2 Media Type Definition 'application/cnam' > (type) > x.3 Media Type Parameter 'unavailable' > (parameter def) thats still my (strictly personal, of course) opinion. > - Section 7: [PII] looks like a reference to me, although it's an > abbreviation, and it's only used once (in the next sentence) (PII) would be better, since all abbreviations are in round parenthesis. > - Section 9: Could be renamed to "Example Call Flow". Unsure what the > "Dialed number" string before the list should mean. the "dialed number" stuff is still there. > -- Bullet e) I think the originating users' phone number does not > neccessarily come from the From: field - P-Asserted-Identity comes to = my mind... still not sure - any SIP gurus? > -- Bullet f) still talks about "tel-URI containing CNAM data" - remain= s of > the first version... still there. Breaks the whole example & makes it useless. please fix! > - Section 10. proxy's -> proxies - The only sentence in this section i= s > incomplete & confusing. (now section 7) still incomplete and confusing. > - Section 14: the definition of parameters / values is confusing. > "unavailable" seems to be an optional _parameter_, while "p" and "u" s= eem to > be _parameter values_ to that parameter. There is a bug around line 6 = of > page 8 - i think that sentence should read "This parameter .... define= d as > data is NOT available for that ..." ("NOT" is missing). Interobability > considerations: I'm pretty sure that usage of this media type is _not_ > specified in RFC3761 - that should be changed into a placeholder for t= he > memo itself (eg. RFC XXXX). There is a typo in the last sentence of th= e > section ("enum@ierf.org" should read "enum@ietf.org"). is now section 12.2 (or, whatever). The "unavailable" parameter is still listed as "Required parameters" in the template, but the text and exampl= es indicate that the parameter is optional. The typo in the mail address still persists. new stuff: - DNSSEC is never expanded. - Section 11. refers to section 13 and 14, which don't exist. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 16 18:01:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTQx-0002wx-7G; Wed, 16 Aug 2006 18:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTQv-0002wo-R4; Wed, 16 Aug 2006 18:00:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDTQv-0002yA-La; Wed, 16 Aug 2006 18:00:17 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDTQu-0006C5-2y; Wed, 16 Aug 2006 18:00:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 09EA92AC1A; Wed, 16 Aug 2006 21:59:46 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GDTQP-0007z6-Pe; Wed, 16 Aug 2006 17:59:45 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 16 Aug 2006 17:59:45 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: enum@ietf.org Subject: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'ENUM Validation Architecture ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-03.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 17 16:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDoRC-0001Ek-Jw; Thu, 17 Aug 2006 16:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDoRB-0001AH-3o for enum@ietf.org; Thu, 17 Aug 2006 16:25:57 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDoC5-0000wL-CZ for enum@ietf.org; Thu, 17 Aug 2006 16:10:22 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7HKAK1N022674 for ; Thu, 17 Aug 2006 13:10:26 -0700 From: "Richard Shockey" To: Date: Thu, 17 Aug 2006 16:09:54 -0400 Message-ID: <010501c6c239$1f513d20$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbCNm7TbLpoDNlVQy+vWJPpO4QEpQAApuIA X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Enum] FW: I-D ACTION:draft-reichinger-enum-foaf-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, August 17, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-reichinger-enum-foaf-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Registration for Enumservice foaf > Author(s) : K. Reichinger > Filename : draft-reichinger-enum-foaf-01.txt > Pages : 8 > Date : 2006-8-17 > > This memo registers the Enumservice "foaf" using the URI schemes > "http" and "https" according to the IANA Enumservice registration > process defined in RFC3671. The Enumservice "foaf" is to be used to > refer from an ENUM domain name to the location of a FOAF RDF file > using the corresponding E.164 telephone number. > > Clients may use data retrieved from a FOAF RDF file to provide caller > or callee with information available within the Friend-Of-A-Friend > (FOAF) Semantic Web application. For example, the caller might be > presented with personal information on the callee (e.g. name, gender > and various online attributes) as well as information on the callee's > social context (e.g. relations to friends or colleagues). > Information collected from FOAF can be used before, during or after a > communication is established. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-reichinger-enum-foaf-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-reichinger-enum-foaf-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 21 14:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEqC-0004uK-M0; Mon, 21 Aug 2006 14:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEqA-0004uD-QS; Mon, 21 Aug 2006 14:49:38 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEq8-0000Pd-CA; Mon, 21 Aug 2006 14:49:38 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7LInW2r002577; Mon, 21 Aug 2006 11:49:37 -0700 From: "Richard Shockey" To: , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" Date: Mon, 21 Aug 2006 14:49:07 -0400 Message-ID: <008301c6c552$7ece0960$54201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbFUnrLBPkZlF7gRsid8e2AcnOVEA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: fluffy@cisco.com, enum@ietf.org, "'Peterson, Jon'" Subject: [Enum] Request for Publication - draft-ietf-enum-vcard-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-03.txt Pages : 10 Date : 2006-8-3 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3761. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-03.txt This is a request for publication for one IETF ENUM WG working group document. A three week WG last call on this document concluded on August 21, 2006. The document above is intended to be a Proposed Standard. There were no additional comments from the last call. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 21 18:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIbA-00075N-Bs; Mon, 21 Aug 2006 18:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIat-0006wT-7z; Mon, 21 Aug 2006 18:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFIat-0002RY-55; Mon, 21 Aug 2006 18:50:07 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=ns0.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFIap-0004pm-VH; Mon, 21 Aug 2006 18:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id ED74D3288C; Mon, 21 Aug 2006 22:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GFIan-0002js-QW; Mon, 21 Aug 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 21 Aug 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-cnam-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --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 : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam' Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-03.txt Pages : 13 Date : 2006-8-21 This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'data:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new media type application/cnam [19]. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-cnam-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-cnam-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-21162805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-cnam-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-cnam-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-21162805.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Aug 22 06:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTUF-0002ed-AF; Tue, 22 Aug 2006 06:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTUE-0002eO-9E for enum@ietf.org; Tue, 22 Aug 2006 06:27:58 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFTU9-0006FC-Oo for enum@ietf.org; Tue, 22 Aug 2006 06:27:58 -0400 Received: (eyou send program); Tue, 22 Aug 2006 18:27:41 +0800 Message-ID: <356242461.08427@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.146 with SMTP; Tue, 22 Aug 2006 18:27:41 +0800 Message-ID: <011101c6c5d5$95cf8930$6306e29f@cnnicchenh> From: "chenhui" To: , "IETF-Announce" References: <355765855.19125@cnnic.cn> Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) Date: Tue, 22 Aug 2006 18:27:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.0 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1403211623==" Errors-To: enum-bounces@ietf.org --===============1403211623== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGV4LCBCZXJuaWUgYW5kIGFsbCwNCg0KUXVpdGUgaW1wb3J0YW50IGRyYWZ0IHRvIHBy b21vdGUgRU5VTSBhcHBsaWNhdGlvbiENCg0KV2Ugc3R1ZGllZCB0aGlzIGRyYWZ0IGFuZCBoYWQg YSBkaXNjdXNzaW9uLiBIZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyBhbmQgc3VnZ2VzdGlvbnMgZm9y IHlvdToNCg0KMS4gVGhlIGRhdGEgZmxvdyBvZiB2YWxpZGF0aW9uIHByb2Nlc3Mgc2F5cyAiQSBW YWxpZGF0aW9uIEVudGl0eSBtYXkgY2hvb3NlIHRvIHBlcmZvcm0gYWxsIGNvbW11bmljYXRpb24g d2l0aCB0aGUgQXNzaWduZWUgdmlhIHRoZSByZXF1ZXN0aW5nIFJlZ2lzdHJhciByYXRoZXIgdGhh biBjb250YWN0aW5nIHRoZSBBc3NpZ25lZSBieSBpdHNlbGYuIiBpbiBsYXN0IHBhcmFncmFwaCBv ZiBTZWMgNC4zLCBidXQgYWN0dWFsbHkgRmlndXJlIDQgb2YgU2VjIDUuMiBzaG93cyBWRSBkaXJl Y3RseSBjb21tdW5pY2F0ZXMgd2l0aCBBc3NpZ25lZS4NCiAgIFdlIGFyZSBub3QgY2xlYXIgdGhh dCBob3cgZG9lcyBWRSBkaXJlY3RseSBjb21tdW5jYXRlcyB3aXRoIEFzc2lnbmVlLCBvciB0aGF0 IFZFIGRyYXdzIHRoZSBlZmZlY3RpdmUgdmFsaWRhdGlvbiBpbmZvcmFtdGlvbiBvdXQgb2YgdGhl IEFzc2lnbmVlL1JlZ2lzdHJhbnQncyByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gZnJvbSBSZWdp c3RyYXIuDQoNCjIuIEl0IHNheXMgVkUgcG9zc2VzcyB0aGUgdmFsaWRhdGlvbiBmdW5jdGlvbiwg YnV0IHRoZSBkZXNjcmlwdGlvbiBvZiBWRSBpbiB0aGUgaW1wbGVtZW50YXRpb24gIHNlZW1zIFZF IGlzIG9ubHkgYW4gYWdlbnQgdG8gcHJlZm9ybSB2YWxpZGF0aW9uLCBzdWNoIGFzIEZpZ3VyZSA0 IG9mIFNlYyA1LjIgdGhhdCBWRSBmZXRjaGVzIGluZm9ybWF0aW9uIGZyb20gTkFFIGFuZCBBc3Np Z25lZS4NCi0tLS1zdWdnZXN0aW9uOiBWRSBwb3NzZXNzIHZhbGlkYXRpb24gZGF0YWJhc2UgYXMg dGhlIHRoaXJkIHZhbGlkYXRpb24gY2VudGVyLCBhbmQgbmVlZCBub3QgdG8gaW5xdWlyZSBvZiBv dGhlciBlbnRpdGllcyBhYm91dCB0aGUgYXNzaWduZWUncyBpbmZvcm1hdGlvbiBkdXJpbmcgdmFs aWRhdGlvbiBwcm9jZXNzLg0KDQozLiBTZWMgMiByZXF1aXJlbWVudCBtZW50aW9ucyAicmVjdXJy aW5nIHZhbGlkYXRpb24iIG9yICJyZXZhbGlkYXRpb24iLCBhbmQgU2VjIDQuMSBkZXNjcmliZXMg cmV2YWxpZGF0aW9uIHdvcmtmbG93LiBXZSB0aGluayBpdCBpcyByYXRoZXIgY29tcGxleCB3aGVu IGV4cGlyYXRpb24gb2YgRS4xNjQgbnVtYmVyIGFuZCBleHBpcmF0aW9uIG9mIEVOVU0gZG9tYWlu IG5hbWUgYm90aCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQuDQotLS0tc3VnZ2VzdGlvbjogUGVyaW9k IG9mIEUuMTY0IG51bWJlciB2YWxpZGl0eSBuZWVkIHRvIGJlIHJlZmVyZWQgb25seSB3aGVuIEUu MTY0IG51bWJlciBpcyBhc3NpZ25lZC4gQW5kIGFmdGVyIHJlZ2lzdHJhdGlvbiBvZiBFTlVNIGRv bWFpbiBuYW1lIGFuZCBFTlVNIHNlcnZpY2VzLCBFLjE2NCBudW1iZXIgdmFsaWRpdHkgZXF1YWxz IHRvIEVOVU0gZG9tYWluIG5hbWUvc2VydmljZXMgdmFsaWRpdHkuDQoNCjQuIFRoZSBkaWZmZXJl bnQgZW50aXRpZXMgaGF2ZSBkaWZmZXJlbnQgZGVtYW5kcyBvZiBiZW5lZml0LCBzbyBpdCBpcyBk aWZmaWN1bHQgdG8gbGV2ZWwgdGhlIHJlbGF0aW9uIG9mIGVhY2ggZW50aXRpZXMgaW4gRU5VTSBw cm92aXNpb24gbW9kZWwsIGVzcGVjaWFsbHkgUmVnaXN0cnksIFZhbGlkYXRpb24gRW50aXR5IGFu ZCBOdW1iZXIgQXNzaWdubWVudCBFbnRpdHkuDQotLS0tc3VnZ2VzdGlvbjogUmVnaXN0cnkgaGFz IHRoZSByaWdodCB0byBkZWxlZ2F0ZSBOQUUsIGFuZCBOQUUgaXMgYWxzbyB0aGUgVkUuDQoNClRo ZSBmb2xsb3dpbmcgZmlndXJlIGV4cGxhaW5zIG91ciBwb2ludCBvZiB2aWV3Og0KICAgICAgICAr LS0tLS0tLS0tLSsNCiAgICAgICAgfCBSZWdpc3RyeSB8IFwNCiAgICAgICAgKy0tLS0tLS0tLS0r ICBcIA0KICAgICAgICAgICAgIF4gICAgICAgICBcIA0KICAgICAgICAgICAgIHwgICAgICAgICAg XA0KICAgICAgICAgICAgIHwgICAgICAgICAgIFwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg XCANCiAgICAgICAgICAgICB8ICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICB8ICAgICAgICAg ICAgICBcDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgIFwgDQogICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICBcIA0KICAgICAgICAgICAgIHwoOCkgICAgICAgICAgICAgIFwoOSkNCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgXCANCiAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgIFwNCiAgICAgICAgICAgICB8ICAgICAgICAgICg2KSAgICAgICB2DQogICAgICAg ICstLS0tLS0tLS0tLSsgLS0tLS0tLS0tLT4rLS0tLS0tLS0tKw0KICAgICAgICB8IFJlZ2lzdHJh ciB8PC0tLS0tLS0tLS0gfCBOQU0oVkUpIHwNCiAgICAgICAgKy0tLS0tLS0tLS0tKyAgICg3KSAg ICA+ICstLS0tLS0tLS0rDQogICAgICAgICAgICAgXiAgICAgICAgICAgICAgICAgICAgIF4gIHwN CiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgfA0KICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICB8ICB8DQogICAgICAgICAgICAgfCg1KSAgICAgICAgICAgICAg ICAgIHwgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgKDIpfCAgfA0KICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICB8DQogICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAg fA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICB8KDMpDQogICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgIHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCAgVg0KICAgICAgICstLS0tLS0tLS0tLS0rICAgICg0KSAgICAgKy0tLS0tLS0t LSsgDQogICAgICAgfCBBc3NpZ25lZSA9IHw8LS0tLS0tLS0tLSB8ICBOQUFFICAgfA0KICAgICAg IHwgUmVnaXN0cmFudCB8LS0tLS0tLS0tLT4gfCAgICAgICAgIHwNCiAgICAgICArLS0tLS0tLS0t LS0tKyAgICAoMSkgICAgICstLS0tLS0tLS0rDQoNCiAgICAgICAgIE5BTTogTnVtYmVyIEFzc2ln bm1lbnQgTWFuYWdlbWVudA0KICAgICAgICAgTkFBRTogIE51bWJlciBBc3NpZ25tZW50IEFnZW50 IEVudGl0eQ0KICAgICAgICAgVkU6ICAgVmFsaWRhdGlvbiBFbnRpdHkNCg0KICAgKDEpIFRoZSBB c3NpZ25lZSBhcHBseXMgZm9yIGFuIEUuMTY0IG51bWJlciBmcm9tIE5BQUUgYW5kIHN1Ym1pdHMg cGVyc29uYWwgcGFydGljdWxhciBpbmZvcm1hdGlvbiAuDQogICAoMikgTkFBRSBzZW5kcyBBc3Np Z25lZSdzIGluZm9ybWF0aW9uIGFuZCB0aGUgYXBwbGllZCBFLjE2NCBudW1iZXIgdG8gTkFNLg0K ICAgKDMpIE5BTSBjaGVja3Mgd2hldGhlciB0aGUgRS4xNjQgbnVtYmVyIGhhcyBiZWVuIGFzc2ln bmVkIGluIGl0cyBWYWxpZGF0aW9uIGRhdGFiYXNlLCBpZiBub3QtYXNzaWduZWQgYWRkcyByZWNv cmQgaW4gZGF0YWJhc2UoQXNzaWduZWUncyBpbmZvcm1hdGlvbiBhbmQgdGhlIGFwcGxpZWQgRS4x NjQgbnVtYmVyIGFyZSB1c2VkIGFzIHZhbGlkYXRpb24gaW5mb3JtYXRpb24sIGFuZCBwZXJpb2Qg b2YgRU5VTSB2YWxpZGl0eSBpcyBjcmVhdGVkKSBhbmQgcmV0dXJucyBzdWNjZXNzZnVsIHJlc3Vs dCwgb3RoZXJ3aXNlIHJldHVybnMgZmFpbGVkIHJlc3VsdC4NCiAgICg0KSBOQUFFIHRlbGxzIEFz c2lnbmVlIHRoZSByZXN1bHQgZ290IGZyb20gTkFNLg0KICAgKDUpIFRoZSBBc3NpZ25lZSBhcHBs aWVzIHRoZSBjb3JyZXNwb25kaW5nIEVOVU0gZG9tYWluIG5hbWUgYXQgYSBFTlVNIFJlZ2lzdHJh ci4NCiAgICg2KSBUaGUgUmVnaXN0cmFyIHJlcXVlc3RzIHZhbGlkYXRpb24gYXQgTkFNKFZFKS4N CiAgICg3KSBUaGUgVkUgdmVyaWZ5IHRoYXQgdGhlIEFzc2lnbmVlIG9mIHRoZSBFLjE2NCBudW1i ZXIgY29ycmVzcG9uZHMgdG8gdGhlIFJlZ2lzdHJhbnQgb2YgdGhlIEVOVU0gZG9tYWluIG5hbWUg YW5kIHJldHVybiByZXN1bHQuDQogICAoOCkgVGhlIFJlZ2lzdHJhciBzZW5kcyBhbiBFTlVNIHJl Z2lzdHJhdGlvbiByZXF1ZXN0IHRvIHRoZSBSZWdpc3RyeS4gQWRkaXRpb25hbCBpbmZvcm1hdGlv biBhYm91dCB0aGUgdmFsaWRhdGlvbiBwcm9jZXNzIG1pZ2h0IGJlIHNlbnQgYWxvbmcgd2l0aCB0 aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuDQogICAoOSkgRmluYWxseSwgUmVnaXN0cnkgc2VuZHMg dG8gTkFNIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBjZXJ0YWluIEUuMTY0IG51bWJlciBoYXMg YmVlbiB1c2VkLih0aGlzIGluZm9ybWF0aW9uIGlzIHVzZWQgdG8gcmVuZXcgcGVyaW9kIG9mIEVO VU0gdmFsaWRpdHkpDQoNClRoZSBiZW5lZml0cyBvZiBvdXIgb3BpbmlvbiBhcmUgYXMgZm9sbG93 aW5nOg0KMS5SZWdpc3RyeSBnZXRzIGRlbGVnYXRpb24gZnJvbSBnb3Zlcm5tZW50IGFuZCBhbnN3 ZXIgZm9yIHRoZSB3aG9sZSBwcm9jZXNzIG9mIEVOVU0gbnVtYmVyIGFzc2lnbm1lbnQgYW5kIEVO VU0gZG9tYWluIG5hbWUgcmVnaXN0cmF0aW9uLCB3aGljaCBjYW4gYXZvaWQgYmVuZWZpdCBhbmQg cmVzcG9uc2liaWxpdHkgb2YgZGlmZmVyZW50IGVudGl0aWVzLg0KMi5VbmlmaWNhdGlvbiBvZiBF TlVNIG51bWJlciBleHBpcmF0aW9uIGFuZCBFTlVNIGRvbWFpbiBuYW1lIGV4cGlyYXRpb24gY2Fu IHJlZHVjZSBvcGVyYXRpb24gYW5kIGNvbWJpbmUgdGhlIEVOVU0gbnVtYmVyIGFuZCBFTlVNIGRv bWFpbiBuYW1lL0VOVU0gc2VydmljZXMuDQozLkluZGVwZW5kZW5jZSBvZiBWRSBwcm92aWRlcyBy YXRoZXIgYWJzb2x1dGUgdmFsaWRhdGlvbiBkYXRhYmFzZSwgYW5kIGlzIHVzZWZ1bCBmb3IgbWFu YWdlbWVudCBhbmQgdmFsaWRhdGlvbiBvZiBFTlVNIGFwcGxpY2F0aW9uLg0KDQpXZSBqdXN0IGJy aW5nIG91dCBzb21lIHRoaW5raW5nLCBhbmQgaWYgYW55IGRpZmZlcmVudCBvcGluaW9uLCBsZXQn cyBkaXNjdXNzIGZ1cnRoZXIuDQoNCllvdXJzIHNpbmNlcmVseSANCg0KQ2hlbmh1aSwgV2FuZ2Zl bmcsIENoZW5saWFuZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRo ZSBJRVNHIiA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+DQpUbzogIklFVEYtQW5ub3VuY2UiIDxp ZXRmLWFubm91bmNlQGlldGYub3JnPg0KQ2M6IDxlbnVtQGlldGYub3JnPg0KU2VudDogVGh1cnNk YXksIEF1Z3VzdCAxNywgMjAwNiA1OjU5IEFNDQpTdWJqZWN0OiBbRW51bV0gTGFzdCBDYWxsOiAn RU5VTSBWYWxpZGF0aW9uIEFyY2hpdGVjdHVyZScgdG8gSW5mb3JtYXRpb25hbCBSRkMgKGRyYWZ0 LWlldGYtZW51bS12YWxpZGF0aW9uLWFyY2gpIA0KDQoNCj4gVGhlIElFU0cgaGFzIHJlY2VpdmVk IGEgcmVxdWVzdCBmcm9tIHRoZSBUZWxlcGhvbmUgTnVtYmVyIE1hcHBpbmcgV0cgdG8gDQo+IGNv bnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQo+IA0KPiAtICdFTlVNIFZhbGlkYXRpb24g QXJjaGl0ZWN0dXJlICcNCj4gICA8ZHJhZnQtaWV0Zi1lbnVtLXZhbGlkYXRpb24tYXJjaC0wMy50 eHQ+IGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDDQo+IA0KPiBUaGUgSUVTRyBwbGFucyB0byBtYWtl IGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMNCj4gZmluYWwg Y29tbWVudHMgb24gdGhpcyBhY3Rpb24uICBQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMgdG8gdGhl DQo+IGllc2dAaWV0Zi5vcmcgb3IgaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMDYt MDgtMzAuDQo+IA0KPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZW51bS12YWxpZGF0aW9uLWFyY2gt MDMudHh0DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZW51bSBtYWlsaW5nIGxpc3QNCj4gZW51bUBpZXRmLm9yZw0KPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbnVtDQo+ --===============1403211623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1403211623==-- From enum-bounces@ietf.org Tue Aug 22 06:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTao-0004cN-7t; Tue, 22 Aug 2006 06:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTam-0004cH-FU for enum@ietf.org; Tue, 22 Aug 2006 06:34:44 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFTak-0007gG-76 for enum@ietf.org; Tue, 22 Aug 2006 06:34:44 -0400 Received: (eyou send program); Tue, 22 Aug 2006 18:33:30 +0800 Message-ID: <356242810.08427@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.146 with SMTP; Tue, 22 Aug 2006 18:33:30 +0800 Message-ID: <000a01c6c5d6$67141380$6306e29f@cnnicchenh> From: "chenhui" To: , Subject: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) Date: Tue, 22 Aug 2006 18:33:26 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.0 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: =?gb2312?B?J831ILflJw==?= , =?gb2312?B?s8LBwQ==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785743610==" Errors-To: enum-bounces@ietf.org --===============0785743610== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGV4IGFuZCBCZXJuaWUsDQoNClF1aXRlIGltcG9ydGFudCBkcmFmdCB0byBwcm9tb3Rl IEVOVU0gYXBwbGljYXRpb24hDQoNCldlIHN0dWRpZWQgdGhpcyBkcmFmdCBhbmQgaGFkIGEgZGlz Y3Vzc2lvbi4gSGVyZSBhcmUgc29tZSBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zIGZvciB5b3U6 DQoNCjEuIFRoZSBkYXRhIGZsb3cgb2YgdmFsaWRhdGlvbiBwcm9jZXNzIHNheXMgIkEgVmFsaWRh dGlvbiBFbnRpdHkgbWF5IGNob29zZSB0byBwZXJmb3JtIGFsbCBjb21tdW5pY2F0aW9uIHdpdGgg dGhlIEFzc2lnbmVlIHZpYSB0aGUgcmVxdWVzdGluZyBSZWdpc3RyYXIgcmF0aGVyIHRoYW4gY29u dGFjdGluZyB0aGUgQXNzaWduZWUgYnkgaXRzZWxmLiIgaW4gbGFzdCBwYXJhZ3JhcGggb2YgU2Vj IDQuMywgYnV0IGFjdHVhbGx5IEZpZ3VyZSA0IG9mIFNlYyA1LjIgc2hvd3MgVkUgZGlyZWN0bHkg Y29tbXVuaWNhdGVzIHdpdGggQXNzaWduZWUuDQogICBXZSBhcmUgbm90IGNsZWFyIHRoYXQgaG93 IGRvZXMgVkUgZGlyZWN0bHkgY29tbXVuY2F0ZXMgd2l0aCBBc3NpZ25lZSwgb3IgdGhhdCBWRSBk cmF3cyB0aGUgZWZmZWN0aXZlIHZhbGlkYXRpb24gaW5mb3JhbXRpb24gb3V0IG9mIHRoZSBBc3Np Z25lZS9SZWdpc3RyYW50J3MgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gUmVnaXN0cmFy Lg0KDQoyLiBJdCBzYXlzIFZFIHBvc3Nlc3MgdGhlIHZhbGlkYXRpb24gZnVuY3Rpb24sIGJ1dCB0 aGUgZGVzY3JpcHRpb24gb2YgVkUgaW4gdGhlIGltcGxlbWVudGF0aW9uICBzZWVtcyBWRSBpcyBv bmx5IGFuIGFnZW50IHRvIHByZWZvcm0gdmFsaWRhdGlvbiwgc3VjaCBhcyBGaWd1cmUgNCBvZiBT ZWMgNS4yIHRoYXQgVkUgZmV0Y2hlcyBpbmZvcm1hdGlvbiBmcm9tIE5BRSBhbmQgQXNzaWduZWUu DQotLS0tc3VnZ2VzdGlvbjogVkUgcG9zc2VzcyB2YWxpZGF0aW9uIGRhdGFiYXNlIGFzIHRoZSB0 aGlyZCB2YWxpZGF0aW9uIGNlbnRlciwgYW5kIG5lZWQgbm90IHRvIGlucXVpcmUgb2Ygb3RoZXIg ZW50aXRpZXMgYWJvdXQgdGhlIGFzc2lnbmVlJ3MgaW5mb3JtYXRpb24gZHVyaW5nIHZhbGlkYXRp b24gcHJvY2Vzcy4NCg0KMy4gU2VjIDIgcmVxdWlyZW1lbnQgbWVudGlvbnMgInJlY3VycmluZyB2 YWxpZGF0aW9uIiBvciAicmV2YWxpZGF0aW9uIiwgYW5kIFNlYyA0LjEgZGVzY3JpYmVzIHJldmFs aWRhdGlvbiB3b3JrZmxvdy4gV2UgdGhpbmsgaXQgaXMgcmF0aGVyIGNvbXBsZXggd2hlbiBleHBp cmF0aW9uIG9mIEUuMTY0IG51bWJlciBhbmQgZXhwaXJhdGlvbiBvZiBFTlVNIGRvbWFpbiBuYW1l IGJvdGggbmVlZCB0byBiZSBjb25zaWRlcmVkLg0KLS0tLXN1Z2dlc3Rpb246IFBlcmlvZCBvZiBF LjE2NCBudW1iZXIgdmFsaWRpdHkgbmVlZCB0byBiZSByZWZlcmVkIG9ubHkgd2hlbiBFLjE2NCBu dW1iZXIgaXMgYXNzaWduZWQuIEFuZCBhZnRlciByZWdpc3RyYXRpb24gb2YgRU5VTSBkb21haW4g bmFtZSBhbmQgRU5VTSBzZXJ2aWNlcywgRS4xNjQgbnVtYmVyIHZhbGlkaXR5IGVxdWFscyB0byBF TlVNIGRvbWFpbiBuYW1lL3NlcnZpY2VzIHZhbGlkaXR5Lg0KDQo0LiBUaGUgZGlmZmVyZW50IGVu dGl0aWVzIGhhdmUgZGlmZmVyZW50IGRlbWFuZHMgb2YgYmVuZWZpdCwgc28gaXQgaXMgZGlmZmlj dWx0IHRvIGxldmVsIHRoZSByZWxhdGlvbiBvZiBlYWNoIGVudGl0aWVzIGluIEVOVU0gcHJvdmlz aW9uIG1vZGVsLCBlc3BlY2lhbGx5IFJlZ2lzdHJ5LCBWYWxpZGF0aW9uIEVudGl0eSBhbmQgTnVt YmVyIEFzc2lnbm1lbnQgRW50aXR5Lg0KLS0tLXN1Z2dlc3Rpb246IFJlZ2lzdHJ5IGhhcyB0aGUg cmlnaHQgdG8gZGVsZWdhdGUgTkFFLCBhbmQgTkFFIGlzIGFsc28gdGhlIFZFLg0KDQpUaGUgZm9s bG93aW5nIGZpZ3VyZSBleHBsYWlucyBvdXIgcG9pbnQgb2YgdmlldzoNCiAgICAgICAgKy0tLS0t LS0tLS0rDQogICAgICAgIHwgUmVnaXN0cnkgfCBcDQogICAgICAgICstLS0tLS0tLS0tKyAgXCAN CiAgICAgICAgICAgICBeICAgICAgICAgXCANCiAgICAgICAgICAgICB8ICAgICAgICAgIFwNCiAg ICAgICAgICAgICB8ICAgICAgICAgICBcDQogICAgICAgICAgICAgfCAgICAgICAgICAgIFwgDQog ICAgICAgICAgICAgfCAgICAgICAgICAgICBcDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAg XA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICBcIA0KICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgXCANCiAgICAgICAgICAgICB8KDgpICAgICAgICAgICAgICBcKDkpDQogICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgIFwgDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICBcDQogICAgICAgICAgICAgfCAgICAgICAgICAoNikgICAgICAgdg0KICAgICAgICArLS0t LS0tLS0tLS0rIC0tLS0tLS0tLS0+Ky0tLS0tLS0tLSsNCiAgICAgICAgfCBSZWdpc3RyYXIgfDwt LS0tLS0tLS0tIHwgTkFNKFZFKSB8DQogICAgICAgICstLS0tLS0tLS0tLSsgICAoNykgICAgPiAr LS0tLS0tLS0tKw0KICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICBeICB8DQogICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgIHwNCiAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgfCAgfA0KICAgICAgICAgICAgIHwoNSkgICAgICAgICAgICAgICAgICB8 ICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICgyKXwgIHwNCiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8ICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgIHwNCiAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgfCgzKQ0KICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICB8ICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgIFYNCiAgICAgICArLS0tLS0tLS0tLS0tKyAgICAoNCkgICAgICstLS0tLS0tLS0rIA0K ICAgICAgIHwgQXNzaWduZWUgPSB8PC0tLS0tLS0tLS0gfCAgTkFBRSAgIHwNCiAgICAgICB8IFJl Z2lzdHJhbnQgfC0tLS0tLS0tLS0+IHwgICAgICAgICB8DQogICAgICAgKy0tLS0tLS0tLS0tLSsg ICAgKDEpICAgICArLS0tLS0tLS0tKw0KDQogICAgICAgICBOQU06IE51bWJlciBBc3NpZ25tZW50 IE1hbmFnZW1lbnQNCiAgICAgICAgIE5BQUU6ICBOdW1iZXIgQXNzaWdubWVudCBBZ2VudCBFbnRp dHkNCiAgICAgICAgIFZFOiAgIFZhbGlkYXRpb24gRW50aXR5DQoNCiAgICgxKSBUaGUgQXNzaWdu ZWUgYXBwbHlzIGZvciBhbiBFLjE2NCBudW1iZXIgZnJvbSBOQUFFIGFuZCBzdWJtaXRzIHBlcnNv bmFsIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24gLg0KICAgKDIpIE5BQUUgc2VuZHMgQXNzaWduZWUn cyBpbmZvcm1hdGlvbiBhbmQgdGhlIGFwcGxpZWQgRS4xNjQgbnVtYmVyIHRvIE5BTS4NCiAgICgz KSBOQU0gY2hlY2tzIHdoZXRoZXIgdGhlIEUuMTY0IG51bWJlciBoYXMgYmVlbiBhc3NpZ25lZCBp biBpdHMgVmFsaWRhdGlvbiBkYXRhYmFzZSwgaWYgbm90LWFzc2lnbmVkIGFkZHMgcmVjb3JkIGlu IGRhdGFiYXNlKEFzc2lnbmVlJ3MgaW5mb3JtYXRpb24gYW5kIHRoZSBhcHBsaWVkIEUuMTY0IG51 bWJlciBhcmUgdXNlZCBhcyB2YWxpZGF0aW9uIGluZm9ybWF0aW9uLCBhbmQgcGVyaW9kIG9mIEVO VU0gdmFsaWRpdHkgaXMgY3JlYXRlZCkgYW5kIHJldHVybnMgc3VjY2Vzc2Z1bCByZXN1bHQsIG90 aGVyd2lzZSByZXR1cm5zIGZhaWxlZCByZXN1bHQuDQogICAoNCkgTkFBRSB0ZWxscyBBc3NpZ25l ZSB0aGUgcmVzdWx0IGdvdCBmcm9tIE5BTS4NCiAgICg1KSBUaGUgQXNzaWduZWUgYXBwbGllcyB0 aGUgY29ycmVzcG9uZGluZyBFTlVNIGRvbWFpbiBuYW1lIGF0IGEgRU5VTSBSZWdpc3RyYXIuDQog ICAoNikgVGhlIFJlZ2lzdHJhciByZXF1ZXN0cyB2YWxpZGF0aW9uIGF0IE5BTShWRSkuDQogICAo NykgVGhlIFZFIHZlcmlmeSB0aGF0IHRoZSBBc3NpZ25lZSBvZiB0aGUgRS4xNjQgbnVtYmVyIGNv cnJlc3BvbmRzIHRvIHRoZSBSZWdpc3RyYW50IG9mIHRoZSBFTlVNIGRvbWFpbiBuYW1lIGFuZCBy ZXR1cm4gcmVzdWx0Lg0KICAgKDgpIFRoZSBSZWdpc3RyYXIgc2VuZHMgYW4gRU5VTSByZWdpc3Ry YXRpb24gcmVxdWVzdCB0byB0aGUgUmVnaXN0cnkuIEFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHZhbGlkYXRpb24gcHJvY2VzcyBtaWdodCBiZSBzZW50IGFsb25nIHdpdGggdGhlIHJl Z2lzdHJhdGlvbiByZXF1ZXN0Lg0KICAgKDkpIEZpbmFsbHksIFJlZ2lzdHJ5IHNlbmRzIHRvIE5B TSB0aGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgY2VydGFpbiBFLjE2NCBudW1iZXIgaGFzIGJlZW4g dXNlZC4odGhpcyBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIHJlbmV3IHBlcmlvZCBvZiBFTlVNIHZh bGlkaXR5KQ0KDQpUaGUgYmVuZWZpdHMgb2Ygb3VyIG9waW5pb24gYXJlIGFzIGZvbGxvd2luZzoN CjEuUmVnaXN0cnkgZ2V0cyBkZWxlZ2F0aW9uIGZyb20gZ292ZXJubWVudCBhbmQgYW5zd2VyIGZv ciB0aGUgd2hvbGUgcHJvY2VzcyBvZiBFTlVNIG51bWJlciBhc3NpZ25tZW50IGFuZCBFTlVNIGRv bWFpbiBuYW1lIHJlZ2lzdHJhdGlvbiwgd2hpY2ggY2FuIGF2b2lkIGJlbmVmaXQgYW5kIHJlc3Bv bnNpYmlsaXR5IG9mIGRpZmZlcmVudCBlbnRpdGllcy4NCjIuVW5pZmljYXRpb24gb2YgRU5VTSBu dW1iZXIgZXhwaXJhdGlvbiBhbmQgRU5VTSBkb21haW4gbmFtZSBleHBpcmF0aW9uIGNhbiByZWR1 Y2Ugb3BlcmF0aW9uIGFuZCBjb21iaW5lIHRoZSBFTlVNIG51bWJlciBhbmQgRU5VTSBkb21haW4g bmFtZS9FTlVNIHNlcnZpY2VzLg0KMy5JbmRlcGVuZGVuY2Ugb2YgVkUgcHJvdmlkZXMgcmF0aGVy IGFic29sdXRlIHZhbGlkYXRpb24gZGF0YWJhc2UsIGFuZCBpcyB1c2VmdWwgZm9yIG1hbmFnZW1l bnQgYW5kIHZhbGlkYXRpb24gb2YgRU5VTSBhcHBsaWNhdGlvbi4NCg0KV2UganVzdCBicmluZyBv dXQgc29tZSB0aGlua2luZywgYW5kIGlmIGFueSBkaWZmZXJlbnQgb3BpbmlvbiwgbGV0J3MgZGlz Y3VzcyBmdXJ0aGVyLg0KDQpZb3VycyBzaW5jZXJlbHkgDQoNCkNoZW5odWksIFdhbmdmZW5nLCBD aGVubGlhbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJUaGUgSUVT RyIgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KVG86ICJJRVRGLUFubm91bmNlIiA8aWV0Zi1h bm5vdW5jZUBpZXRmLm9yZz4NCkNjOiA8ZW51bUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMTcsIDIwMDYgNTo1OSBBTQ0KU3ViamVjdDogW0VudW1dIExhc3QgQ2FsbDogJ0VOVU0g VmFsaWRhdGlvbiBBcmNoaXRlY3R1cmUnIHRvIEluZm9ybWF0aW9uYWwgUkZDIChkcmFmdC1pZXRm LWVudW0tdmFsaWRhdGlvbi1hcmNoKSANCg0KDQo+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJl cXVlc3QgZnJvbSB0aGUgVGVsZXBob25lIE51bWJlciBNYXBwaW5nIFdHIHRvIA0KPiBjb25zaWRl ciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiANCj4gLSAnRU5VTSBWYWxpZGF0aW9uIEFyY2hp dGVjdHVyZSAnDQo+ICAgPGRyYWZ0LWlldGYtZW51bS12YWxpZGF0aW9uLWFyY2gtMDMudHh0PiBh cyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KPiANCj4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRl Y2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzDQo+IGZpbmFsIGNvbW1l bnRzIG9uIHRoaXMgYWN0aW9uLiAgUGxlYXNlIHNlbmQgYW55IGNvbW1lbnRzIHRvIHRoZQ0KPiBp ZXNnQGlldGYub3JnIG9yIGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDA2LTA4LTMw Lg0KPiANCj4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPiBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVudW0tdmFsaWRhdGlvbi1hcmNoLTAzLnR4 dA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGVudW0gbWFpbGluZyBsaXN0DQo+IGVudW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW51bQ0KPg== --===============0785743610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0785743610==-- From enum-bounces@ietf.org Tue Aug 22 11:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXpd-0003YB-S4; Tue, 22 Aug 2006 11:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXpc-0003Xy-3Q; Tue, 22 Aug 2006 11:06:20 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFXpb-00029C-BS; Tue, 22 Aug 2006 11:06:20 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 22 Aug 2006 17:06:05 +0200 id 0007C0AA.44EB1D5E.000075F3 Message-ID: <44EB1D15.4010105@enum.at> Date: Tue, 22 Aug 2006 17:04:53 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: chenhui Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) References: <356242810.08427@cnnic.cn> In-Reply-To: <356242810.08427@cnnic.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: enum@ietf.org, =?GB2312?B?s8LBwQ==?= , iesg@ietf.org, =?GB2312?B?J831ILflJw==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org chenhui wrote: > Quite important draft to promote ENUM application! Hi chenhui, my comments inline: > 1. The data flow of validation process says "A Validation Entity may choose to perform all communication with the Assignee via the requesting Registrar rather than contacting the Assignee by itself." in last paragraph of Sec 4.3, but actually Figure 4 of Sec 5.2 shows VE directly communicates with Assignee. > We are not clear that how does VE directly communcates with Assignee, or that VE draws the effective validation inforamtion out of the Assignee/Registrant's registration information from Registrar. Actually, it's pretty much a local choice how a VE together with a Registrar would like to operate. If the registrar already provides enough information together with the validation request, there may be no need to contact the assignee at all, however, we can't explude it in the draft. Please note that section 5 provides just examples - in the first case (section 5.1), the VE does not interact with the Number holder at all - the number holder might not even be aware of the VE. In the second example, however, the VE uses some kind of eg. call back mechanism to check the data provided by the registrar in the validation request. Conclusion: By not limiting if, when and how a VE interacts with the Assignee, our model becomes flexible enough to fit current (and hopefully most future) models of ENUM administration. There may be rather "free" models (as we have implemented it in Austria), and there may be models where the actual form of communication is dictated by the NRA or an industry consortium. Our draft, again, does not preclude either case. > 2. It says VE possess the validation function, but the description of VE in the implementation seems VE is only an agent to preform validation, such as Figure 4 of Sec 5.2 that VE fetches information from NAE and Assignee. yes, that's exactly its purpose. To handle the validation process, however that is implemented. What do you mean by "posessing the validation function"? Do you mean that the VE posesses all relevant data? > ----suggestion: VE possess validation database as the third validation center, and need not to inquire of other entities about the assignee's information during validation process. I don't understand what the other two validation centers would be. However, to make it work as you indicated, you would need to force every telco in every country of this world to hand over his complete customer database to all VEs in that country - i can't imagine that this will happen anytime soon. Again, we do not exclude a case where a VE _could_ have the information that you describe - our model gives freedom in this perspective as well. > 3. Sec 2 requirement mentions "recurring validation" or "revalidation", and Sec 4.1 describes revalidation workflow. We think it is rather complex when expiration of E.164 number and expiration of ENUM domain name both need to be considered. In many countries, E.164 numbers do not "expire". My parents have their phone number since about 25 years, they even switched their telcos a few times, and kept their number. Their number will be relinquished when they cancel their phone line, but that's up to their decision, and not tied to any date. > ----suggestion: Period of E.164 number validity need to be refered only when E.164 number is assigned. And after registration of ENUM domain name and ENUM services, E.164 number validity equals to ENUM domain name/services validity. As outlined above, there are existing numbers out there which do not expire "automatically". Most of the phone numbers out there are also not tied to an ENUM-Domain, because the corresponding ENUM domain has not been registered. Therefore, the validity of the ENUM domain cannot be tied to the expiration of the number itself. Of course would it be easier to know when a certain number is returned, but this information is only with the respective NAE (who might not cooperate with the registry for this purpose). But: there might be cases where revalidation is trivial (or not even required), eg.: - trivial: Like in Example 5.1, where the Service provider acts as the NAE as well as the Registrar and the VE. Revalidation becomes just a lookup in the customer database. - not required: When the ENUM domain existance is the basis for the number allocation (like the Austrian number range +43 780). Because number and domain are intrinsically tied to each other (and the number is actually created and deleted when the ENUM domain is created and deleted), no revalidation is neccessary. That's the reason for the "In most cases, ..." at the beginning of the revalidation workflow - that there might be scenarios where it's _not_ neccessary - decision about this is a local matter, again. > 4. The different entities have different demands of benefit, so it is difficult to level the relation of each entities in ENUM provision model, especially Registry, Validation Entity and Number Assignment Entity. > ----suggestion: Registry has the right to delegate NAE, and NAE is also the VE. Again, this precludes certain scenarios (including most current implementations), because: The entity to appoint NAEs is the NRA (in most cases the regulator), so if you require that the Registry appoints NAEs you essentially require the roles of Registry and NRA to collapse into one single entity. By requiring that NAE and VE are the same entity, you collapse another two roles. When we started with the draft, our feeling was that collapsing roles is much easier than splitting them, so we clearly seperated each role, without precluding that an entity may perform several roles. So, according to our draft and your scenario, you would have: Entity "A", which assumes the role of NRA and Registry Entity "B", which assumes the role of NAE plus a VE This is perfectly possible with our document, but ultimately a national matter. > The following figure explains our point of view: > +----------+ > | Registry | \ > +----------+ \ > ^ \ > | \ > | \ > | \ > | \ > | \ > | \ > | \ > |(8) \(9) > | \ > | \ > | (6) v > +-----------+ ---------->+---------+ > | Registrar |<---------- | NAM(VE) | > +-----------+ (7) > +---------+ > ^ ^ | > | | | > | | | > |(5) | | > | (2)| | > | | | > | | | > | | | > | | |(3) > | | | > | | V > +------------+ (4) +---------+ > | Assignee = |<---------- | NAAE | > | Registrant |----------> | | > +------------+ (1) +---------+ > > NAM: Number Assignment Management > NAAE: Number Assignment Agent Entity > VE: Validation Entity > > (1) The Assignee applys for an E.164 number from NAAE and submits personal particular information . > (2) NAAE sends Assignee's information and the applied E.164 number to NAM. > (3) NAM checks whether the E.164 number has been assigned in its Validation database, if not-assigned adds record in database(Assignee's information and the applied E.164 number are used as validation information, and period of ENUM validity is created) and returns successful result, otherwise returns failed result. > (4) NAAE tells Assignee the result got from NAM. > (5) The Assignee applies the corresponding ENUM domain name at a ENUM Registrar. > (6) The Registrar requests validation at NAM(VE). > (7) The VE verify that the Assignee of the E.164 number corresponds to the Registrant of the ENUM domain name and return result. > (8) The Registrar sends an ENUM registration request to the Registry. Additional information about the validation process might be sent along with the registration request. > (9) Finally, Registry sends to NAM the information that the certain E.164 number has been used.(this information is used to renew period of ENUM validity) Most of what you described above sounds like you're proposing an actual validation method. Our draft does not do this for a reason: it reduces flexibility. On the other hand, i think that our role definition fits pretty well into your method - the entity which serves as VE just assumes another new role that you defined for your method (the NAM), and you introduce another role (the NAAE). Generally, i don't see how the method that you proposed above would work with already assigned numbers, because verifying information provided by the Assignee in the first place does not seem to make much sense. > The benefits of our opinion are as following: > 1.Registry gets delegation from government and answer for the whole process of ENUM number assignment and ENUM domain name registration, which can avoid benefit and responsibility of different entities. Again, our model allows to collaps several roles into a single entity as you are proposing. We're not saying that the entity operating the registry must not assume any other role as well. > 2.Unification of ENUM number expiration and ENUM domain name expiration can reduce operation and combine the ENUM number and ENUM domain name/ENUM services. I don't think you can change the way E.164 numbers are assigned, and therefore, applying an expiration on numbers is not an option. Additionally, E.164 numbers and ENUM domains are assigned completely independent - that was the reason in the first place why ENUM validation was neccessary. If both addressing elements would be assigned together, validation would be superflous (as, again, it is the case for +43 780). > 3.Independence of VE provides rather absolute validation database, and is useful for management and validation of ENUM application. Sorry, i didn't get this point. Could you elaborate on this? i hope that clarifies some of the issues - i didn't talk to bernie yet, so he might have more comments on your suggestions. Please don't hesitate to contact us again if there's anything which remains unclear. thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 22 18:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeXb-00057r-3J; Tue, 22 Aug 2006 18:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeXa-00057m-6a for enum@ietf.org; Tue, 22 Aug 2006 18:16:10 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFeXX-0007Ca-Q5 for enum@ietf.org; Tue, 22 Aug 2006 18:16:10 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7MMGDtg001176; Tue, 22 Aug 2006 15:16:18 -0700 From: "Richard Shockey" To: Date: Tue, 22 Aug 2006 18:15:46 -0400 Message-ID: <001301c6c638$896f5180$54201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbGOIKTbp0Uop4QQeisWHiIvtqnvg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Last Call on document draft-ietf-enum-cnam-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam' Author(s) : R. Shockey, et al. Filename : draft-ietf-enum-cnam-03.txt Pages : 13 Date : 2006-8-21 This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'data:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new media type application/cnam . This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-03.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 1 month or so from today August 22 until at least September 22 though we can modify that if new issues come up. The purpose of the extended WGLC is to accommodate the summer vacation schedules of WG participants. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 23 05:19:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFosO-0004sU-Rg; Wed, 23 Aug 2006 05:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFosN-0004sG-7C for enum@ietf.org; Wed, 23 Aug 2006 05:18:19 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFosL-0007WS-I3 for enum@ietf.org; Wed, 23 Aug 2006 05:18:19 -0400 Received: (eyou send program); Wed, 23 Aug 2006 17:18:02 +0800 Message-ID: <356324682.20236@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.146 with SMTP; Wed, 23 Aug 2006 17:18:02 +0800 Message-ID: <00e401c6c695$0cddff60$6306e29f@cnnicchenh> From: "chenhui" To: "Alexander Mayrhofer" References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) Date: Wed, 23 Aug 2006 17:18:09 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.0 (+) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: enum@ietf.org, =?gb2312?B?s8LBwQ==?= , iesg@ietf.org, =?gb2312?B?J831ILflJw==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0996427730==" Errors-To: enum-bounces@ietf.org --===============0996427730== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGV4LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgZXhwbGFuYXRpb26joQ0K QWZ0ZXIgdGhpbmsgYWdhaW4sIHdlIGhpZ2hseSBhZ3JlZSB3aXRoIHRoZSBmbGV4aWJpbGl0eSBv ZiB5b3VyIGRyYWZ0Lg0KDQpBbmQgdGhlIHN1Z2dlc3Rpb25zIHdlIG1lbnRpb24gbWFpbmx5IHBy b2NlZWQgZnJvbSBhY3R1YWwgZG9tZXN0aWMgc2l0dWF0aW9uIGFuZCBzb21lIGV4dGVuc2lvbi4N Cg0KQXMgeW91IGJyaW5nIG91dCBpbiB0aGUgb3RoZXIgZHJhZnQgIlRlbGVwaG9uZSBOdW1iZXIg TWFwcGluZyBhbmQgRG9tYWluIEtleXMgIGFzIGEgRGlzdHJpYnV0ZWQgSWRlbnRpdHkgSW5mcmFz dHJ1Y3R1cmUiIHRoYXQgRU5VTSBudW1iZXIgY2FuIGJlIHVzZWQgdGhlIGlkZW50aWZpZXIgZm9y IG1hbnkgYXBwbGljYXRpb24gc3VjaCBhcyBQMlAgQ29tbXVuaWNhdGlvbi9Wb0lQLCB3ZSBhcmUg YWxzbyBjYXJyaW5nIG9uIHRoaXMgc3R1ZHkuIFRodXMsIGluIG9yZGVyIHRvIGluc3VyZSBhdXRo ZW50aWNpdHkgb2YgRU5VTSB1c2VyJ3MgaW5mb3JtYXRpb24sIHdlIGNvbnNpZGVyIHRoZSBmb2xs b3dpbmcgcXVlc3Rpb24gMSBhbmQgMi4gQW5kIHF1ZXN0aW9uIDMgYW5kIDQgaXMgYWJvdXQgbnVt YmVyIHRyYW5zZmVyIGFuZCByZXZhbGlkYXRpb24uDQoNCjEuIFdlIHRoaW5rIHRoZSB2YWxpZGF0 aW9uIGluY2x1ZGVzIHR3byBhc3BlY3RzLCBvbmUgaXMgdGhlIHJlZ2lzdHJhbnQncyBhdXRoZW50 aWNpdHksIHRoZSBvdGhlciBpcyB0aGF0IEVOVU0gcmVnaXN0cmFudCBpcyB0aGUgc2FtZSB3aXRo IEUuMTY0IGhvbGRlci4NCkluIEF1c3RyaWFuIG1vZGVsLCAiRU5VTSBkb21haW4gZXhpc3RlbmNl IGlzIHRoZSBiYXNpcyBmb3IgdGhlIG51bWJlciBhbGxvY2F0aW9uIiwgRU5VTSBkb21haW4gcmVn aXN0cmF0aW9uIGlzIG9uIGludGVybmV0LCB0aHVzLCBob3cgdG8gaW5zdXJlIHRoZSB1c2VyJ3Mg YXV0aGVudGljaXR5PyBPciB5b3UgY29uc2lkZXIgbm9ib2R5IHdpbGwgc3VibWl0IHRoZSBtZW5k YWNpb3VzIGluZm9ybWF0aW9uPw0KDQoyLiBUaGUgdGhpcmQgVkUgd2UgbWVudGlvbmVkIGlzIHRo ZSBuZXV0cmFsIHZhbGlkYXRpb24gZW50aXR5LCB3aGljaCBoYXMgcmVzcG9uc2liaWxpdHkgZm9y IHZhbGlkYXRpb24gb2YgdGhlIEVOVU0gcmVnaXN0cmF0aW9uIGFuZCBhcHBsaWNhdGlvbi4NClRo ZSBkcmFmdCBzaG93cyBOQUUvQ1NQIGNhbiBiZSB0cnVzdGVkLiBCdXQgYWN0dWFsbHksIFZvSVAg c2VydmljZSBwcm92aWRlcnMgaW4gbWFueSBjb3VudHJpZXMgbWF5IGJlIGxhY2sgb2YgZW5vdWdo IHN1cGVydmlzYWwsIGFuZCBpZiBjZXJ0YWluIFZvSVAgcHJvdmlkZXIgZ29lcyBiYW5rcnVwdCwg dHJhbnNmZXJpbmcgb2YgdXNlcnMnIGluZm9ybWF0aW9uIGJlbG9uZ2VkIHRvIHRoZSBWb0lQIHBy b3ZpZGVyIHdpbGwgYmUgYSBwcm9ibGVtLCBzbyB3ZSBwcmVmZXIgdG8gdHJ1c3QgdGhlIHRoaXJk L25ldXRyYWwgVkUgd2hvIGhvbGRzIHRoZSB0b3RhbCB1c2VycydzIGluZm9ybWF0aW9uLg0KDQoz LiBZb3UgZGlkIG5vdCBtZW50aW9uIEVOVU0gbnVtYmVyIHRyYW5zZmVyLCBhbmQgaXMgaXQgcG9z c2libGUgdG8gdHJhbnNmZXJlZCBhbiBFTlVNIG51bWJlciBmcm9tIG9uZSBwZXJzb24gdG8gYW5v dGhlciBhcyBnZW5hcmFsIGRvbWFpbiB0cmFuc2Zlcj8gDQpJZiBFTlVNIG51bWJlciBwZXJtaXRz IHRvIGJlIHRyYW5zZmVyZWQsIHRoZW4gd2UgdGhpbmsgdGhlIE51bWJlciBBc3NpZ25tZW50IEVu dGl0eSBvZiBhIG5hdGlvbmFsIHJhbmdlIGlzIHByZWZlcmVkLCBzbyB0aGF0IHVzZXJzIGNhbiBh cHBseSBFTlVNIG51bWJlciBmcm9tIGFueSBudW1iZXIgYXNzaWdubWVudCBhZ2VudHMuIEFsc28s IGlmIGNlcnRhaW4gRU5VTSBudW1iZXIgaXMgdHJhbnNmZXJlZCwgTkFFIG5lZWRzIHRvIHRlbGwg UmVnaXN0cnkvUmVnaXN0cmFyIHRoZSB0cmFuc2ZlcmVkIGluZm9ybWF0aW9uLg0KDQo0LiBXZSB3 YW50IHRvIGNvbmZpcm0gd2hldGhlciB0aGUgcmV2YWxpZGF0aW9uIGluIHRoZSBkcmFmdCBkZW5v dGVzIHRoYXQgRU5VTSB2YWxpZGF0aW9uIGl0c2VsZiBoYXMgZXhwaXJhdGlvbiBkYXRlIGFzIGFs bCBraW5kcyBvZiB2YWxpZGF0aW9uLCBzbyBpZiBFTlVNIGRlbGVnYXRpb24gaXMgYmV5b25kIGV4 cGlyYXRpb24gZGF0ZSwgcmV2YWxpZGF0aW9uIGlzIG5lZWRlZC4NCkZ1cnRoZXJtb3JlLCBpZiBF TlVNIG51bWJlciBjYW4gYmUgY2FuY2VsbGVkIG9yIHRyYW5zZmVyZWQsIG1heWJlIEVOVU0gcmV2 YWxpZGF0aW9uIGlzIG5lZWRlZC4NCg0KQlRXLCBFLjE2NCBudW1iZXIgbWF5YmUgaGFzIGV4cGly YXRpb24gdGltZSBpbiBzb21lIGNvdW50cmllcyBzdWNoIGFzIENoaW5hLiBGb3IgZXhhbXBsZSwg YSBwZXJzb24gYXBwbHkgb25lIEUuMTY0IG51bWJlcihvZiBjb3Vyc2UgaW5jbHVkaW5nIHRlbGVj b21tdW5pY2F0aW9uIHNlcnZpY2UpIGZyb20gQ1NQLCBhbmQgdGhlIGRlZmF1bHQgZXhwaXJhdGlv biB0aW1lIGlzIHVzdWFsbHkgdGhyZWUgbW9udGhzLCB0aGVuIGlmIHRoZSBwZXJzb24gZG9ubm90 IHBheSBhZ2FpbiwgdGhlIHRlbGVjb21tdW5pY2F0aW9uIHNlcnZpY2Ugd2lsbCBiZSBzdG9wcGVk IGFuZCB0aGUgbnVtYmVyIHdpbGwgYmUgdGFrZW4gYmFjayBhbmQgcmVhc3NpZ25lZC4NCg0KQmVz dCByZWdhcmRzIQ0KDQpZb3VycyBzaW5jZXJlbHkgDQpDaGVuaHVpLCBXYW5nZmVuZywgQ2hlbmxp YW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxleGFuZGVyIE1h eXJob2ZlciIgPGFsZXhhbmRlci5tYXlyaG9mZXJAZW51bS5hdD4NClRvOiAiY2hlbmh1aSIgPGNo ZW5odWlAY25uaWMuY24+DQpDYzogPGllc2dAaWV0Zi5vcmc+OyA8ZW51bUBpZXRmLm9yZz47ICIn zfUgt+UnIiA8ZmVuZ3dAY25uaWMuY24+OyAis8LBwSIgPGNoZW5saWFuZ0Bjbm5pYy5jbj4NClNl bnQ6IFR1ZXNkYXksIEF1Z3VzdCAyMiwgMjAwNiAxMTowNCBQTQ0KU3ViamVjdDogUmU6IFtFbnVt XSBMYXN0IENhbGw6ICdFTlVNIFZhbGlkYXRpb24gQXJjaGl0ZWN0dXJlJyB0byBJbmZvcm1hdGlv bmFsIFJGQyAoZHJhZnQtaWV0Zi1lbnVtLXZhbGlkYXRpb24tYXJjaCkNCg0KDQo+IA0KPiANCj4g Y2hlbmh1aSB3cm90ZToNCj4+IFF1aXRlIGltcG9ydGFudCBkcmFmdCB0byBwcm9tb3RlIEVOVU0g YXBwbGljYXRpb24hDQo+IA0KPiBIaSBjaGVuaHVpLA0KPiANCj4gbXkgY29tbWVudHMgaW5saW5l Og0KPiANCj4+IDEuIFRoZSBkYXRhIGZsb3cgb2YgdmFsaWRhdGlvbiBwcm9jZXNzIHNheXMgIkEg VmFsaWRhdGlvbiBFbnRpdHkgbWF5IGNob29zZSB0byBwZXJmb3JtIGFsbCBjb21tdW5pY2F0aW9u IHdpdGggdGhlIEFzc2lnbmVlIHZpYSB0aGUgcmVxdWVzdGluZyBSZWdpc3RyYXIgcmF0aGVyIHRo YW4gY29udGFjdGluZyB0aGUgQXNzaWduZWUgYnkgaXRzZWxmLiIgaW4gbGFzdCBwYXJhZ3JhcGgg b2YgU2VjIDQuMywgYnV0IGFjdHVhbGx5IEZpZ3VyZSA0IG9mIFNlYyA1LjIgc2hvd3MgVkUgZGly ZWN0bHkgY29tbXVuaWNhdGVzIHdpdGggQXNzaWduZWUuDQo+PiAgICBXZSBhcmUgbm90IGNsZWFy IHRoYXQgaG93IGRvZXMgVkUgZGlyZWN0bHkgY29tbXVuY2F0ZXMgd2l0aCBBc3NpZ25lZSwgb3Ig dGhhdCBWRSBkcmF3cyB0aGUgZWZmZWN0aXZlIHZhbGlkYXRpb24gaW5mb3JhbXRpb24gb3V0IG9m IHRoZSBBc3NpZ25lZS9SZWdpc3RyYW50J3MgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGZyb20g UmVnaXN0cmFyLg0KPiANCj4gQWN0dWFsbHksIGl0J3MgcHJldHR5IG11Y2ggYSBsb2NhbCBjaG9p Y2UgaG93IGEgVkUgdG9nZXRoZXIgd2l0aCBhIFJlZ2lzdHJhcg0KPiB3b3VsZCBsaWtlIHRvIG9w ZXJhdGUuIElmIHRoZSByZWdpc3RyYXIgYWxyZWFkeSBwcm92aWRlcyBlbm91Z2ggaW5mb3JtYXRp b24NCj4gdG9nZXRoZXIgd2l0aCB0aGUgdmFsaWRhdGlvbiByZXF1ZXN0LCB0aGVyZSBtYXkgYmUg bm8gbmVlZCB0byBjb250YWN0IHRoZQ0KPiBhc3NpZ25lZSBhdCBhbGwsIGhvd2V2ZXIsIHdlIGNh bid0IGV4cGx1ZGUgaXQgaW4gdGhlIGRyYWZ0Lg0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBzZWN0 aW9uIDUgcHJvdmlkZXMganVzdCBleGFtcGxlcyAtIGluIHRoZSBmaXJzdCBjYXNlDQo+IChzZWN0 aW9uIDUuMSksIHRoZSBWRSBkb2VzIG5vdCBpbnRlcmFjdCB3aXRoIHRoZSBOdW1iZXIgaG9sZGVy IGF0IGFsbCAtIHRoZQ0KPiBudW1iZXIgaG9sZGVyIG1pZ2h0IG5vdCBldmVuIGJlIGF3YXJlIG9m IHRoZSBWRS4gSW4gdGhlIHNlY29uZCBleGFtcGxlLA0KPiBob3dldmVyLCB0aGUgVkUgdXNlcyBz b21lIGtpbmQgb2YgZWcuIGNhbGwgYmFjayBtZWNoYW5pc20gdG8gY2hlY2sgdGhlIGRhdGENCj4g cHJvdmlkZWQgYnkgdGhlIHJlZ2lzdHJhciBpbiB0aGUgdmFsaWRhdGlvbiByZXF1ZXN0Lg0KPiAN Cj4gQ29uY2x1c2lvbjogQnkgbm90IGxpbWl0aW5nIGlmLCB3aGVuIGFuZCBob3cgYSBWRSBpbnRl cmFjdHMgd2l0aCB0aGUNCj4gQXNzaWduZWUsIG91ciBtb2RlbCBiZWNvbWVzIGZsZXhpYmxlIGVu b3VnaCB0byBmaXQgY3VycmVudCAoYW5kIGhvcGVmdWxseQ0KPiBtb3N0IGZ1dHVyZSkgbW9kZWxz IG9mIEVOVU0gYWRtaW5pc3RyYXRpb24uIFRoZXJlIG1heSBiZSByYXRoZXIgImZyZWUiDQo+IG1v ZGVscyAoYXMgd2UgaGF2ZSBpbXBsZW1lbnRlZCBpdCBpbiBBdXN0cmlhKSwgYW5kIHRoZXJlIG1h eSBiZSBtb2RlbHMgd2hlcmUNCj4gdGhlIGFjdHVhbCBmb3JtIG9mIGNvbW11bmljYXRpb24gaXMg ZGljdGF0ZWQgYnkgdGhlIE5SQSBvciBhbiBpbmR1c3RyeQ0KPiBjb25zb3J0aXVtLiBPdXIgZHJh ZnQsIGFnYWluLCBkb2VzIG5vdCBwcmVjbHVkZSBlaXRoZXIgY2FzZS4NCj4gDQo+PiAyLiBJdCBz YXlzIFZFIHBvc3Nlc3MgdGhlIHZhbGlkYXRpb24gZnVuY3Rpb24sIGJ1dCB0aGUgZGVzY3JpcHRp b24gb2YgVkUgaW4gdGhlIGltcGxlbWVudGF0aW9uICBzZWVtcyBWRSBpcyBvbmx5IGFuIGFnZW50 IHRvIHByZWZvcm0gdmFsaWRhdGlvbiwgc3VjaCBhcyBGaWd1cmUgNCBvZiBTZWMgNS4yIHRoYXQg VkUgZmV0Y2hlcyBpbmZvcm1hdGlvbiBmcm9tIE5BRSBhbmQgQXNzaWduZWUuDQo+IA0KPiB5ZXMs IHRoYXQncyBleGFjdGx5IGl0cyBwdXJwb3NlLiBUbyBoYW5kbGUgdGhlIHZhbGlkYXRpb24gcHJv Y2VzcywgaG93ZXZlcg0KPiB0aGF0IGlzIGltcGxlbWVudGVkLiBXaGF0IGRvIHlvdSBtZWFuIGJ5 ICJwb3Nlc3NpbmcgdGhlIHZhbGlkYXRpb24NCj4gZnVuY3Rpb24iPyBEbyB5b3UgbWVhbiB0aGF0 IHRoZSBWRSBwb3Nlc3NlcyBhbGwgcmVsZXZhbnQgZGF0YT8NCj4gDQo+PiAtLS0tc3VnZ2VzdGlv bjogVkUgcG9zc2VzcyB2YWxpZGF0aW9uIGRhdGFiYXNlIGFzIHRoZSB0aGlyZCB2YWxpZGF0aW9u IGNlbnRlciwgYW5kIG5lZWQgbm90IHRvIGlucXVpcmUgb2Ygb3RoZXIgZW50aXRpZXMgYWJvdXQg dGhlIGFzc2lnbmVlJ3MgaW5mb3JtYXRpb24gZHVyaW5nIHZhbGlkYXRpb24gcHJvY2Vzcy4NCj4g DQo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZSBvdGhlciB0d28gdmFsaWRhdGlvbiBjZW50 ZXJzIHdvdWxkIGJlLiBIb3dldmVyLA0KPiB0byBtYWtlIGl0IHdvcmsgYXMgeW91IGluZGljYXRl ZCwgeW91IHdvdWxkIG5lZWQgdG8gZm9yY2UgZXZlcnkgdGVsY28gaW4NCj4gZXZlcnkgY291bnRy eSBvZiB0aGlzIHdvcmxkIHRvIGhhbmQgb3ZlciBoaXMgY29tcGxldGUgY3VzdG9tZXIgZGF0YWJh c2UgdG8NCj4gYWxsIFZFcyBpbiB0aGF0IGNvdW50cnkgLSBpIGNhbid0IGltYWdpbmUgdGhhdCB0 aGlzIHdpbGwgaGFwcGVuIGFueXRpbWUgc29vbi4NCj4gDQo+IEFnYWluLCB3ZSBkbyBub3QgZXhj bHVkZSBhIGNhc2Ugd2hlcmUgYSBWRSBfY291bGRfIGhhdmUgdGhlIGluZm9ybWF0aW9uIHRoYXQN Cj4geW91IGRlc2NyaWJlIC0gb3VyIG1vZGVsIGdpdmVzIGZyZWVkb20gaW4gdGhpcyBwZXJzcGVj dGl2ZSBhcyB3ZWxsLg0KPiANCj4+IDMuIFNlYyAyIHJlcXVpcmVtZW50IG1lbnRpb25zICJyZWN1 cnJpbmcgdmFsaWRhdGlvbiIgb3IgInJldmFsaWRhdGlvbiIsIGFuZCBTZWMgNC4xIGRlc2NyaWJl cyByZXZhbGlkYXRpb24gd29ya2Zsb3cuIFdlIHRoaW5rIGl0IGlzIHJhdGhlciBjb21wbGV4IHdo ZW4gZXhwaXJhdGlvbiBvZiBFLjE2NCBudW1iZXIgYW5kIGV4cGlyYXRpb24gb2YgRU5VTSBkb21h aW4gbmFtZSBib3RoIG5lZWQgdG8gYmUgY29uc2lkZXJlZC4NCj4gDQo+IEluIG1hbnkgY291bnRy aWVzLCBFLjE2NCBudW1iZXJzIGRvIG5vdCAiZXhwaXJlIi4gTXkgcGFyZW50cyBoYXZlIHRoZWly DQo+IHBob25lIG51bWJlciBzaW5jZSBhYm91dCAyNSB5ZWFycywgdGhleSBldmVuIHN3aXRjaGVk IHRoZWlyIHRlbGNvcyBhIGZldw0KPiB0aW1lcywgYW5kIGtlcHQgdGhlaXIgbnVtYmVyLiBUaGVp ciBudW1iZXIgd2lsbCBiZSByZWxpbnF1aXNoZWQgd2hlbiB0aGV5DQo+IGNhbmNlbCB0aGVpciBw aG9uZSBsaW5lLCBidXQgdGhhdCdzIHVwIHRvIHRoZWlyIGRlY2lzaW9uLCBhbmQgbm90IHRpZWQg dG8NCj4gYW55IGRhdGUuDQo+IA0KPj4gLS0tLXN1Z2dlc3Rpb246IFBlcmlvZCBvZiBFLjE2NCBu dW1iZXIgdmFsaWRpdHkgbmVlZCB0byBiZSByZWZlcmVkIG9ubHkgd2hlbiBFLjE2NCBudW1iZXIg aXMgYXNzaWduZWQuIEFuZCBhZnRlciByZWdpc3RyYXRpb24gb2YgRU5VTSBkb21haW4gbmFtZSBh bmQgRU5VTSBzZXJ2aWNlcywgRS4xNjQgbnVtYmVyIHZhbGlkaXR5IGVxdWFscyB0byBFTlVNIGRv bWFpbiBuYW1lL3NlcnZpY2VzIHZhbGlkaXR5Lg0KPiANCj4gQXMgb3V0bGluZWQgYWJvdmUsIHRo ZXJlIGFyZSBleGlzdGluZyBudW1iZXJzIG91dCB0aGVyZSB3aGljaCBkbyBub3QgZXhwaXJlDQo+ ICJhdXRvbWF0aWNhbGx5Ii4gTW9zdCBvZiB0aGUgcGhvbmUgbnVtYmVycyBvdXQgdGhlcmUgYXJl IGFsc28gbm90IHRpZWQgdG8gYW4NCj4gRU5VTS1Eb21haW4sIGJlY2F1c2UgdGhlIGNvcnJlc3Bv bmRpbmcgRU5VTSBkb21haW4gaGFzIG5vdCBiZWVuIHJlZ2lzdGVyZWQuDQo+IFRoZXJlZm9yZSwg dGhlIHZhbGlkaXR5IG9mIHRoZSBFTlVNIGRvbWFpbiBjYW5ub3QgYmUgdGllZCB0byB0aGUgZXhw aXJhdGlvbg0KPiBvZiB0aGUgbnVtYmVyIGl0c2VsZi4gT2YgY291cnNlIHdvdWxkIGl0IGJlIGVh c2llciB0byBrbm93IHdoZW4gYSBjZXJ0YWluDQo+IG51bWJlciBpcyByZXR1cm5lZCwgYnV0IHRo aXMgaW5mb3JtYXRpb24gaXMgb25seSB3aXRoIHRoZSByZXNwZWN0aXZlIE5BRQ0KPiAod2hvIG1p Z2h0IG5vdCBjb29wZXJhdGUgd2l0aCB0aGUgcmVnaXN0cnkgZm9yIHRoaXMgcHVycG9zZSkuDQo+ IA0KPiBCdXQ6IHRoZXJlIG1pZ2h0IGJlIGNhc2VzIHdoZXJlIHJldmFsaWRhdGlvbiBpcyB0cml2 aWFsIChvciBub3QgZXZlbg0KPiByZXF1aXJlZCksIGVnLjoNCj4gDQo+IC0gdHJpdmlhbDogTGlr ZSBpbiBFeGFtcGxlIDUuMSwgd2hlcmUgdGhlIFNlcnZpY2UgcHJvdmlkZXIgYWN0cyBhcyB0aGUg TkFFDQo+IGFzIHdlbGwgYXMgdGhlIFJlZ2lzdHJhciBhbmQgdGhlIFZFLiBSZXZhbGlkYXRpb24g YmVjb21lcyBqdXN0IGEgbG9va3VwIGluDQo+IHRoZSBjdXN0b21lciBkYXRhYmFzZS4NCj4gDQo+ IC0gbm90IHJlcXVpcmVkOiBXaGVuIHRoZSBFTlVNIGRvbWFpbiBleGlzdGFuY2UgaXMgdGhlIGJh c2lzIGZvciB0aGUgbnVtYmVyDQo+IGFsbG9jYXRpb24gKGxpa2UgdGhlIEF1c3RyaWFuIG51bWJl ciByYW5nZSArNDMgNzgwKS4gQmVjYXVzZSBudW1iZXIgYW5kDQo+IGRvbWFpbiBhcmUgaW50cmlu c2ljYWxseSB0aWVkIHRvIGVhY2ggb3RoZXIgKGFuZCB0aGUgbnVtYmVyIGlzIGFjdHVhbGx5DQo+ IGNyZWF0ZWQgYW5kIGRlbGV0ZWQgd2hlbiB0aGUgRU5VTSBkb21haW4gaXMgY3JlYXRlZCBhbmQg ZGVsZXRlZCksIG5vDQo+IHJldmFsaWRhdGlvbiBpcyBuZWNjZXNzYXJ5Lg0KPiANCj4gVGhhdCdz IHRoZSByZWFzb24gZm9yIHRoZSAiSW4gbW9zdCBjYXNlcywgLi4uIiBhdCB0aGUgYmVnaW5uaW5n IG9mIHRoZQ0KPiByZXZhbGlkYXRpb24gd29ya2Zsb3cgLSB0aGF0IHRoZXJlIG1pZ2h0IGJlIHNj ZW5hcmlvcyB3aGVyZSBpdCdzIF9ub3RfDQo+IG5lY2Nlc3NhcnkgLSBkZWNpc2lvbiBhYm91dCB0 aGlzIGlzIGEgbG9jYWwgbWF0dGVyLCBhZ2Fpbi4NCj4gDQo+PiA0LiBUaGUgZGlmZmVyZW50IGVu dGl0aWVzIGhhdmUgZGlmZmVyZW50IGRlbWFuZHMgb2YgYmVuZWZpdCwgc28gaXQgaXMgZGlmZmlj dWx0IHRvIGxldmVsIHRoZSByZWxhdGlvbiBvZiBlYWNoIGVudGl0aWVzIGluIEVOVU0gcHJvdmlz aW9uIG1vZGVsLCBlc3BlY2lhbGx5IFJlZ2lzdHJ5LCBWYWxpZGF0aW9uIEVudGl0eSBhbmQgTnVt YmVyIEFzc2lnbm1lbnQgRW50aXR5Lg0KPj4gLS0tLXN1Z2dlc3Rpb246IFJlZ2lzdHJ5IGhhcyB0 aGUgcmlnaHQgdG8gZGVsZWdhdGUgTkFFLCBhbmQgTkFFIGlzIGFsc28gdGhlIFZFLg0KPiANCj4g QWdhaW4sIHRoaXMgcHJlY2x1ZGVzIGNlcnRhaW4gc2NlbmFyaW9zIChpbmNsdWRpbmcgbW9zdCBj dXJyZW50DQo+IGltcGxlbWVudGF0aW9ucyksIGJlY2F1c2U6IFRoZSBlbnRpdHkgdG8gYXBwb2lu dCBOQUVzIGlzIHRoZSBOUkEgKGluIG1vc3QNCj4gY2FzZXMgdGhlIHJlZ3VsYXRvciksIHNvIGlm IHlvdSByZXF1aXJlIHRoYXQgdGhlIFJlZ2lzdHJ5IGFwcG9pbnRzIE5BRXMgeW91DQo+IGVzc2Vu dGlhbGx5IHJlcXVpcmUgdGhlIHJvbGVzIG9mIFJlZ2lzdHJ5IGFuZCBOUkEgdG8gY29sbGFwc2Ug aW50byBvbmUNCj4gc2luZ2xlIGVudGl0eS4NCj4gDQo+IEJ5IHJlcXVpcmluZyB0aGF0IE5BRSBh bmQgVkUgYXJlIHRoZSBzYW1lIGVudGl0eSwgeW91IGNvbGxhcHNlIGFub3RoZXIgdHdvDQo+IHJv bGVzLg0KPiANCj4gV2hlbiB3ZSBzdGFydGVkIHdpdGggdGhlIGRyYWZ0LCBvdXIgZmVlbGluZyB3 YXMgdGhhdCBjb2xsYXBzaW5nIHJvbGVzIGlzDQo+IG11Y2ggZWFzaWVyIHRoYW4gc3BsaXR0aW5n IHRoZW0sIHNvIHdlIGNsZWFybHkgc2VwZXJhdGVkIGVhY2ggcm9sZSwgd2l0aG91dA0KPiBwcmVj bHVkaW5nIHRoYXQgYW4gZW50aXR5IG1heSBwZXJmb3JtIHNldmVyYWwgcm9sZXMuDQo+IA0KPiBT bywgYWNjb3JkaW5nIHRvIG91ciBkcmFmdCBhbmQgeW91ciBzY2VuYXJpbywgeW91IHdvdWxkIGhh dmU6DQo+IA0KPiBFbnRpdHkgIkEiLCB3aGljaCBhc3N1bWVzIHRoZSByb2xlIG9mIE5SQSBhbmQg UmVnaXN0cnkNCj4gRW50aXR5ICJCIiwgd2hpY2ggYXNzdW1lcyB0aGUgcm9sZSBvZiBOQUUgcGx1 cyBhIFZFDQo+IA0KPiBUaGlzIGlzIHBlcmZlY3RseSBwb3NzaWJsZSB3aXRoIG91ciBkb2N1bWVu dCwgYnV0IHVsdGltYXRlbHkgYSBuYXRpb25hbCBtYXR0ZXIuDQo+IA0KPj4gVGhlIGZvbGxvd2lu ZyBmaWd1cmUgZXhwbGFpbnMgb3VyIHBvaW50IG9mIHZpZXc6DQo+PiAgICAgICAgICstLS0tLS0t LS0tKw0KPj4gICAgICAgICB8IFJlZ2lzdHJ5IHwgXA0KPj4gICAgICAgICArLS0tLS0tLS0tLSsg IFwgDQo+PiAgICAgICAgICAgICAgXiAgICAgICAgIFwgDQo+PiAgICAgICAgICAgICAgfCAgICAg ICAgICBcDQo+PiAgICAgICAgICAgICAgfCAgICAgICAgICAgXA0KPj4gICAgICAgICAgICAgIHwg ICAgICAgICAgICBcIA0KPj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgXA0KPj4gICAgICAg ICAgICAgIHwgICAgICAgICAgICAgIFwNCj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg XCANCj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIFwgDQo+PiAgICAgICAgICAgICAg fCg4KSAgICAgICAgICAgICAgXCg5KQ0KPj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICBcIA0KPj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgXA0KPj4gICAgICAgICAg ICAgIHwgICAgICAgICAgKDYpICAgICAgIHYNCj4+ICAgICAgICAgKy0tLS0tLS0tLS0tKyAtLS0t LS0tLS0tPistLS0tLS0tLS0rDQo+PiAgICAgICAgIHwgUmVnaXN0cmFyIHw8LS0tLS0tLS0tLSB8 IE5BTShWRSkgfA0KPj4gICAgICAgICArLS0tLS0tLS0tLS0rICAgKDcpICAgID4gKy0tLS0tLS0t LSsNCj4+ICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgICAgICAgXiAgfA0KPj4gICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICB8DQo+PiAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIHwgIHwNCj4+ICAgICAgICAgICAgICB8KDUpICAgICAgICAgICAgICAg ICAgfCAgfA0KPj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAoMil8ICB8DQo+PiAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgIHwNCj4+ICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgfCAgfA0KPj4gICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8ICB8DQo+PiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgIHwo MykNCj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgfA0KPj4gICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICBWDQo+PiAgICAgICAgKy0tLS0tLS0tLS0t LSsgICAgKDQpICAgICArLS0tLS0tLS0tKyANCj4+ICAgICAgICB8IEFzc2lnbmVlID0gfDwtLS0t LS0tLS0tIHwgIE5BQUUgICB8DQo+PiAgICAgICAgfCBSZWdpc3RyYW50IHwtLS0tLS0tLS0tPiB8 ICAgICAgICAgfA0KPj4gICAgICAgICstLS0tLS0tLS0tLS0rICAgICgxKSAgICAgKy0tLS0tLS0t LSsNCj4+IA0KPj4gICAgICAgICAgTkFNOiBOdW1iZXIgQXNzaWdubWVudCBNYW5hZ2VtZW50DQo+ PiAgICAgICAgICBOQUFFOiAgTnVtYmVyIEFzc2lnbm1lbnQgQWdlbnQgRW50aXR5DQo+PiAgICAg ICAgICBWRTogICBWYWxpZGF0aW9uIEVudGl0eQ0KPj4gDQo+PiAgICAoMSkgVGhlIEFzc2lnbmVl IGFwcGx5cyBmb3IgYW4gRS4xNjQgbnVtYmVyIGZyb20gTkFBRSBhbmQgc3VibWl0cyBwZXJzb25h bCBwYXJ0aWN1bGFyIGluZm9ybWF0aW9uIC4NCj4+ICAgICgyKSBOQUFFIHNlbmRzIEFzc2lnbmVl J3MgaW5mb3JtYXRpb24gYW5kIHRoZSBhcHBsaWVkIEUuMTY0IG51bWJlciB0byBOQU0uDQo+PiAg ICAoMykgTkFNIGNoZWNrcyB3aGV0aGVyIHRoZSBFLjE2NCBudW1iZXIgaGFzIGJlZW4gYXNzaWdu ZWQgaW4gaXRzIFZhbGlkYXRpb24gZGF0YWJhc2UsIGlmIG5vdC1hc3NpZ25lZCBhZGRzIHJlY29y ZCBpbiBkYXRhYmFzZShBc3NpZ25lZSdzIGluZm9ybWF0aW9uIGFuZCB0aGUgYXBwbGllZCBFLjE2 NCBudW1iZXIgYXJlIHVzZWQgYXMgdmFsaWRhdGlvbiBpbmZvcm1hdGlvbiwgYW5kIHBlcmlvZCBv ZiBFTlVNIHZhbGlkaXR5IGlzIGNyZWF0ZWQpIGFuZCByZXR1cm5zIHN1Y2Nlc3NmdWwgcmVzdWx0 LCBvdGhlcndpc2UgcmV0dXJucyBmYWlsZWQgcmVzdWx0Lg0KPj4gICAgKDQpIE5BQUUgdGVsbHMg QXNzaWduZWUgdGhlIHJlc3VsdCBnb3QgZnJvbSBOQU0uDQo+PiAgICAoNSkgVGhlIEFzc2lnbmVl IGFwcGxpZXMgdGhlIGNvcnJlc3BvbmRpbmcgRU5VTSBkb21haW4gbmFtZSBhdCBhIEVOVU0gUmVn aXN0cmFyLg0KPj4gICAgKDYpIFRoZSBSZWdpc3RyYXIgcmVxdWVzdHMgdmFsaWRhdGlvbiBhdCBO QU0oVkUpLg0KPj4gICAgKDcpIFRoZSBWRSB2ZXJpZnkgdGhhdCB0aGUgQXNzaWduZWUgb2YgdGhl IEUuMTY0IG51bWJlciBjb3JyZXNwb25kcyB0byB0aGUgUmVnaXN0cmFudCBvZiB0aGUgRU5VTSBk b21haW4gbmFtZSBhbmQgcmV0dXJuIHJlc3VsdC4NCj4+ICAgICg4KSBUaGUgUmVnaXN0cmFyIHNl bmRzIGFuIEVOVU0gcmVnaXN0cmF0aW9uIHJlcXVlc3QgdG8gdGhlIFJlZ2lzdHJ5LiBBZGRpdGlv bmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSB2YWxpZGF0aW9uIHByb2Nlc3MgbWlnaHQgYmUgc2Vu dCBhbG9uZyB3aXRoIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdC4NCj4+ICAgICg5KSBGaW5hbGx5 LCBSZWdpc3RyeSBzZW5kcyB0byBOQU0gdGhlIGluZm9ybWF0aW9uIHRoYXQgdGhlIGNlcnRhaW4g RS4xNjQgbnVtYmVyIGhhcyBiZWVuIHVzZWQuKHRoaXMgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBy ZW5ldyBwZXJpb2Qgb2YgRU5VTSB2YWxpZGl0eSkNCj4gDQo+IE1vc3Qgb2Ygd2hhdCB5b3UgZGVz Y3JpYmVkIGFib3ZlIHNvdW5kcyBsaWtlIHlvdSdyZSBwcm9wb3NpbmcgYW4gYWN0dWFsDQo+IHZh bGlkYXRpb24gbWV0aG9kLiBPdXIgZHJhZnQgZG9lcyBub3QgZG8gdGhpcyBmb3IgYSByZWFzb246 IGl0IHJlZHVjZXMNCj4gZmxleGliaWxpdHkuDQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgaSB0 aGluayB0aGF0IG91ciByb2xlIGRlZmluaXRpb24gZml0cyBwcmV0dHkgd2VsbCBpbnRvDQo+IHlv dXIgbWV0aG9kIC0gdGhlIGVudGl0eSB3aGljaCBzZXJ2ZXMgYXMgVkUganVzdCBhc3N1bWVzIGFu b3RoZXIgbmV3IHJvbGUNCj4gdGhhdCB5b3UgZGVmaW5lZCBmb3IgeW91ciBtZXRob2QgKHRoZSBO QU0pLCBhbmQgeW91IGludHJvZHVjZSBhbm90aGVyIHJvbGUNCj4gKHRoZSBOQUFFKS4NCj4gDQo+ IEdlbmVyYWxseSwgaSBkb24ndCBzZWUgaG93IHRoZSBtZXRob2QgdGhhdCB5b3UgcHJvcG9zZWQg YWJvdmUgd291bGQgd29yaw0KPiB3aXRoIGFscmVhZHkgYXNzaWduZWQgbnVtYmVycywgYmVjYXVz ZSB2ZXJpZnlpbmcgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlDQo+IEFzc2lnbmVlIGluIHRo ZSBmaXJzdCBwbGFjZSBkb2VzIG5vdCBzZWVtIHRvIG1ha2UgbXVjaCBzZW5zZS4NCj4gDQo+PiBU aGUgYmVuZWZpdHMgb2Ygb3VyIG9waW5pb24gYXJlIGFzIGZvbGxvd2luZzoNCj4+IDEuUmVnaXN0 cnkgZ2V0cyBkZWxlZ2F0aW9uIGZyb20gZ292ZXJubWVudCBhbmQgYW5zd2VyIGZvciB0aGUgd2hv bGUgcHJvY2VzcyBvZiBFTlVNIG51bWJlciBhc3NpZ25tZW50IGFuZCBFTlVNIGRvbWFpbiBuYW1l IHJlZ2lzdHJhdGlvbiwgd2hpY2ggY2FuIGF2b2lkIGJlbmVmaXQgYW5kIHJlc3BvbnNpYmlsaXR5 IG9mIGRpZmZlcmVudCBlbnRpdGllcy4NCj4gDQo+IEFnYWluLCBvdXIgbW9kZWwgYWxsb3dzIHRv IGNvbGxhcHMgc2V2ZXJhbCByb2xlcyBpbnRvIGEgc2luZ2xlIGVudGl0eSBhcyB5b3UNCj4gYXJl IHByb3Bvc2luZy4gV2UncmUgbm90IHNheWluZyB0aGF0IHRoZSBlbnRpdHkgb3BlcmF0aW5nIHRo ZSByZWdpc3RyeSBtdXN0DQo+IG5vdCBhc3N1bWUgYW55IG90aGVyIHJvbGUgYXMgd2VsbC4NCj4g DQo+PiAyLlVuaWZpY2F0aW9uIG9mIEVOVU0gbnVtYmVyIGV4cGlyYXRpb24gYW5kIEVOVU0gZG9t YWluIG5hbWUgZXhwaXJhdGlvbiBjYW4gcmVkdWNlIG9wZXJhdGlvbiBhbmQgY29tYmluZSB0aGUg RU5VTSBudW1iZXIgYW5kIEVOVU0gZG9tYWluIG5hbWUvRU5VTSBzZXJ2aWNlcy4NCj4gDQo+IEkg ZG9uJ3QgdGhpbmsgeW91IGNhbiBjaGFuZ2UgdGhlIHdheSBFLjE2NCBudW1iZXJzIGFyZSBhc3Np Z25lZCwgYW5kDQo+IHRoZXJlZm9yZSwgYXBwbHlpbmcgYW4gZXhwaXJhdGlvbiBvbiBudW1iZXJz IGlzIG5vdCBhbiBvcHRpb24uDQo+IA0KPiBBZGRpdGlvbmFsbHksIEUuMTY0IG51bWJlcnMgYW5k IEVOVU0gZG9tYWlucyBhcmUgYXNzaWduZWQgY29tcGxldGVseQ0KPiBpbmRlcGVuZGVudCAtIHRo YXQgd2FzIHRoZSByZWFzb24gaW4gdGhlIGZpcnN0IHBsYWNlIHdoeSBFTlVNIHZhbGlkYXRpb24g d2FzDQo+IG5lY2Nlc3NhcnkuIElmIGJvdGggYWRkcmVzc2luZyBlbGVtZW50cyB3b3VsZCBiZSBh c3NpZ25lZCB0b2dldGhlciwNCj4gdmFsaWRhdGlvbiB3b3VsZCBiZSBzdXBlcmZsb3VzIChhcywg YWdhaW4sIGl0IGlzIHRoZSBjYXNlIGZvciArNDMgNzgwKS4NCj4gDQo+PiAzLkluZGVwZW5kZW5j ZSBvZiBWRSBwcm92aWRlcyByYXRoZXIgYWJzb2x1dGUgdmFsaWRhdGlvbiBkYXRhYmFzZSwgYW5k IGlzIHVzZWZ1bCBmb3IgbWFuYWdlbWVudCBhbmQgdmFsaWRhdGlvbiBvZiBFTlVNIGFwcGxpY2F0 aW9uLg0KPiANCj4gU29ycnksIGkgZGlkbid0IGdldCB0aGlzIHBvaW50LiBDb3VsZCB5b3UgZWxh Ym9yYXRlIG9uIHRoaXM/DQo+IA0KPiANCj4gaSBob3BlIHRoYXQgY2xhcmlmaWVzIHNvbWUgb2Yg dGhlIGlzc3VlcyAtIGkgZGlkbid0IHRhbGsgdG8gYmVybmllIHlldCwgc28NCj4gaGUgbWlnaHQg aGF2ZSBtb3JlIGNvbW1lbnRzIG9uIHlvdXIgc3VnZ2VzdGlvbnMuIFBsZWFzZSBkb24ndCBoZXNp dGF0ZSB0bw0KPiBjb250YWN0IHVzIGFnYWluIGlmIHRoZXJlJ3MgYW55dGhpbmcgd2hpY2ggcmVt YWlucyB1bmNsZWFyLg0KPiANCj4gdGhhbmtzLA0KPiANCj4gQWxleA0KPg== --===============0996427730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0996427730==-- From enum-bounces@ietf.org Wed Aug 23 08:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrS5-0007b6-Jp; Wed, 23 Aug 2006 08:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrS3-0007ac-Hx; Wed, 23 Aug 2006 08:03:19 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFrS2-00044g-0X; Wed, 23 Aug 2006 08:03:19 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 23 Aug 2006 14:03:14 +0200 id 0007C09E.44EC4402.00001770 Message-ID: <44EC43BB.50701@enum.at> Date: Wed, 23 Aug 2006 14:02:03 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable To: chenhui Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> In-Reply-To: <356324682.20236@cnnic.cn> X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: enum@ietf.org, =?GB2312?B?s8LBwQ==?= , iesg@ietf.org, =?GB2312?B?J831ILflJw==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org chenhui wrote: > Thank you for your detailed explanation=A3=A1 > After think again, we highly agree with the flexibility of your draft. > > And the suggestions we mention mainly proceed from actual domestic sit= uation and some extension. I'm happy to hear that our draft fits your actual implementation plans - that's the proof that it's flexible enough. > As you bring out in the other draft "Telephone Number Mapping and Doma= in Keys as a Distributed Identity Infrastructure" that ENUM number can = be used the identifier for many application such as P2P Communication/Vo= IP, we are also carring on this study. Thus, in order to insure authenti= city of ENUM user's information, we consider the following question 1 an= d 2. And question 3 and 4 is about number transfer and revalidation. > > 1. We think the validation includes two aspects, one is the registrant= 's authenticity, the other is that ENUM registrant is the same with E.16= 4 holder. exactly. See section 2 of the draft. > In Austrian model, "ENUM domain existence is the basis for the number = allocation", ENUM domain registration is on internet, thus, how to insur= e the user's authenticity? Or you consider nobody will submit the mendac= ious information? The "number follows ENUM" model is only applied to one special number ra= nge (+43 780). In all other number ranges, the ENUM domain follows an existi= ng number. For the special number range mentioned above, numbers may be allocated anonymously. For validation purposes, i don't need to know _who_ the own= er of the number is as long as number holder and ENUM domain name holder ar= e the same (anonymous numbers are possible in that range). If someone ente= rs wrong data for such a number, he will have a hard time recovering it onc= e he eg. lost his password or wants to change ISP. There might be other validation methods where you don't need to know _wh= o_ the number holder is, as long as you can ensure the requirements, eg. a SMS-loop to a mobile phone may be fine for ENUM validation, but does not transport any number holder information. > 2. The third VE we mentioned is the neutral validation entity, which h= as responsibility for validation of the ENUM registration and applicatio= n. > The draft shows NAE/CSP can be trusted. But actually, VoIP service pro= viders in many countries may be lack of enough supervisal, and if certai= n VoIP provider goes bankrupt, transfering of users' information belonge= d to the VoIP provider will be a problem, so we prefer to trust the thir= d/neutral VE who holds the total users's information. It's the same issue when a classical telco goes bankrupt. Yes, we had th= at already in Austria, where all of a sudden several thousands of customers were disconnected because of such a case. So, this is not special to ENU= M. > 3. You did not mention ENUM number transfer, and is it possible to tra= nsfered an ENUM number from one person to another as genaral domain tran= sfer? > If ENUM number permits to be transfered, then we think the Number Assi= gnment Entity of a national range is prefered, so that users can apply E= NUM number from any number assignment agents. Also, if certain ENUM numb= er is transfered, NAE needs to tell Registry/Registrar the transfered in= formation. Our local assupmtion is that the new Registrar needs to re-perform initi= al validation, and then can issue a transfer request. Additionally, there are no ties between a special NAE and a special VE o= r registrar. You can register any Austrian number at any registrar (given = he accepts you as a customer, of colurse ;). > 4. We want to confirm whether the revalidation in the draft denotes th= at ENUM validation itself has expiration date as all kinds of validation= , so if ENUM delegation is beyond expiration date, revalidation is neede= d. > Furthermore, if ENUM number can be cancelled or transfered, maybe ENUM= revalidation is needed. The actual expiry of validation information is local policy. eg. for "normal" number ranges in Austria, the max. validity is 6 months, for th= ose "special" number range listed above the validation does not expire at al= l. Our general assumption in the draft (see section 4.1) is that ENUM delegations for which no valid validation (sic!) exists need to be suspe= nded from DNS (however that might be implemented). > BTW, E.164 number maybe has expiration time in some countries such as = China. For example, a person apply one E.164 number(of course including = telecommunication service) from CSP, and the default expiration time is = usually three months, then if the person donnot pay again, the telecommu= nication service will be stopped and the number will be taken back and r= eassigned. yes, in that case it might be desireable to tie the validation expiry to= the expiration of the number itself. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 23 09:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsN9-0002iM-87; Wed, 23 Aug 2006 09:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsN7-0002iG-Vw for enum@ietf.org; Wed, 23 Aug 2006 09:02:17 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsN5-0007Zw-JH for enum@ietf.org; Wed, 23 Aug 2006 09:02:17 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7ND2Jb2004041; Wed, 23 Aug 2006 06:02:24 -0700 From: "Richard Shockey" To: Date: Wed, 23 Aug 2006 09:01:54 -0400 Message-ID: <018001c6c6b4$52bdc820$54201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbGtE7nB0YrTEj7QGKgOCOAmC2i4Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'Cullen Jennings' , =?iso-8859-1?Q?'=22Patrik_F=E4ltstr=F6m=22'?= , "'Peterson, Jon'" Subject: [Enum] ENUM WG Last Call on draft-conroy-enum-edns0-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Title : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-conroy-enum-edns0-02.txt Pages : 16 Date : 2006-6-29 Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document updates RFC 3761 only in adding this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-02.txt The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 1 month or so from today August 23 until at least September 23 though we can modify that if new issues come up. The purpose of the extended WGLC is to accommodate the summer vacation schedules of WG participants. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 23 09:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsqt-0007YV-2l; Wed, 23 Aug 2006 09:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsqs-0007YA-7j; Wed, 23 Aug 2006 09:33:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFr4H-0005M3-N3; Wed, 23 Aug 2006 07:38:45 -0400 Received: from kentucky.ucd.ie ([193.1.169.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFr1h-0006Gw-No; Wed, 23 Aug 2006 07:36:10 -0400 Received: from conversion-daemon.kentucky.ucd.ie by kentucky.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0J4G005017KPWO00@kentucky.ucd.ie> (original mail from Niall.oReilly@ucd.ie); Wed, 23 Aug 2006 12:35:54 +0100 (IST) Received: from [137.43.2.214] by kentucky.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0J4G00LD187TAOA0@kentucky.ucd.ie>; Wed, 23 Aug 2006 12:35:53 +0100 (IST) Date: Wed, 23 Aug 2006 12:38:04 +0100 From: Niall O'Reilly Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) In-reply-to: <356324682.20236@cnnic.cn> To: chenhui Message-id: <26706F5D-44AD-4C6B-B4BA-059F223A223C@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 X-Gpgmail-State: !signed References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> X-Spam-Score: -2.6 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, =?UTF-8?B?6ZmI5Lqu?= , Niall O'Reilly , =?UTF-8?Q?'=E7=8E=8B_=E5=B3=B0'?= , iesg@ietf.org, Alexander Mayrhofer X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 23 Aug 2006, at 10:18, chenhui wrote: > 1. We think the validation includes two aspects, one is the > registrant's authenticity, the other is that ENUM registrant is the > same with E.164 holder. > In Austrian model, "ENUM domain existence is the basis for the > number allocation", ENUM domain registration is on internet, thus, > how to insure the user's authenticity? Or you consider nobody will > submit the mendacious information? If I've understood correctly, this is for a special category of number: the kind of number whose allocation is coupled to an ENUM registration. In this case, the E.164 number and the ENUM domain are aspects of a single transaction, and are simultaneously issued to the same subscriber/ registrant; validation is thereby considerably simplified. If "mendacious information" is involved, the same mendacious information is necessarily attached to both the number and the domain. /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 23 11:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuG6-0006v1-TY; Wed, 23 Aug 2006 11:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuG5-0006uf-MN; Wed, 23 Aug 2006 11:03:09 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuG2-0007f9-Cp; Wed, 23 Aug 2006 11:03:09 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 23 Aug 2006 16:57:14 +0200 id 0007C09E.44EC6CCB.000036D7 Message-ID: <44EC6C82.5000606@enum.at> Date: Wed, 23 Aug 2006 16:56:02 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Niall O'Reilly Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> <44EC43BB.50701@enum.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: enum@ietf.org, =?windows-1252?Q?=27=3F_=3F=27?= , iesg@ietf.org, =?windows-1252?Q?=3F=3F?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Niall O'Reilly wrote: >> yes, in that case it might be desireable to tie the validation expiry >> to the >> expiration of the number itself. > > Or arrange that the period for which a validation is effective is > related to the > period for which an expired number is routinely quarantined before > re-assignment. That was exactly the reason for those "6 months" we chose - it's the roughly agreed "cooldown" period for geographic numbers in Austria. Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 23 13:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwJL-0001fX-UB; Wed, 23 Aug 2006 13:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwJK-0001ah-HX; Wed, 23 Aug 2006 13:14:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuBU-0006ga-Ki; Wed, 23 Aug 2006 10:58:24 -0400 Received: from dakota.ucd.ie ([193.1.169.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFtwp-0003OJ-8N; Wed, 23 Aug 2006 10:43:17 -0400 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0J4G00M019Y7PD00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) ; Wed, 23 Aug 2006 13:22:22 +0100 (IST) Received: from [137.43.2.214] by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0J4G00EA4AD9I410@dakota.ucd.ie>; Wed, 23 Aug 2006 13:22:21 +0100 (IST) Date: Wed, 23 Aug 2006 13:24:32 +0100 From: Niall O'Reilly Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) In-reply-to: <44EC43BB.50701@enum.at> To: Alexander Mayrhofer Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Gpgmail-State: !signed References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> <44EC43BB.50701@enum.at> X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, =?UTF-8?B?6ZmI5Lqu?= , =?UTF-8?Q?'=E7=8E=8B_=E5=B3=B0'?= , iesg@ietf.org, Niall O'Reilly X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 23 Aug 2006, at 13:02, Alexander Mayrhofer wrote: > Our general assumption in the draft (see section 4.1) is that ENUM > delegations for which no valid validation (sic!) exists need to be > suspended > from DNS (however that might be implemented). > >> BTW, E.164 number maybe has expiration time in some countries such >> as China. For example, a person apply one E.164 number(of course >> including telecommunication service) from CSP, and the default >> expiration time is usually three months, then if the person donnot >> pay again, the telecommunication service will be stopped and the >> number will be taken back and reassigned. > > yes, in that case it might be desireable to tie the validation > expiry to the > expiration of the number itself. Or arrange that the period for which a validation is effective is related to the period for which an expired number is routinely quarantined before re- assignment. This approach would provide for resynchronization of validity between the number and the the ENUM validation token in case the expiry date of the number is not conveniently available to the VE, or that the number has to be prematurely withdrawn for commercial or operational reasons. /Niall _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 24 04:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnl-00080W-P8; Thu, 24 Aug 2006 04:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnk-0007r7-6L for enum@ietf.org; Thu, 24 Aug 2006 04:43:00 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGAiL-00071l-2F for enum@ietf.org; Thu, 24 Aug 2006 04:37:26 -0400 Received: (eyou send program); Thu, 24 Aug 2006 16:36:59 +0800 Message-ID: <356408619.13809@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.146 with SMTP; Thu, 24 Aug 2006 16:36:59 +0800 Message-ID: <00b501c6c758$7c4c6a30$6306e29f@cnnicchenh> From: "chenhui" To: "Alexander Mayrhofer" References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> <356334594.21857@cnnic.cn> Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) Date: Thu, 24 Aug 2006 16:37:07 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.0 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: enum@ietf.org, =?gb2312?B?s8LBwQ==?= , iesg@ietf.org, =?gb2312?B?J831ILflJw==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635397564==" Errors-To: enum-bounces@ietf.org --===============0635397564== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGV4LA0KDQpUaGFuayB5b3UsIGFuZCB3ZSBoYXZlIGFsbW9zdCB1bmRlcnN0YW5kZWQg eW91ciBvcGluaW9ucy4NCg0KVGhlIHJlYXNvbiB3ZSBtZW50aW9uIG5ldXRyYWwgVkUgaXMgdGhh dCB3ZSBjYXJlIHNvIG11Y2ggYWJvdXQgYXV0aGVudGljaXR5IG9mIEVOVU0gdXNlcnMuIA0KDQpJ ZiBOQUVzIGNhbiBiZSB0cnVzdGVkIGluIHRoZSBkcmFmdCwgd2Ugd29uZGVyIHdoZXRoZXIgX05B RXNfIGhhdmUgdGhlIHR3byBmdW5jdGlvbnM6DQoxLiBOQUVzIGhhdmUgcmVzcG9uc2liaWxpdHkg Zm9yIGF1dGhlbnRpY2l0eSBvZiB0aGUgRU5VTSBudW1iZXIgaG9sZGVycy4gKGV4Y2VwdCB0aGUg Y2FzZSBvZiAiKzQzNzgwIiBudW1iZXIgcmFuZ2VzKQ0KMi4gQXNzaWduZWUgY2FuIGJlIGFzc2ln bmVkIF9hbnlfIEVOVU0gbnVtYmVyIGZyb20gYW55IF9OQUVfIGluIG9yZGVyIHRvIG1ha2UgRU5V TSBudW1iZXIgdHJhbnNmZXIgbW9yZSBjb252ZW5pZW50bHkuIChZb3UgaGF2ZSBleHBsYWluZWQg IllvdSBjYW4gcmVnaXN0ZXIgYW55IEF1c3RyaWFuIG51bWJlciBhdCBhbnkgX3JlZ2lzdHJhcl8i IGluIHRoZSBsYXN0IGxldHRlci4gQnV0IGlmIEVOVU0gbnVtYmVyIGlzIG5vdCArNDM3ODAgbnVt YmVyLCBtYXliZSB0aGUgdXNlciBnZXRzIG51bWJlciBiZWZvcmUgZG9tYWluKS4NCg0KKioqKioq KioqKioqKioqKioNCg0KV2UgaGF2ZSB0aGUgZm9sbG93aW5nIG9waW5pb24gdG8gc2hhcmUgd2l0 aCB5b3U6DQoNCkVOVU0sIGFzIGEgYnJpZGdlIG9mIHRlbGVjb21tdW5pY2F0aW9uIGFuZCBpbnRl cm5ldCwgc2hvdWxkIGJlIGFibGUgdG8gcHJvbW90ZSB0aGUgYXBwbGljYXRpb25zIG9mIHR3byBu ZXR3b3Jrcy4gQXMgdGltZSBhcyBkZXZlbG9waW5nIEVOVU0sIHRoZSBpbmZsdWVuY2Ugb2YgVm9J UCwgdGhlIG1vc3QgaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9mIEVOVU0sIHRvIHRyYWRpdGlvbmFs IHRlbGVjb21tdW5pY2F0aW9uIG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQuDQoNCkluIHRyYWRpdGlv bmFsIHRlbGVjb21tdW5pY2F0aW9uLCBhdXRoZW50aWNpdHkvY29uc2lzdGVuY3kvdmFsaWRpdHkg b2YgdGhlIHVzZXIncyBpZGVudGl0eSBjYW4gYmUgZ3VhcmFudGVlZCBiZWNhdXNlIEUuMTY0IG51 bWJlciBpcyBhc3NpZ25lZCBhY2NvcmRpbmcgdG8gcmVhbCBpZGVudGl0eSBhbmQgdGhlIG51bWJl ciBpcyB0aWVkIHRvIGEgY2VydGFpbiB0ZXJtaW5hbC4gQnV0IGl0IGlzIGRpZmZlcmVudCBmb3Ig Vm9JUCBzZXJ2aWNlKGEgdXNlciBjYW4gZ2V0IGEgVm9JUCBhY2NvdW50IGJ5IGludGVyZW50IHJl Z2lzdHJhdGlvbiwgZXZlbiB0aGUgdXNlciBjYW4gYmUgbG9naW4gZnJvbSBhbnl3aGVyZSBhbmQg dXNlIFZvSVAgc2VydmljZSkuDQoNCklmIGF1dGhlbnRpY2l0eSBvZiBFTlVNIHVzZXJzIGlzIGVu c3VyZWQgZHVyaW5nIEVOVU0gcmVnaXN0cmF0aW9uIGFuZCBhcHBsaWNhdGlvbiwgd2UgdGhpbmsg bWF5YmUgRU5VTSBjYW4gcHJvdmlkZSBhcyBhbiBpbXBvcnRhbnQgdXNlcidzIHZhbGlkYXRpb24g bWVjaGFuaXNtIGZvciBWb0lQLCB0byBwcmV2ZW50IGZhbHNpZmljYXRpb24gYW5kIHdhcnJhbnQg c29tZSBzZWN1cml0eS4gRnVydGhlcm1vcmUsIEVOVU0gY2FuIGJlIHVzZWQgaW4gTkdOLzNHIHRv IHByb3ZpZGUgYSBraW5kIG9mIGNyZWRpdGFibGUgYW5kIHNlY3VyZSBhZGRyZXNzaW5nIHRlY2hu b2xvZ3kuDQoNClNvIHdlIGNvbnNpZGVyIHdoZXRoZXIgdGhlIGRyYWZ0IGNvdWxkIG1lbnRpb24g c29tZSBtYXR0ZXJzIG9mIEVOVU0gdXNlcnMnIGF1dGhlbnRpY2l0eS4NCg0KVGhlIHZhbGlkYXRp b24gYXJjaGl0ZWN0dXJlIHdlIG1lbnRpb25lZCB3aGljaCBlbXBoYXNpemVzIHRoZSBmdW5jdGlv biBvZiBWRSBpcyBqdXN0IGZvciBFTlVNIHVzZXJzJyBhdXRoZW50aWNpdHkuIEFjdHVhbGx5LCB0 aGlzIHZhbGlkYXRpb24gYXJjaGl0ZWN0dXJlIGhhcyBub3QgbXVjaCBkaWZmZXJlbmNlIHdpdGgg dGhlIGFyY2hpdGVjaHR1cmUgbWVudGlvbmVkIGluIHlvdXIgZHJhZnQsIGFuZCB0aGUgbWFpbiBk aWZmZXJlbmNlIGlzIHRoYXQgVkUgbmVlZHMgdG8gc3RvcmUgdXNlcnMnIGluZm9ybWF0aW9uLiBJ ZiBFTlVNIHRyYW5zZmVyIGhhcHBlbnMgb3IgTkFFL0NTUC9Wb0lQIFNQIGdvZXMgYmFua3J1cHQs IHRoZSBkYXRhIGNhbiBiZSB0cmFuc2ZlcmVkIG9yIHJlc2VydmVkIGVmZmVjdGl2ZWx5IC0tLSB3 aGljaCBpcyBzaW1pbGFyIHdpdGggdGhlIG1hbmFnZW1lbnQgb2YgZG9tYWluIG5hbWVzIGluIGRv bWFpbiBzeXN0ZW0gYmV0d2VlbiBkb21haW4gbmFtZSBSZWdpc3RyeSBhbmQgcmVnaXN0cmFyLiBJ dCBtYWtlcyByZXNvbHV0aW9uIGluZGVwZW5kZW50IG9mIHJlZ2lzdHJhdGlvbi4gQWxzbywgYSBy ZXBsaWNhIG9mIG51bWJlciBhbGxvY2F0aW9uIGF0IFZFIGNhbiBtYWtlIHZhbGlkYXRpb24gbW9y ZSBlZmZpY2llbnQuDQoNCkFuZCBhbHNvLCBpZiB0aGVyZSBpcyBhIChOdW1iZXIgQXNzaWdubWVu dCBNYW5hZ2VtZW50KSB0byBjb21tdW5pY2F0aW9uIHdpdGggUmVnaXN0cnksIGl0IHdpbGwgYmUg bW9yZSBlYXN5IHRvIGltcGxlbWVudCBhbmQgcHJvdmlkZSBzdGFuZGFyZGl6ZWQgRU5VTSBzZXJ2 aWNlcy4gVGhlcmVmb3JlLCBhbiBpbmRlcGVuZGVudCBOQU0vVkUgaXMgbmVlZGVkLCBpdCB3aWxs IGRvIGdvb2QgdG8gc3VwZXJ2aXNhbCBvZiBnb3Zlcm5tZW50IHRvby4NCg0KQmVzdCBXaXNoZXMh DQoNCllvdXJzIFNpbmNlcmVseSwNCkNoZW5odWksIFdhbmdmZW5nLCBDaGVubGlhbmcNCg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXhhbmRlciBNYXlyaG9mZXIi IDxhbGV4YW5kZXIubWF5cmhvZmVyQGVudW0uYXQ+DQpUbzogImNoZW5odWkiIDxjaGVuaHVpQGNu bmljLmNuPg0KQ2M6IDxpZXNnQGlldGYub3JnPjsgPGVudW1AaWV0Zi5vcmc+OyAiJ831ILflJyIg PGZlbmd3QGNubmljLmNuPjsgIrPCwcEiIDxjaGVubGlhbmdAY25uaWMuY24+DQpTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAyMywgMjAwNiA4OjAyIFBNDQpTdWJqZWN0OiBSZTogW0VudW1dIExhc3Qg Q2FsbDogJ0VOVU0gVmFsaWRhdGlvbiBBcmNoaXRlY3R1cmUnIHRvIEluZm9ybWF0aW9uYWwgUkZD IChkcmFmdC1pZXRmLWVudW0tdmFsaWRhdGlvbi1hcmNoKQ0KDQoNCj4gY2hlbmh1aSB3cm90ZToN Cj4+IFRoYW5rIHlvdSBmb3IgeW91ciBkZXRhaWxlZCBleHBsYW5hdGlvbqOhDQo+PiBBZnRlciB0 aGluayBhZ2Fpbiwgd2UgaGlnaGx5IGFncmVlIHdpdGggdGhlIGZsZXhpYmlsaXR5IG9mIHlvdXIg ZHJhZnQuDQo+PiANCj4+IEFuZCB0aGUgc3VnZ2VzdGlvbnMgd2UgbWVudGlvbiBtYWlubHkgcHJv Y2VlZCBmcm9tIGFjdHVhbCBkb21lc3RpYyBzaXR1YXRpb24gYW5kIHNvbWUgZXh0ZW5zaW9uLg0K PiANCj4gSSdtIGhhcHB5IHRvIGhlYXIgdGhhdCBvdXIgZHJhZnQgZml0cyB5b3VyIGFjdHVhbCBp bXBsZW1lbnRhdGlvbiBwbGFucyAtDQo+IHRoYXQncyB0aGUgcHJvb2YgdGhhdCBpdCdzIGZsZXhp YmxlIGVub3VnaC4NCj4gDQo+PiBBcyB5b3UgYnJpbmcgb3V0IGluIHRoZSBvdGhlciBkcmFmdCAi VGVsZXBob25lIE51bWJlciBNYXBwaW5nIGFuZCBEb21haW4gS2V5cyAgYXMgYSBEaXN0cmlidXRl ZCBJZGVudGl0eSBJbmZyYXN0cnVjdHVyZSIgdGhhdCBFTlVNIG51bWJlciBjYW4gYmUgdXNlZCB0 aGUgaWRlbnRpZmllciBmb3IgbWFueSBhcHBsaWNhdGlvbiBzdWNoIGFzIFAyUCBDb21tdW5pY2F0 aW9uL1ZvSVAsIHdlIGFyZSBhbHNvIGNhcnJpbmcgb24gdGhpcyBzdHVkeS4gVGh1cywgaW4gb3Jk ZXIgdG8gaW5zdXJlIGF1dGhlbnRpY2l0eSBvZiBFTlVNIHVzZXIncyBpbmZvcm1hdGlvbiwgd2Ug Y29uc2lkZXIgdGhlIGZvbGxvd2luZyBxdWVzdGlvbiAxIGFuZCAyLiBBbmQgcXVlc3Rpb24gMyBh bmQgNCBpcyBhYm91dCBudW1iZXIgdHJhbnNmZXIgYW5kIHJldmFsaWRhdGlvbi4NCj4+IA0KPj4g MS4gV2UgdGhpbmsgdGhlIHZhbGlkYXRpb24gaW5jbHVkZXMgdHdvIGFzcGVjdHMsIG9uZSBpcyB0 aGUgcmVnaXN0cmFudCdzIGF1dGhlbnRpY2l0eSwgdGhlIG90aGVyIGlzIHRoYXQgRU5VTSByZWdp c3RyYW50IGlzIHRoZSBzYW1lIHdpdGggRS4xNjQgaG9sZGVyLg0KPiANCj4gZXhhY3RseS4gU2Vl IHNlY3Rpb24gMiBvZiB0aGUgZHJhZnQuDQo+IA0KPj4gSW4gQXVzdHJpYW4gbW9kZWwsICJFTlVN IGRvbWFpbiBleGlzdGVuY2UgaXMgdGhlIGJhc2lzIGZvciB0aGUgbnVtYmVyIGFsbG9jYXRpb24i LCBFTlVNIGRvbWFpbiByZWdpc3RyYXRpb24gaXMgb24gaW50ZXJuZXQsIHRodXMsIGhvdyB0byBp bnN1cmUgdGhlIHVzZXIncyBhdXRoZW50aWNpdHk/IE9yIHlvdSBjb25zaWRlciBub2JvZHkgd2ls bCBzdWJtaXQgdGhlIG1lbmRhY2lvdXMgaW5mb3JtYXRpb24/DQo+IA0KPiBUaGUgIm51bWJlciBm b2xsb3dzIEVOVU0iIG1vZGVsIGlzIG9ubHkgYXBwbGllZCB0byBvbmUgc3BlY2lhbCBudW1iZXIg cmFuZ2UNCj4gKCs0MyA3ODApLiBJbiBhbGwgb3RoZXIgbnVtYmVyIHJhbmdlcywgdGhlIEVOVU0g ZG9tYWluIGZvbGxvd3MgYW4gZXhpc3RpbmcNCj4gbnVtYmVyLg0KPiANCj4gRm9yIHRoZSBzcGVj aWFsIG51bWJlciByYW5nZSBtZW50aW9uZWQgYWJvdmUsIG51bWJlcnMgbWF5IGJlIGFsbG9jYXRl ZA0KPiBhbm9ueW1vdXNseS4gRm9yIHZhbGlkYXRpb24gcHVycG9zZXMsIGkgZG9uJ3QgbmVlZCB0 byBrbm93IF93aG9fIHRoZSBvd25lcg0KPiBvZiB0aGUgbnVtYmVyIGlzIGFzIGxvbmcgYXMgbnVt YmVyIGhvbGRlciBhbmQgRU5VTSBkb21haW4gbmFtZSBob2xkZXIgYXJlDQo+IHRoZSBzYW1lIChh bm9ueW1vdXMgbnVtYmVycyBhcmUgcG9zc2libGUgaW4gdGhhdCByYW5nZSkuIElmIHNvbWVvbmUg ZW50ZXJzDQo+IHdyb25nIGRhdGEgZm9yIHN1Y2ggYSBudW1iZXIsIGhlIHdpbGwgaGF2ZSBhIGhh cmQgdGltZSByZWNvdmVyaW5nIGl0IG9uY2UgaGUNCj4gZWcuIGxvc3QgaGlzIHBhc3N3b3JkIG9y IHdhbnRzIHRvIGNoYW5nZSBJU1AuDQo+IA0KPiBUaGVyZSBtaWdodCBiZSBvdGhlciB2YWxpZGF0 aW9uIG1ldGhvZHMgd2hlcmUgeW91IGRvbid0IG5lZWQgdG8ga25vdyBfd2hvXw0KPiB0aGUgbnVt YmVyIGhvbGRlciBpcywgYXMgbG9uZyBhcyB5b3UgY2FuIGVuc3VyZSB0aGUgcmVxdWlyZW1lbnRz LCBlZy4gYQ0KPiBTTVMtbG9vcCB0byBhIG1vYmlsZSBwaG9uZSBtYXkgYmUgZmluZSBmb3IgRU5V TSB2YWxpZGF0aW9uLCBidXQgZG9lcyBub3QNCj4gdHJhbnNwb3J0IGFueSBudW1iZXIgaG9sZGVy IGluZm9ybWF0aW9uLg0KPiANCj4+IDIuIFRoZSB0aGlyZCBWRSB3ZSBtZW50aW9uZWQgaXMgdGhl IG5ldXRyYWwgdmFsaWRhdGlvbiBlbnRpdHksIHdoaWNoIGhhcyByZXNwb25zaWJpbGl0eSBmb3Ig dmFsaWRhdGlvbiBvZiB0aGUgRU5VTSByZWdpc3RyYXRpb24gYW5kIGFwcGxpY2F0aW9uLg0KPj4g VGhlIGRyYWZ0IHNob3dzIE5BRS9DU1AgY2FuIGJlIHRydXN0ZWQuIEJ1dCBhY3R1YWxseSwgVm9J UCBzZXJ2aWNlIHByb3ZpZGVycyBpbiBtYW55IGNvdW50cmllcyBtYXkgYmUgbGFjayBvZiBlbm91 Z2ggc3VwZXJ2aXNhbCwgYW5kIGlmIGNlcnRhaW4gVm9JUCBwcm92aWRlciBnb2VzIGJhbmtydXB0 LCB0cmFuc2ZlcmluZyBvZiB1c2VycycgaW5mb3JtYXRpb24gYmVsb25nZWQgdG8gdGhlIFZvSVAg cHJvdmlkZXIgd2lsbCBiZSBhIHByb2JsZW0sIHNvIHdlIHByZWZlciB0byB0cnVzdCB0aGUgdGhp cmQvbmV1dHJhbCBWRSB3aG8gaG9sZHMgdGhlIHRvdGFsIHVzZXJzJ3MgaW5mb3JtYXRpb24uDQo+ IA0KPiBJdCdzIHRoZSBzYW1lIGlzc3VlIHdoZW4gYSBjbGFzc2ljYWwgdGVsY28gZ29lcyBiYW5r cnVwdC4gWWVzLCB3ZSBoYWQgdGhhdA0KPiBhbHJlYWR5IGluIEF1c3RyaWEsIHdoZXJlIGFsbCBv ZiBhIHN1ZGRlbiBzZXZlcmFsIHRob3VzYW5kcyBvZiBjdXN0b21lcnMNCj4gd2VyZSBkaXNjb25u ZWN0ZWQgYmVjYXVzZSBvZiBzdWNoIGEgY2FzZS4gU28sIHRoaXMgaXMgbm90IHNwZWNpYWwgdG8g RU5VTS4NCj4gDQo+PiAzLiBZb3UgZGlkIG5vdCBtZW50aW9uIEVOVU0gbnVtYmVyIHRyYW5zZmVy LCBhbmQgaXMgaXQgcG9zc2libGUgdG8gdHJhbnNmZXJlZCBhbiBFTlVNIG51bWJlciBmcm9tIG9u ZSBwZXJzb24gdG8gYW5vdGhlciBhcyBnZW5hcmFsIGRvbWFpbiB0cmFuc2Zlcj8gDQo+PiBJZiBF TlVNIG51bWJlciBwZXJtaXRzIHRvIGJlIHRyYW5zZmVyZWQsIHRoZW4gd2UgdGhpbmsgdGhlIE51 bWJlciBBc3NpZ25tZW50IEVudGl0eSBvZiBhIG5hdGlvbmFsIHJhbmdlIGlzIHByZWZlcmVkLCBz byB0aGF0IHVzZXJzIGNhbiBhcHBseSBFTlVNIG51bWJlciBmcm9tIGFueSBudW1iZXIgYXNzaWdu bWVudCBhZ2VudHMuIEFsc28sIGlmIGNlcnRhaW4gRU5VTSBudW1iZXIgaXMgdHJhbnNmZXJlZCwg TkFFIG5lZWRzIHRvIHRlbGwgUmVnaXN0cnkvUmVnaXN0cmFyIHRoZSB0cmFuc2ZlcmVkIGluZm9y bWF0aW9uLg0KPiANCj4gT3VyIGxvY2FsIGFzc3VwbXRpb24gaXMgdGhhdCB0aGUgbmV3IFJlZ2lz dHJhciBuZWVkcyB0byByZS1wZXJmb3JtIGluaXRpYWwNCj4gdmFsaWRhdGlvbiwgYW5kIHRoZW4g Y2FuIGlzc3VlIGEgdHJhbnNmZXIgcmVxdWVzdC4NCj4gDQo+IEFkZGl0aW9uYWxseSwgdGhlcmUg YXJlIG5vIHRpZXMgYmV0d2VlbiBhIHNwZWNpYWwgTkFFIGFuZCBhIHNwZWNpYWwgVkUgb3INCj4g cmVnaXN0cmFyLiBZb3UgY2FuIHJlZ2lzdGVyIGFueSBBdXN0cmlhbiBudW1iZXIgYXQgYW55IHJl Z2lzdHJhciAoZ2l2ZW4gaGUNCj4gYWNjZXB0cyB5b3UgYXMgYSBjdXN0b21lciwgb2YgY29sdXJz ZSA7KS4NCj4gDQo+PiA0LiBXZSB3YW50IHRvIGNvbmZpcm0gd2hldGhlciB0aGUgcmV2YWxpZGF0 aW9uIGluIHRoZSBkcmFmdCBkZW5vdGVzIHRoYXQgRU5VTSB2YWxpZGF0aW9uIGl0c2VsZiBoYXMg ZXhwaXJhdGlvbiBkYXRlIGFzIGFsbCBraW5kcyBvZiB2YWxpZGF0aW9uLCBzbyBpZiBFTlVNIGRl bGVnYXRpb24gaXMgYmV5b25kIGV4cGlyYXRpb24gZGF0ZSwgcmV2YWxpZGF0aW9uIGlzIG5lZWRl ZC4NCj4+IEZ1cnRoZXJtb3JlLCBpZiBFTlVNIG51bWJlciBjYW4gYmUgY2FuY2VsbGVkIG9yIHRy YW5zZmVyZWQsIG1heWJlIEVOVU0gcmV2YWxpZGF0aW9uIGlzIG5lZWRlZC4NCj4gDQo+IFRoZSBh Y3R1YWwgZXhwaXJ5IG9mIHZhbGlkYXRpb24gaW5mb3JtYXRpb24gaXMgbG9jYWwgcG9saWN5LiBl Zy4gZm9yDQo+ICJub3JtYWwiIG51bWJlciByYW5nZXMgaW4gQXVzdHJpYSwgdGhlIG1heC4gdmFs aWRpdHkgaXMgNiBtb250aHMsIGZvciB0aG9zZQ0KPiAic3BlY2lhbCIgbnVtYmVyIHJhbmdlIGxp c3RlZCBhYm92ZSB0aGUgdmFsaWRhdGlvbiBkb2VzIG5vdCBleHBpcmUgYXQgYWxsLg0KPiANCj4g T3VyIGdlbmVyYWwgYXNzdW1wdGlvbiBpbiB0aGUgZHJhZnQgKHNlZSBzZWN0aW9uIDQuMSkgaXMg dGhhdCBFTlVNDQo+IGRlbGVnYXRpb25zIGZvciB3aGljaCBubyB2YWxpZCB2YWxpZGF0aW9uIChz aWMhKSBleGlzdHMgbmVlZCB0byBiZSBzdXNwZW5kZWQNCj4gZnJvbSBETlMgKGhvd2V2ZXIgdGhh dCBtaWdodCBiZSBpbXBsZW1lbnRlZCkuDQo+IA0KPj4gQlRXLCBFLjE2NCBudW1iZXIgbWF5YmUg aGFzIGV4cGlyYXRpb24gdGltZSBpbiBzb21lIGNvdW50cmllcyBzdWNoIGFzIENoaW5hLiBGb3Ig ZXhhbXBsZSwgYSBwZXJzb24gYXBwbHkgb25lIEUuMTY0IG51bWJlcihvZiBjb3Vyc2UgaW5jbHVk aW5nIHRlbGVjb21tdW5pY2F0aW9uIHNlcnZpY2UpIGZyb20gQ1NQLCBhbmQgdGhlIGRlZmF1bHQg ZXhwaXJhdGlvbiB0aW1lIGlzIHVzdWFsbHkgdGhyZWUgbW9udGhzLCB0aGVuIGlmIHRoZSBwZXJz b24gZG9ubm90IHBheSBhZ2FpbiwgdGhlIHRlbGVjb21tdW5pY2F0aW9uIHNlcnZpY2Ugd2lsbCBi ZSBzdG9wcGVkIGFuZCB0aGUgbnVtYmVyIHdpbGwgYmUgdGFrZW4gYmFjayBhbmQgcmVhc3NpZ25l ZC4NCj4gDQo+IHllcywgaW4gdGhhdCBjYXNlIGl0IG1pZ2h0IGJlIGRlc2lyZWFibGUgdG8gdGll IHRoZSB2YWxpZGF0aW9uIGV4cGlyeSB0byB0aGUNCj4gZXhwaXJhdGlvbiBvZiB0aGUgbnVtYmVy IGl0c2VsZi4NCj4gDQo+IGNoZWVycw0KPiANCj4gQWxleA0KPg== --===============0635397564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0635397564==-- From enum-bounces@ietf.org Thu Aug 24 05:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBpl-0003Ix-OS; Thu, 24 Aug 2006 05:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBpk-0003Hp-0E; Thu, 24 Aug 2006 05:49:08 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGBpi-0007cX-IB; Thu, 24 Aug 2006 05:49:07 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 24 Aug 2006 11:48:51 +0200 id 0007C0AC.44ED7603.000041EE Message-ID: <44ED75BC.2020102@enum.at> Date: Thu, 24 Aug 2006 11:47:40 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: chenhui Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> <356334594.21857@cnnic.cn> <356408619.13809@cnnic.cn> In-Reply-To: <356408619.13809@cnnic.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: enum@ietf.org, =?GB2312?B?J831ILflJw==?= , iesg@ietf.org, =?GB2312?B?s8LBwQ==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org chenhui wrote: > The reason we mention neutral VE is that we care so much about authenticity of ENUM users. That's very much a local policy decision, how much and what kind of information the different roles need to store. We tried to stay away from mandating the actual amount of information as much as possible. > If NAEs can be trusted in the draft, we wonder whether _NAEs_ have the two functions: Our assumption is that the NAEs have the authoritative information about numbers they did assign. The actual amount of that information might range from the pure "is assigned / is unassigned" (eg. in the case of anonymous prepaid mobile numbers) to a fully verified set of personal data (eg. for fixed lines which include an entry in the white pages directory). The question here is whether they cooperate in providing that data when the entity serving as NAE does not also provide VE services. Our experience is that it's very unlikely they cooperate unless they are forced to. > 1. NAEs have responsibility for authenticity of the ENUM number holders. (except the case of "+43780" number ranges) It's important to distinguish between "number allocation" and "ENUM registration". Yes, the NAEs _should_ have the authoritative information about the number holder (if available, see above), but they might not even be aware that the number holder aquired the ENUM domain for that number. > 2. Assignee can be assigned _any_ ENUM number from any _NAE_ in order to make ENUM number transfer more conveniently. (You have explained "You can register any Austrian number at any _registrar_" in the last letter. But if ENUM number is not +43780 number, maybe the user gets number before domain). Again, it's important to seperate the actual "E.164 number" from the "ENUM domain". Both may be handled by completely different entities, but the potential Registrant somehow needs to prove to the VE that he's also the Assignee of that number. In that actual process, information that the NAEs collected might definitely be helpful - some of that information is already publicly available (eg. white pages, other directories), so the VE _may_ make use of that information. It's very similar to the number portability process, where you also have to prove that you own the number to a different company than the one that originally assigned you the number. That's also the reason why a successful ENUM validation is very often a byproduct of a successful number porting process to a ITSP. cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 24 07:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDHT-0004Ef-Mp; Thu, 24 Aug 2006 07:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDHS-0004EZ-VQ for enum@ietf.org; Thu, 24 Aug 2006 07:21:50 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDHQ-00047L-Lr for enum@ietf.org; Thu, 24 Aug 2006 07:21:50 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Thu, 24 Aug 2006 13:21:31 +0200 id 0007C0A5.44ED8BBB.000051CE Message-ID: <44ED8B74.9080104@enum.at> Date: Thu, 24 Aug 2006 13:20:20 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: richard@shockey.us Subject: Re: [Enum] ENUM WG Last Call on document draft-ietf-enum-cnam-03.txt References: <001301c6c638$896f5180$54201f0a@cis.neustar.com> In-Reply-To: <001301c6c638$896f5180$54201f0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, 'Cullen Jennings' , =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'Peterson, Jon'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > > Title : IANA Registration for an Enumservice Calling > Name Delivery (CNAM) Information and IANA > Registration for Media type 'application/cnam' > again, a bunch of issues with this draft: - ABNF normative reference still missing (since -01!). - afaik the RFC editors don't like references in the Abstract (which, BTW, points to a non-existant reference - [19] should be [18]) - please remove it from there, and add it at the end of the first sentence on page 3. - E.164 reference still outdated - typo on page 4: "unavaiable=u" is missing the 'l' [and probably still more which i didn't catch because this is my 3rd review] cheers Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 24 22:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGRtX-0004eK-5a; Thu, 24 Aug 2006 22:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGRtV-0004e7-0g for enum@ietf.org; Thu, 24 Aug 2006 22:58:05 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGRtQ-0003lK-6I for enum@ietf.org; Thu, 24 Aug 2006 22:58:04 -0400 Received: (eyou send program); Fri, 25 Aug 2006 10:57:41 +0800 Message-ID: <356474661.19975@cnnic.cn> X-EYOUMAIL-SMTPAUTH: chenhui@cnnic.cn Received: from unknown (HELO cnnicchenh) (159.226.6.99) by 159.226.7.146 with SMTP; Fri, 25 Aug 2006 10:57:41 +0800 Message-ID: <006501c6c7f2$415d1470$6306e29f@cnnicchenh> From: "chenhui" To: "Alexander Mayrhofer" References: <356242810.08427@cnnic.cn> <356259169.14342@cnnic.cn> <356324682.20236@cnnic.cn> <356334594.21857@cnnic.cn> <356408619.13809@cnnic.cn> <356412932.16851@cnnic.cn> Subject: Re: [Enum] Last Call: 'ENUM Validation Architecture' to Informational RFC (draft-ietf-enum-validation-arch) Date: Fri, 25 Aug 2006 10:57:51 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.0 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: enum@ietf.org, =?gb2312?B?J831ILflJw==?= , iesg@ietf.org, =?gb2312?B?s8LBwQ==?= X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892357975==" Errors-To: enum-bounces@ietf.org --===============0892357975== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGV4LA0KDQpZZXMsIEVOVU0gbnVtYmVyLCBhcyBpZGVudGl0eSBvZiB0aGUgdXNlciwg aGFzIGluaGVyZW50IGZlYXR1cmUgb2YgTlAsIHdoaWNoIGlzIGltcG9ydGFudCBmb3IgdGhlIHZh cmlvdXMgc2VydmljZXMgaWRlbnRpZmllZCBieSBFTlVNIG51bWJlcnMuDQoNCldlIGhvcGUgdGhp cyBSRkMgYWJvdXQgZnVsbC1zY2FsZSBudW1iZXIgYXNzaWdubWVudCBhbmQgdmFsaWRhdGlvbiBj b21lcyBvbiwgYW5kIGhvcGUgaXQgd2lsbCBwbGF5IGFuIHZpdGFsIHJvbGUgaW4gdGhlIGFjdHVh bCBFTlVNIHByb3Zpc2lvbiBhbmQgaW1wbGVtZW50YXRpb24uDQoNCkJlc3QgV2lzaGVzIQ0KWW91 cnMgU2luY2VyZWx5LA0KQ2hlbmh1aSwgV2FuZ2ZlbmcsIENoZW5saWFuZw0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXhhbmRlciBNYXlyaG9mZXIiIDxhbGV4YW5k ZXIubWF5cmhvZmVyQGVudW0uYXQ+DQpUbzogImNoZW5odWkiIDxjaGVuaHVpQGNubmljLmNuPg0K Q2M6IDxlbnVtQGlldGYub3JnPjsgIrPCwcEiIDxjaGVubGlhbmdAY25uaWMuY24+OyA8aWVzZ0Bp ZXRmLm9yZz47ICInzfUgt+UnIiA8ZmVuZ3dAY25uaWMuY24+DQpTZW50OiBUaHVyc2RheSwgQXVn dXN0IDI0LCAyMDA2IDU6NDcgUE0NClN1YmplY3Q6IFJlOiBbRW51bV0gTGFzdCBDYWxsOiAnRU5V TSBWYWxpZGF0aW9uIEFyY2hpdGVjdHVyZScgdG8gSW5mb3JtYXRpb25hbCBSRkMgKGRyYWZ0LWll dGYtZW51bS12YWxpZGF0aW9uLWFyY2gpDQoNCg0KPiBjaGVuaHVpIHdyb3RlOg0KPj4gVGhlIHJl YXNvbiB3ZSBtZW50aW9uIG5ldXRyYWwgVkUgaXMgdGhhdCB3ZSBjYXJlIHNvIG11Y2ggYWJvdXQg YXV0aGVudGljaXR5IG9mIEVOVU0gdXNlcnMuIA0KPiANCj4gVGhhdCdzIHZlcnkgbXVjaCBhIGxv Y2FsIHBvbGljeSBkZWNpc2lvbiwgaG93IG11Y2ggYW5kIHdoYXQga2luZCBvZg0KPiBpbmZvcm1h dGlvbiB0aGUgZGlmZmVyZW50IHJvbGVzIG5lZWQgdG8gc3RvcmUuIFdlIHRyaWVkIHRvIHN0YXkg YXdheSBmcm9tDQo+IG1hbmRhdGluZyB0aGUgYWN0dWFsIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBh cyBtdWNoIGFzIHBvc3NpYmxlLg0KPiANCj4+IElmIE5BRXMgY2FuIGJlIHRydXN0ZWQgaW4gdGhl IGRyYWZ0LCB3ZSB3b25kZXIgd2hldGhlciBfTkFFc18gaGF2ZSB0aGUgdHdvIGZ1bmN0aW9uczoN Cj4gDQo+IE91ciBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIE5BRXMgaGF2ZSB0aGUgYXV0aG9yaXRh dGl2ZSBpbmZvcm1hdGlvbiBhYm91dA0KPiBudW1iZXJzIHRoZXkgZGlkIGFzc2lnbi4gVGhlIGFj dHVhbCBhbW91bnQgb2YgdGhhdCBpbmZvcm1hdGlvbiBtaWdodCByYW5nZQ0KPiBmcm9tIHRoZSBw dXJlICJpcyBhc3NpZ25lZCAvIGlzIHVuYXNzaWduZWQiIChlZy4gaW4gdGhlIGNhc2Ugb2YgYW5v bnltb3VzDQo+IHByZXBhaWQgbW9iaWxlIG51bWJlcnMpIHRvIGEgZnVsbHkgdmVyaWZpZWQgc2V0 IG9mIHBlcnNvbmFsIGRhdGEgKGVnLiBmb3INCj4gZml4ZWQgbGluZXMgd2hpY2ggaW5jbHVkZSBh biBlbnRyeSBpbiB0aGUgd2hpdGUgcGFnZXMgZGlyZWN0b3J5KS4NCj4gDQo+IFRoZSBxdWVzdGlv biBoZXJlIGlzIHdoZXRoZXIgdGhleSBjb29wZXJhdGUgaW4gcHJvdmlkaW5nIHRoYXQgZGF0YSB3 aGVuIHRoZQ0KPiBlbnRpdHkgc2VydmluZyBhcyBOQUUgZG9lcyBub3QgYWxzbyBwcm92aWRlIFZF IHNlcnZpY2VzLiBPdXIgZXhwZXJpZW5jZSBpcw0KPiB0aGF0IGl0J3MgdmVyeSB1bmxpa2VseSB0 aGV5IGNvb3BlcmF0ZSB1bmxlc3MgdGhleSBhcmUgZm9yY2VkIHRvLg0KPiANCj4+IDEuIE5BRXMg aGF2ZSByZXNwb25zaWJpbGl0eSBmb3IgYXV0aGVudGljaXR5IG9mIHRoZSBFTlVNIG51bWJlciBo b2xkZXJzLiAoZXhjZXB0IHRoZSBjYXNlIG9mICIrNDM3ODAiIG51bWJlciByYW5nZXMpDQo+IA0K PiBJdCdzIGltcG9ydGFudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuICJudW1iZXIgYWxsb2NhdGlv biIgYW5kICJFTlVNDQo+IHJlZ2lzdHJhdGlvbiIuIFllcywgdGhlIE5BRXMgX3Nob3VsZF8gaGF2 ZSB0aGUgYXV0aG9yaXRhdGl2ZSBpbmZvcm1hdGlvbg0KPiBhYm91dCB0aGUgbnVtYmVyIGhvbGRl ciAoaWYgYXZhaWxhYmxlLCBzZWUgYWJvdmUpLCBidXQgdGhleSBtaWdodCBub3QgZXZlbg0KPiBi ZSBhd2FyZSB0aGF0IHRoZSBudW1iZXIgaG9sZGVyIGFxdWlyZWQgdGhlIEVOVU0gZG9tYWluIGZv ciB0aGF0IG51bWJlci4NCj4gDQo+PiAyLiBBc3NpZ25lZSBjYW4gYmUgYXNzaWduZWQgX2FueV8g RU5VTSBudW1iZXIgZnJvbSBhbnkgX05BRV8gaW4gb3JkZXIgdG8gbWFrZSBFTlVNIG51bWJlciB0 cmFuc2ZlciBtb3JlIGNvbnZlbmllbnRseS4gKFlvdSBoYXZlIGV4cGxhaW5lZCAiWW91IGNhbiBy ZWdpc3RlciBhbnkgQXVzdHJpYW4gbnVtYmVyIGF0IGFueSBfcmVnaXN0cmFyXyIgaW4gdGhlIGxh c3QgbGV0dGVyLiBCdXQgaWYgRU5VTSBudW1iZXIgaXMgbm90ICs0Mzc4MCBudW1iZXIsIG1heWJl IHRoZSB1c2VyIGdldHMgbnVtYmVyIGJlZm9yZSBkb21haW4pLg0KPiANCj4gQWdhaW4sIGl0J3Mg aW1wb3J0YW50IHRvIHNlcGVyYXRlIHRoZSBhY3R1YWwgIkUuMTY0IG51bWJlciIgZnJvbSB0aGUg IkVOVU0NCj4gZG9tYWluIi4gQm90aCBtYXkgYmUgaGFuZGxlZCBieSBjb21wbGV0ZWx5IGRpZmZl cmVudCBlbnRpdGllcywgYnV0IHRoZQ0KPiBwb3RlbnRpYWwgUmVnaXN0cmFudCBzb21laG93IG5l ZWRzIHRvIHByb3ZlIHRvIHRoZSBWRSB0aGF0IGhlJ3MNCj4gYWxzbyB0aGUgQXNzaWduZWUgb2Yg dGhhdCBudW1iZXIuDQo+IA0KPiBJbiB0aGF0IGFjdHVhbCBwcm9jZXNzLCBpbmZvcm1hdGlvbiB0 aGF0IHRoZSBOQUVzIGNvbGxlY3RlZCBtaWdodCBkZWZpbml0ZWx5DQo+IGJlIGhlbHBmdWwgLSBz b21lIG9mIHRoYXQgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBwdWJsaWNseSBhdmFpbGFibGUgKGVn Lg0KPiB3aGl0ZSBwYWdlcywgb3RoZXIgZGlyZWN0b3JpZXMpLCBzbyB0aGUgVkUgX21heV8gbWFr ZSB1c2Ugb2YgdGhhdCBpbmZvcm1hdGlvbi4NCj4gDQo+IEl0J3MgdmVyeSBzaW1pbGFyIHRvIHRo ZSBudW1iZXIgcG9ydGFiaWxpdHkgcHJvY2Vzcywgd2hlcmUgeW91IGFsc28gaGF2ZSB0bw0KPiBw cm92ZSB0aGF0IHlvdSBvd24gdGhlIG51bWJlciB0byBhIGRpZmZlcmVudCBjb21wYW55IHRoYW4g dGhlIG9uZSB0aGF0DQo+IG9yaWdpbmFsbHkgYXNzaWduZWQgeW91IHRoZSBudW1iZXIuIFRoYXQn cyBhbHNvIHRoZSByZWFzb24gd2h5IGEgc3VjY2Vzc2Z1bA0KPiBFTlVNIHZhbGlkYXRpb24gaXMg dmVyeSBvZnRlbiBhIGJ5cHJvZHVjdCBvZiBhIHN1Y2Nlc3NmdWwgbnVtYmVyIHBvcnRpbmcNCj4g cHJvY2VzcyB0byBhIElUU1AuDQo+IA0KPiBjaGVlcnMNCj4gDQo+IEFsZXg= --===============0892357975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0892357975==-- From enum-bounces@ietf.org Mon Aug 28 20:49:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrm8-0003GO-DO; Mon, 28 Aug 2006 20:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrm7-0003GH-CR for enum@ietf.org; Mon, 28 Aug 2006 20:48:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqlg-0002Uc-NK for enum@ietf.org; Mon, 28 Aug 2006 19:43:49 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHqck-0005sw-5r for enum@ietf.org; Mon, 28 Aug 2006 19:34:34 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1934653wxc for ; Mon, 28 Aug 2006 16:34:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kfTyMjjUVi1rY5CK/vwl0SDZYOVWFVc1U4pY4NEIHlqi3YYFo0lvb6GB8XyheflHHthFu5MuL/vstLdLcy8sT3Rl7ea+YaWcD2L/HoCzYm20aGQZM8N30YwjGlw/wxUyJIjrEt6+DTm6IicPykZ3hsKdzHWMO0EBSrgEXuc6Kqg= Received: by 10.90.25.9 with SMTP id 9mr1336019agy; Mon, 28 Aug 2006 16:34:33 -0700 (PDT) Received: by 10.90.120.7 with HTTP; Mon, 28 Aug 2006 16:34:33 -0700 (PDT) Message-ID: Date: Tue, 29 Aug 2006 00:34:33 +0100 From: "Lee Dryburgh" To: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.3 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Enum] Is ENUM anti-competitive? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, There are a stack of services/applications which I would like to investigate which require (amongst other things) a single identifier. Lately, due to the seemingly slow pace of progress in the realms of digital identity, I thought of using ENUM to provide the required single identifier service. But from my reading around ENUM (this mailing list and associated documents) I have a number of concerns with the primary one being the fear that ENUM is anti-competitive. It would appear to give telcos (who pay my wages) ongoing control over a numbering business and as such gives them power to hold a consumer (who may wish to break away for service) hostage. As a test question, how easy for it would it be for Skype to become a Tier-2 player (so that they could control my E.164 identity)? In addition, from my understanding of the situation the identity space (E.164) is unlikely to be unbundled from the telephony service, thus an ENUM contact identifier could only be purchased as an add on to existing voice/rental service and that service providers are unlikely to sell numbers (and corresponding management) separately from a voice service? Hopefully my concerns are not true? Thanks in advance _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 28 22:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHtXZ-0004ds-8O; Mon, 28 Aug 2006 22:41:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHtXX-0004dn-Rn for enum@ietf.org; Mon, 28 Aug 2006 22:41:23 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHtXS-00087t-9u for enum@ietf.org; Mon, 28 Aug 2006 22:41:23 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7T2emri024736; Mon, 28 Aug 2006 19:40:54 -0700 From: "Richard Shockey" To: "'Lee Dryburgh'" , Subject: RE: [Enum] Is ENUM anti-competitive? Date: Mon, 28 Aug 2006 22:40:25 -0400 Message-ID: <00be01c6cb14$8064ec40$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbLBOF8xEMF9pTSRB6ZxP9b3tGQrwADHL8g In-Reply-To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Humm .. first of all as ENUM co-chair thank you for your thoughtful note you raise may interesting issues that many of us are continuing to struggle with. > -----Original Message----- > From: Lee Dryburgh [mailto:dryburghl@gmail.com] > Sent: Monday, August 28, 2006 7:35 PM > To: enum@ietf.org > Subject: [Enum] Is ENUM anti-competitive? > > Hi Folks, > > There are a stack of services/applications which I would like to > investigate which require (amongst other things) a single identifier. > Lately, due to the seemingly slow pace of progress in the realms of > digital identity, I thought of using ENUM to provide the required > single identifier service. Well Digital Identity is a large and complex subject that is being dealt with in multiple fora for a including the IETF SIP working groups. I would suggest reading. Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. SIP and the Security Assertion Markup Language http://www.softarmor.com/wgdb/docs/draft-tschofenig-sip-saml-04.txt SIP Identity http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt SIP Identity Coexistance http://tools.ietf.org/wg/sip/draft-rosenberg-sip-identity-coexistence-00.txt Liberty Alliance: The Liberty Alliance is comprised of over 60 member companies representing a wide variety of industries and over a billion customers, with operations all over the globe. Each of the member companies either owns and operates large communities of interest or is the developer of core technology that can enable a federation of online communities. http://www.projectliberty.org/ SAML (Security Assertion Markup Language): An XML standard for exchanging authentication and authorization data between security systems. See http://www.oasis-open.org/committees/security/#documents. What applications are you trying to enable? > > But from my reading around ENUM (this mailing list and associated > documents) I have a number of concerns with the primary one being the > fear that ENUM is anti-competitive. It would appear to give telcos > (who pay my wages) ongoing control over a numbering business and as > such gives them power to hold a consumer (who may wish to break away > for service) hostage. Not necessarily true. The current national implementations of RFC 3761 within e164.arpa give to the consumer ...aka the number holder vs the carrier of record the right to write the zone files. This has been the thrust of regulatory implementations up to this date. However many carriers have understood that they have internal as well as external interconnection issues that could use a parallel implementation of 3761 specifically targeted towards the issuer of the E.164 number vs the consumer. Hence the work here on what is generally referred to as Infrastructure ENUM. Title : Infrastrucure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum- reqs-03.txt > > As a test question, how easy for it would it be for Skype to become a > Tier-2 player (so that they could control my E.164 identity)? The management of E.164 numbers are a matter of national control totally outside the scope of the ENUM WG. This is a national sovereign issue. And the management of the zones of e164.arpa has generally been interpreted as being within the national sovereign scope of the nation state. See your local telecom regulator for further information :-) > > In addition, from my understanding of the situation the identity space > (E.164) is unlikely to be unbundled from the telephony service, thus > an ENUM contact identifier could only be purchased as an add on to > existing voice/rental service and that service providers are unlikely > to sell numbers (and corresponding management) separately from a voice > service? Maybe maybe not, again this is an national issue .. you are correct in identifying E.164 as a globally unique and well managed namespace that could be used as a address for the location of a identity object ( hopefully SAML) that could contain multiple attributes etc. But that has yet to be seen. > > Hopefully my concerns are not true? You are asking the right questions.. the answers are yet to be seen. > > Thanks in advance Not at all thanks for asking. I'm sure others on this list will chime in. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 29 03:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHy9u-0000JS-9e; Tue, 29 Aug 2006 03:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHy9s-0000IX-Gt for enum@ietf.org; Tue, 29 Aug 2006 03:37:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHy9o-00035h-Mq for enum@ietf.org; Tue, 29 Aug 2006 03:37:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Enum] Is ENUM anti-competitive? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Aug 2006 09:36:16 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C50F6@oefeg-s04.oefeg.loc> In-Reply-To: <00be01c6cb14$8064ec40$23f0a544@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Is ENUM anti-competitive? Thread-Index: AcbLBOF8xEMF9pTSRB6ZxP9b3tGQrwADHL8gAApxKcA= From: "Stastny Richard" To: , "Lee Dryburgh" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > Not necessarily true. The current national implementations of RFC 3761 > within e164.arpa give to the consumer ...aka the number holder vs the > carrier of record the right to write the zone files. > > In addition, from my understanding of the situation the identity space > > (E.164) is unlikely to be unbundled from the telephony service, thus > > an ENUM contact identifier could only be purchased as an add on to > > existing voice/rental service and that service providers are unlikely > > to sell numbers (and corresponding management) separately from a voice > > service? >=20 > Maybe maybe not, again this is an national issue .. you are correct in > identifying E.164 as a globally unique and well managed namespace that > could > be used as a address for the location of a identity object (hopefully > SAML) > that could contain multiple attributes etc. But that has yet to be seen. >=20 > > This is basically correct: E.164 numbers ARE the identifiers for the telephony service. As Richard Shockey points out, in User ENUM (e164.arpa - not in Infrastructure ENUM)=20 the consumer has the right to write the zone file.=20 BUT only for an existing phone number. So it is - as you recognize - an add on to an existing phone service. There is one exception: nationally a number range may be defined (as in Austria +43780), where the phone service comes only in existence with the ENUM entry. But also here it is mandatory that the number is treated as a phone service on the PSTB=20 and routed at least via one gateway to the Internet) Nevertheless, as you may link an ENUM entry to any service on the Internet (e.g. mailto), you may also enter a pointer to a certificate. In ETSI TS 102 152 we have proposed an enumservice "key" pointing to a public key certificate. This could e.g. be used if you send a signed e-mail to somebody. Maybe this or a similar enumservice should be reconsidered again. regards Richard Stastny > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, August 29, 2006 4:40 AM > To: 'Lee Dryburgh'; enum@ietf.org > Subject: RE: [Enum] Is ENUM anti-competitive? >=20 >=20 > Humm .. first of all as ENUM co-chair thank you for your thoughtful note > you > raise may interesting issues that many of us are continuing to struggle > with. >=20 > > -----Original Message----- > > From: Lee Dryburgh [mailto:dryburghl@gmail.com] > > Sent: Monday, August 28, 2006 7:35 PM > > To: enum@ietf.org > > Subject: [Enum] Is ENUM anti-competitive? > > > > Hi Folks, > > > > There are a stack of services/applications which I would like to > > investigate which require (amongst other things) a single identifier. > > Lately, due to the seemingly slow pace of progress in the realms of > > digital identity, I thought of using ENUM to provide the required > > single identifier service. >=20 >=20 > Well Digital Identity is a large and complex subject that is being dealt > with in multiple fora for a including the IETF SIP working groups. I would > suggest reading. >=20 > Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the > Session Initiation Protocol (SIP) for Asserted Identity within Trusted > Networks", RFC 3325, November 2002. >=20 > SIP and the Security Assertion Markup Language > http://www.softarmor.com/wgdb/docs/draft-tschofenig-sip-saml-04.txt >=20 > SIP Identity > http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt >=20 > SIP Identity Coexistance > http://tools.ietf.org/wg/sip/draft-rosenberg-sip-identity-coexistence- > 00.txt >=20 > Liberty Alliance: The Liberty Alliance is comprised of over 60 member > companies representing a wide variety of industries and over a billion > customers, with operations all over the globe. Each of the member > companies > either owns and operates large communities of interest or is the developer > of core technology that can enable a federation of online communities. > http://www.projectliberty.org/ >=20 > SAML (Security Assertion Markup Language): An XML standard for exchanging > authentication and authorization data between security systems. See > http://www.oasis-open.org/committees/security/#documents. >=20 >=20 > What applications are you trying to enable? >=20 >=20 > > > > But from my reading around ENUM (this mailing list and associated > > documents) I have a number of concerns with the primary one being the > > fear that ENUM is anti-competitive. It would appear to give telcos > > (who pay my wages) ongoing control over a numbering business and as > > such gives them power to hold a consumer (who may wish to break away > > for service) hostage. >=20 >=20 > Not necessarily true. The current national implementations of RFC 3761 > within e164.arpa give to the consumer ...aka the number holder vs the > carrier of record the right to write the zone files. >=20 > This has been the thrust of regulatory implementations up to this date. >=20 > However many carriers have understood that they have internal as well as > external interconnection issues that could use a parallel implementation > of > 3761 specifically targeted towards the issuer of the E.164 number vs the > consumer. Hence the work here on what is generally referred to as > Infrastructure ENUM. >=20 > Title : Infrastrucure ENUM Requirements > Author(s) : S. Lind, P. Pfautz > Filename : > draft-ietf-enum-infrastructure-enum-reqs-03.txt > Pages : 7 > Date : 2006-8-8 >=20 > This document provides requirements for "infrastructure" or "carrier" > ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to > facilitate interconnection of networks for E.164 number addressed > services, > in particular but not restricted to VoIP (Voice over IP.) >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum- > reqs-03.txt >=20 >=20 > > > > As a test question, how easy for it would it be for Skype to become a > > Tier-2 player (so that they could control my E.164 identity)? >=20 >=20 > The management of E.164 numbers are a matter of national control totally > outside the scope of the ENUM WG. This is a national sovereign issue. And > the management of the zones of e164.arpa has generally been interpreted as > being within the national sovereign scope of the nation state. >=20 > See your local telecom regulator for further information :-) >=20 > > > > In addition, from my understanding of the situation the identity space > > (E.164) is unlikely to be unbundled from the telephony service, thus > > an ENUM contact identifier could only be purchased as an add on to > > existing voice/rental service and that service providers are unlikely > > to sell numbers (and corresponding management) separately from a voice > > service? >=20 > Maybe maybe not, again this is an national issue .. you are correct in > identifying E.164 as a globally unique and well managed namespace that > could > be used as a address for the location of a identity object ( hopefully > SAML) > that could contain multiple attributes etc. But that has yet to be seen. >=20 > > > > Hopefully my concerns are not true? >=20 > You are asking the right questions.. the answers are yet to be seen. >=20 > > > > Thanks in advance >=20 >=20 > Not at all thanks for asking. >=20 > I'm sure others on this list will chime in. >=20 > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 29 07:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1rp-0002wC-83; Tue, 29 Aug 2006 07:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1rn-0002vl-JT for enum@ietf.org; Tue, 29 Aug 2006 07:34:51 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI1rl-0001gS-5W for enum@ietf.org; Tue, 29 Aug 2006 07:34:51 -0400 Received: from [195.54.244.2] (account jim HELO [172.16.2.13]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 58642; Tue, 29 Aug 2006 12:34:35 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DF98FCB-17AA-45A0-8B4D-EC9D6F804980@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] Is ENUM anti-competitive? Date: Tue, 29 Aug 2006 12:34:31 +0100 To: Lee Dryburgh X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Aug 29, 2006, at 00:34, Lee Dryburgh wrote: > In addition, from my understanding of the situation the identity space > (E.164) is unlikely to be unbundled from the telephony service, thus > an ENUM contact identifier could only be purchased as an add on to > existing voice/rental service and that service providers are unlikely > to sell numbers (and corresponding management) separately from a voice > service? ENUM is the mapping of E.164 numbers into domain names. How someone gets an E.164 number is their business: not the IETF's. This generally involves a transaction with a company that provides telephone service of some sort. As you noted. :-) However there are companies who provide ENUM registrations and "telephone service" without necessarily offering conventional voice or fax service. For instance, the regulators in a few European countries have allocated number ranges for VoIP service and given out blocks from those ranges to providers. So when a customer gets a number in one of these ranges, it's largely for VoIP and an ENUM registration is a no- brainer. Essentially the E.164 number is an end-point to allow PSTN users to hopefully terminate a conventional call to that customer. Another consideration here is authentication and validation. In many parts of the world, ENUM is an opt-in process and numbers can only be entered if the end-user can prove they have the right to use the number. This will usually require the co-operation of the telco providing service for that number. If they don't, validation either fails or doesn't happen at all. That's anti-competitive (sort of). However end users can always switch telephone service to a telco that will authenticate and validate them for ENUM purposes. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 29 08:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2jD-0004Fu-8S; Tue, 29 Aug 2006 08:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2jC-0004FW-3C for enum@ietf.org; Tue, 29 Aug 2006 08:30:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI2jB-0003F8-WC for enum@ietf.org; Tue, 29 Aug 2006 08:30:02 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI2bV-0008Op-N2 for enum@ietf.org; Tue, 29 Aug 2006 08:22:07 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k7TCMwKj022965; Tue, 29 Aug 2006 08:22:58 -0400 Received: from trutkowski-desk.verisign.com ([10.26.0.6]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 08:21:30 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.4 (Beta) Date: Tue, 29 Aug 2006 08:22:00 -0400 To: "Lee Dryburgh" , enum@ietf.org From: Tony Rutkowski Subject: Re: [Enum] Is ENUM anti-competitive? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Aug 2006 12:21:30.0945 (UTC) FILETIME=[A8B8B310:01C6CB65] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Lee, As others have noted, ENUM is merely an Internet DNS E.164 number resolution technique first developed in the early 90s by Malamud & Rose which still exists at TPC.INT. Arguably, a North American based alternative platform that's somewhat less flexible can be found in the LERG and SS7 message protocols. As you note, E.164 numbers have value because they are relatively stable, generally authenticated, simple numeric global public communication infrastructure identifiers maintained over many decades by government and the telecommunication industry through the ITU. There is a useful history of E.164 with detailed citations from 1945 to 2001 at: draft-rutkowski-enum-basis-00.txt Arguably, the most valuable E.164 identity protocol is E.115-2006 which provides a trusted means to exchange and bill for an array of diverse E.164 related identity information. It's a very nicely done specification that can support both XML and ASN.1 syntaxes. In a world where identity management is becoming more valuable, E.115-2006 may be where the E.164 opportunities exist. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum