From mailnull@www1.ietf.org Mon Mar 3 16:03:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12823 for ; Mon, 3 Mar 2003 16:03:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23LDOs26674 for enum-archive@odin.ietf.org; Mon, 3 Mar 2003 16:13:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23LD2p26661; Mon, 3 Mar 2003 16:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23LBBp26525 for ; Mon, 3 Mar 2003 16:11:11 -0500 Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12714; Mon, 3 Mar 2003 16:00:31 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA10056; Mon, 3 Mar 2003 13:02:15 -0800 Message-Id: <5.2.0.9.2.20030227120623.04d76eb0@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 16:02:01 -0500 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h23LBBp26526 Subject: [Enum] Agenda for ENUM WG IETF 56 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit WEDNESDAY, March 19, 2003 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG OPS v6ops IPv6 Operations WG TSV dccp Datagram Congestion Control Protocol WG TSV enum Telephone Number Mapping WG ************* IETF 56 San Francisco Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: TBD Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … VOLUNTEERS WANTED ! . ################### 1 . 2916bis 04 review... Patrik Faltstrom 15 M The 04 document is in the ID editor queue. ################# 2. Report from the IFAX WG Toyoda-san 10 M Title : IFAX service of ENUM Author(s) : K. Toyoda, D. Crocker Filename : draft-toyoda-faxservice-enum-00.txt Pages : 0 Date : 2003-2-21 This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is 'Facsimile using Internet Mail'. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-toyoda-faxservice-enum-00.txt ################### 3. Presence service registration Jon Peterson 20 Min A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enumservice Registration for Presence Services Author(s) : J. Peterson Filename : draft-peterson-enum-pres-00.txt Pages : 8 Date : 2003-2-26 This document registers an ENUM service for presence services (as described in RFC2778 [3]) pursuant to the guidelines in RFC2916bis [2]. Specifically, this document focuses on provisioning pres URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-enum-pres-00.txt ################### 4 Brandner etal 1 hr. Title : Registration for enumservices of group messages Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enumservice-msg-00.txt Pages : 0 Date : 2003-2-11 This document registers a group of 'enumservices' [5] to be used to indicate that the associated resources are capable of receiving discrete messages. Specifically, the 'enumservices' registered with this document are 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'mailto:' and 'tel:' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-msg-00.txt Titile ; : Registration for enumservices voice and video Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-vovi-00.txt Pages : 0 Date : 2003-2-21 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the 'enumservices' registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-vovi-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration for enumservices web and ft Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-webft-00.txt Pages : 0 Date : 2003-2-24 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are primarily sources for information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-webft-00.txt ################### Additional ENUM WG documents that have revised versions but not on the agenda... A. Peterson SIP enumservice registrations. 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 : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-ietf-enum-sip-00.txt Pages : 9 Date : 2003-2-26 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-00.txt B. Title : ENUM Service Registration for H.323 URL Author(s) : O. Levin Filename : draft-ietf-enum-h323-00.txt Pages : 4 Date : 2003-2-19 The H.323 specification [2] defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers an ENUM service for H.323 according to specifications and guidelines in RFC2916bis [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-00.txt C. Title : Extensible Provisioning Protocol E.164 Number Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-02.txt Pages : 20 Date : 2003-2-20 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-02.txt D. ENUM Privacy and Security E. ENUM Call flows >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 07:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15644 for ; Tue, 4 Mar 2003 07:36:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24ClJ032565 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 07:47:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ClEp32560; Tue, 4 Mar 2003 07:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Ceqp31999 for ; Tue, 4 Mar 2003 07:40:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15000; Tue, 4 Mar 2003 07:29:54 -0500 (EST) Message-Id: <200303041229.HAA15000@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Mar 2003 07:29:54 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to URI DDDS Application (ENUM) Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-04.txt Pages : 21 Date : 2003-3-3 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2916bis-04.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-rfc2916bis-04.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: <2003-3-3145059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3145059.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 09:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24422 for ; Tue, 4 Mar 2003 09:45:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Etdn09900 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 09:55:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24EtZp09895; Tue, 4 Mar 2003 09:55:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Esqp09854 for ; Tue, 4 Mar 2003 09:54:52 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24369 for ; Tue, 4 Mar 2003 09:43:51 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Mon, 03 Mar 2003 20:23:24 -0500 Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: enum@ietf.org In-Reply-To: <200303041229.HAA15000@ietf.org> References: <200303041229.HAA15000@ietf.org> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046789138.4798.8.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 04 Mar 2003 09:45:38 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just before I sent this out there were some additional comments concerning the DNSSEC issue. I decided not to put my proposed text in there since I think the issue probably needs some (hopefully short) discussion in the meeting. As far as I can tell once that text is changed the document should be done (although I would like some more examples)... -MM On Tue, 2003-03-04 at 07:29, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. > > Title : The E.164 to URI DDDS Application (ENUM) > Author(s) : P. Faltstrom, M. Mealling > Filename : draft-ietf-enum-rfc2916bis-04.txt > Pages : 21 > Date : 2003-3-3 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 09:57:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24936 for ; Tue, 4 Mar 2003 09:57:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24F7sl11173 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 10:07:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24F7np11161; Tue, 4 Mar 2003 10:07:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24F6qp10307 for ; Tue, 4 Mar 2003 10:06:52 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24824 for ; Tue, 4 Mar 2003 09:55:51 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA16134 for ; Tue, 4 Mar 2003 06:57:35 -0800 Message-Id: <5.2.0.9.2.20030304095233.0589a4d0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Mar 2003 09:56:55 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] RE: rfc2916bis-04.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I want to emphasize as strongly as I can that the WG read the 04 draft very carefully as it is the candidate for last call. If it is agreeable to the WG, in the absence of substantive comments over the next 5 working days I'll issue last call. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 09:59:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25098 for ; Tue, 4 Mar 2003 09:59:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24FA4T11397 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 10:10:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FA4p11392; Tue, 4 Mar 2003 10:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24F9Xp11314 for ; Tue, 4 Mar 2003 10:09:33 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25015 for ; Tue, 4 Mar 2003 09:58:31 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA16281; Tue, 4 Mar 2003 07:00:15 -0800 Message-Id: <5.2.0.9.2.20030304095832.02cd8eb0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Mar 2003 10:00:03 -0500 To: Michael Mealling , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt In-Reply-To: <1046789138.4798.8.camel@blackdell.neonym.net> References: <200303041229.HAA15000@ietf.org> <200303041229.HAA15000@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 09:45 AM 3/4/2003 -0500, Michael Mealling wrote: >Just before I sent this out there were some additional comments >concerning the DNSSEC issue. I decided not to put my proposed text in >there since I think the issue probably needs some (hopefully short) >discussion in the meeting. As far as I can tell once that text is >changed the document should be done (although I would like some more >examples)... OK .. thats fine with me ...we'll hold off any last call until after SF I'm assuming now that we need an 05. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 10:20:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26825 for ; Tue, 4 Mar 2003 10:20:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24FVBX12624 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 10:31:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FVAp12619; Tue, 4 Mar 2003 10:31:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24FUvp12557 for ; Tue, 4 Mar 2003 10:30:57 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26787 for ; Tue, 4 Mar 2003 10:19:55 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Mon, 03 Mar 2003 20:59:26 -0500 Subject: Re: [Enum] RE: rfc2916bis-04.txt From: Michael Mealling To: Richard Shockey Cc: enum@ietf.org In-Reply-To: <5.2.0.9.2.20030304095233.0589a4d0@popd.ix.netcom.com> References: <5.2.0.9.2.20030304095233.0589a4d0@popd.ix.netcom.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046791300.4809.10.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 04 Mar 2003 10:21:40 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-03-04 at 09:56, Richard Shockey wrote: > I want to emphasize as strongly as I can that the WG read the 04 draft very > carefully as it is the candidate for last call. > > If it is agreeable to the WG, in the absence of substantive comments over > the next 5 working days I'll issue last call. I know of two issues that need to be discussed: 1) final agreement on DNSSEC wording 2) any additional text on the partial e.164 number issue -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 15:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08891 for ; Tue, 4 Mar 2003 15:18:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24KTPP10448 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 15:29:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KT7510441; Tue, 4 Mar 2003 15:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KRf510338 for ; Tue, 4 Mar 2003 15:27:41 -0500 Received: from maynard.mail.mindspring.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08806 for ; Tue, 4 Mar 2003 15:16:33 -0500 (EST) Received: from dialup-209.245.231.95.dial1.dallas1.level3.net ([209.245.231.95] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18qIri-0007G1-00; Tue, 04 Mar 2003 15:18:19 -0500 Message-ID: <3E65263B.7A2F83D6@ix.netcom.com> Date: Tue, 04 Mar 2003 14:18:35 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Michael Mealling CC: Richard Shockey , enum@ietf.org Subject: Re: [Enum] RE: rfc2916bis-04.txt References: <5.2.0.9.2.20030304095233.0589a4d0@popd.ix.netcom.com> <1046791300.4809.10.camel@blackdell.neonym.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael and all, I agree with Michael here... Michael Mealling wrote: > On Tue, 2003-03-04 at 09:56, Richard Shockey wrote: > > I want to emphasize as strongly as I can that the WG read the 04 draft very > > carefully as it is the candidate for last call. > > > > If it is agreeable to the WG, in the absence of substantive comments over > > the next 5 working days I'll issue last call. > > I know of two issues that need to be discussed: > > 1) final agreement on DNSSEC wording > 2) any additional text on the partial e.164 number issue > > -MM > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 4 23:14:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21645 for ; Tue, 4 Mar 2003 23:14:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h254OsA09836 for enum-archive@odin.ietf.org; Tue, 4 Mar 2003 23:24:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h254Oo509830; Tue, 4 Mar 2003 23:24:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h254NR509796 for ; Tue, 4 Mar 2003 23:23:27 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21625 for ; Tue, 4 Mar 2003 23:12:09 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 5 Mar 2003 05:17:57 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Thread-Index: AcLiYBXeDIv1nuuEQ1O319xPCdT5IQAbTBlj From: "Stastny Richard" To: "Richard Shockey" , "Michael Mealling" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h254NR509797 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rich and MM, was it really necessary to introduce so much new text in 04? I hoped to have rfc2916bis from the table soon, but with all this new text in section 1.3, 2.4, 2.5, 2.6 and wherever else I have a problem. I need to discuss and understand the impact of all these issues so IMHO it is not yet possible to have a last call now. So I also agree to hold off last call until SFO. best regards Richard Stastny -----Ursprüngliche Nachricht----- Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Di 04.03.2003 16:00 An: Michael Mealling; enum@ietf.org Cc: Betreff: Re: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt At 09:45 AM 3/4/2003 -0500, Michael Mealling wrote: >Just before I sent this out there were some additional comments >concerning the DNSSEC issue. I decided not to put my proposed text in >there since I think the issue probably needs some (hopefully short) >discussion in the meeting. As far as I can tell once that text is >changed the document should be done (although I would like some more >examples)... OK .. thats fine with me ...we'll hold off any last call until after SF I'm assuming now that we need an 05. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 5 06:22:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25175 for ; Wed, 5 Mar 2003 06:22:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BX0L15837 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 06:33:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BWu515826; Wed, 5 Mar 2003 06:32:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BV5515793 for ; Wed, 5 Mar 2003 06:31:05 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25166 for ; Wed, 5 Mar 2003 06:19:37 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 11:21:40 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2T8YR56; Wed, 5 Mar 2003 11:21:32 -0000 From: "Conroy, Lawrence (SMTP)" To: Michael Mealling , enum@ietf.org Cc: Richard@shockey.us Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1046789138.4798.8.camel@blackdell.neonym.net> References: <200303041229.HAA15000@ietf.org> <1046789138.4798.8.camel@blackdell.neonym.net> Date: Wed, 5 Mar 2003 11:21:28 +0000 Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 9:45 am -0500 4/3/03, Michael Mealling wrote: >Just before I sent this out there were some additional comments >concerning the DNSSEC issue. I decided not to put my proposed text in >there since I think the issue probably needs some (hopefully short) >discussion in the meeting. As far as I can tell once that text is >changed the document should be done (although I would like some more >examples)... Hi Folks, in the examples of 4.1, enumservice "msg" is given (twice). I guess that this "crossed" with the update to/replacement of the earlier evil 'compendium' draft, and will be changed to "email". Correct? On the topic, I also am not sure this is quite ready for WGLC, as I need to understand the new text; I look forward to the SF meeting. atb, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 09:49:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02007 for ; Wed, 5 Mar 2003 09:49:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25F0YA31671 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 10:00:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25F0U531663; Wed, 5 Mar 2003 10:00:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Exq531533 for ; Wed, 5 Mar 2003 09:59:52 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01928 for ; Wed, 5 Mar 2003 09:48:21 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 04 Mar 2003 20:27:45 -0500 Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: Stastny Richard Cc: Richard Shockey , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046875800.4809.49.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 09:50:00 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-03-04 at 23:17, Stastny Richard wrote: > was it really necessary to introduce so much new text in 04? It was based on issues people brought up on the list so as the document author I'm duty bound to reflect list consensus in the document.Plus some sections (like 1.3) were simply incorrect but needed more text to explain what the real issue was. None of the changes are substantive. Nothing technical has changed with how ENUM works at all. Just explanatory text. > I hoped to have > rfc2916bis from the table soon, but with all this new text in section 1.3, 2.4, 2.5, 2.6 > and wherever else I have a problem. I need to discuss and understand the impact of all these issues > so IMHO it is not yet possible to have a last call now. > > So I also agree to hold off last call until SFO. Feel free to bug me directly if you have questions about the new text... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 10:33:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05670 for ; Wed, 5 Mar 2003 10:33:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FiHo04705 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 10:44:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FiD504700; Wed, 5 Mar 2003 10:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FhB504601 for ; Wed, 5 Mar 2003 10:43:11 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05481 for ; Wed, 5 Mar 2003 10:31:38 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA14716; Wed, 5 Mar 2003 07:33:20 -0800 Message-Id: <5.2.0.9.2.20030305100327.0564ad10@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Mar 2003 10:05:09 -0500 To: "Stastny Richard" , "Michael Mealling" , From: Richard Shockey Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt In-Reply-To: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 05:17 AM 3/5/2003 +0100, Stastny Richard wrote: >Hi Rich and MM, > >was it really necessary to introduce so much new text in 04? I hoped to have >rfc2916bis from the table soon, but with all this new text in section 1.3, >2.4, 2.5, 2.6 >and wherever else I have a problem. I need to discuss and understand the >impact of all these issues >so IMHO it is not yet possible to have a last call now. > >So I also agree to hold off last call until SFO. OK I agree but get your comments to the list ASAP... We all agree that it is essential this work move forward quickly. > >best regards >Richard Stastny > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 10:34:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05805 for ; Wed, 5 Mar 2003 10:34:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Fj2N04855 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 10:45:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Fj2504850; Wed, 5 Mar 2003 10:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Fij504799 for ; Wed, 5 Mar 2003 10:44:45 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05652 for ; Wed, 5 Mar 2003 10:33:12 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 15:35:15 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2T8YS31; Wed, 5 Mar 2003 15:35:12 -0000 From: "Conroy, Lawrence (SMTP)" To: Michael Mealling , Stastny Richard Cc: Richard Shockey , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1046875800.4809.49.camel@blackdell.neonym.net> References: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> <1046875800.4809.49.camel@blackdell.neonym.net> Date: Wed, 5 Mar 2003 15:34:30 +0000 Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 9:50 am -0500 5/3/03, Michael Mealling wrote: >Plus some sections (like 1.3) were simply incorrect but needed more text to >explain what the real issue was. > >None of the changes are substantive. Nothing technical has changed with >how ENUM works at all. Just explanatory text. Hi Michael, Folks, I'm intrigued - what about section 1.3 of rfc2916bis-03.txt was wrong and has been corrected by this version? all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 10:42:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06612 for ; Wed, 5 Mar 2003 10:42:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25FrBW05326 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 10:53:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FrA505321; Wed, 5 Mar 2003 10:53:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25FqQ505279 for ; Wed, 5 Mar 2003 10:52:26 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06417 for ; Wed, 5 Mar 2003 10:40:54 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 04 Mar 2003 21:20:20 -0500 Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: "Conroy, Lawrence (SMTP)" Cc: Stastny Richard , Richard Shockey , enum@ietf.org In-Reply-To: References: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> <1046875800.4809.49.camel@blackdell.neonym.net> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046878957.4809.65.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 10:42:37 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 10:34, Conroy, Lawrence (SMTP) wrote: > At 9:50 am -0500 5/3/03, Michael Mealling wrote: > > >Plus some sections (like 1.3) were simply incorrect but needed more text to > >explain what the real issue was. > > > >None of the changes are substantive. Nothing technical has changed with > >how ENUM works at all. Just explanatory text. > > Hi Michael, Folks, > I'm intrigued - what about section 1.3 of rfc2916bis-03.txt was > wrong and has been corrected by this version? It was the interaction between the Order and Preference fields. The old 1.3 simply said 'order' need not be preserved when it really meant Preference. The intent of the old 1.3 was to allow a client to pick the most appropriate record for their application. Which is what the Preference field is for. The Order field has to be adhered to since DNS records can be in any order. The key point in 1.3 is this: The Order field in the NAPTR is a request from the holder of the E.164 number that the records be handled in a specifc way. The Preference field is merely a suggestion from that E.164 holder that one record might be better than another. A client implementing ENUM MUST adhere to the Order field but can simply take the Preference value "on advisement" as part of a client context specific selection method. Which means that in many cases, most ENUM zone entries will all have the same Order but with different Preferences. But in the cases where there is a difference then the client still has to take Order into account first. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 11:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08731 for ; Wed, 5 Mar 2003 11:00:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25GBfl08053 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 11:11:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GBZ508046; Wed, 5 Mar 2003 11:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GA6507923 for ; Wed, 5 Mar 2003 11:10:06 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08444 for ; Wed, 5 Mar 2003 10:58:33 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 16:00:35 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2T8YSQT; Wed, 5 Mar 2003 16:00:30 -0000 From: "Conroy, Lawrence (SMTP)" To: Michael Mealling Cc: Stastny Richard , Richard Shockey , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1046878957.4809.65.camel@blackdell.neonym.net> References: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> <1046875800.4809.49.camel@blackdell.neonym.net> <1046878957.4809.65.camel@blackdell.neonym.net> Date: Wed, 5 Mar 2003 16:00:26 +0000 Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 10:42 am -0500 5/3/03, Michael Mealling wrote: >On Wed, 2003-03-05 at 10:34, Conroy, Lawrence (SMTP) wrote: >> At 9:50 am -0500 5/3/03, Michael Mealling wrote: >> >> >Plus some sections (like 1.3) were simply incorrect but needed more text to >> >explain what the real issue was. >> > >> >None of the changes are substantive. Nothing technical has changed with >> >how ENUM works at all. Just explanatory text. >> >> Hi Michael, Folks, >> I'm intrigued - what about section 1.3 of rfc2916bis-03.txt was >> wrong and has been corrected by this version? > >It was the interaction between the Order and Preference fields. The old >1.3 simply said 'order' need not be preserved when it really meant >Preference. The intent of the old 1.3 was to allow a client to pick the >most appropriate record for their application. Which is what the >Preference field is for. The Order field has to be adhered to since DNS >records can be in any order. The key point in 1.3 is this: > > The Order field in the NAPTR is a > request from the holder of the E.164 number that the records be > handled in a specifc way. The Preference field is merely a > suggestion from that E.164 holder that one record might be better > than another. A client implementing ENUM MUST adhere to the Order > field but can simply take the Preference value "on advisement" as > part of a client context specific selection method. > >Which means that in many cases, most ENUM zone entries will all have the >same Order but with different Preferences. But in the cases where there >is a difference then the client still has to take Order into account >first. > >-MM Hi Michael, folks, Well... That's not all that the new improved 1.3 says, or it would be two sentences or three sentences long: "The ORDER field value in a set of NAPTRs MUST be used to select the order in which these NAPTRs are processed. The PREFERENCE field acts as a recommendation and so may be over-ridden based on local policies that are not the subject of standardisation; thus the PREFERENCE field MAY be used to select between NAPTRs holding the same ORDER field value". For reference, the 1.3 from 2916bis-03 doesn't mention the ORDER field at all: " The preference field in the NAPTR is a request from the holder of the E.164 in what order the records are to be used. It is to be noted that the party looking up the records MAY apply a local policy for in what order the records are to be used based on a combination of the service fields and URI schemes. This overrides the MUST requirement in the DDDS algorithm. " I wonder if we're adding in text on "End System" policy; wouldn't this be better in a subsequent BCP rather than a Protocol Standard document? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 11:21:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10257 for ; Wed, 5 Mar 2003 11:21:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25GWDE09765 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 11:32:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GWD509760; Wed, 5 Mar 2003 11:32:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25GVs509702 for ; Wed, 5 Mar 2003 11:31:54 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10196 for ; Wed, 5 Mar 2003 11:20:20 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 04 Mar 2003 21:59:45 -0500 Subject: Re: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: "Conroy, Lawrence (SMTP)" Cc: Stastny Richard , Richard Shockey , enum@ietf.org In-Reply-To: References: <06CF906FE3998C4E944213062009F1620DF021@oefeg-s02.oefeg.loc> <1046875800.4809.49.camel@blackdell.neonym.net> <1046878957.4809.65.camel@blackdell.neonym.net> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046881323.4809.78.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 11:22:03 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 11:00, Conroy, Lawrence (SMTP) wrote: > At 10:42 am -0500 5/3/03, Michael Mealling wrote: > >It was the interaction between the Order and Preference fields. The old > >1.3 simply said 'order' need not be preserved when it really meant > >Preference. The intent of the old 1.3 was to allow a client to pick the > >most appropriate record for their application. Which is what the > >Preference field is for. The Order field has to be adhered to since DNS > >records can be in any order. The key point in 1.3 is this: > > > > The Order field in the NAPTR is a > > request from the holder of the E.164 number that the records be > > handled in a specifc way. The Preference field is merely a > > suggestion from that E.164 holder that one record might be better > > than another. A client implementing ENUM MUST adhere to the Order > > field but can simply take the Preference value "on advisement" as > > part of a client context specific selection method. > > > >Which means that in many cases, most ENUM zone entries will all have the > >same Order but with different Preferences. But in the cases where there > >is a difference then the client still has to take Order into account > >first. > > > >-MM > > Hi Michael, folks, > Well... > That's not all that the new improved 1.3 says, or it would be two sentences > or three sentences long: One thing I've learned is that if you don't explain why you make such a statement everyone believes its just your personal opinion. All of the rest of the text explains why Order and Preference are the way they are. > "The ORDER field value in a set of NAPTRs MUST be used to select the order > in which these NAPTRs are processed. The PREFERENCE field acts as a > recommendation and so may be over-ridden based on local policies that are not the subject of > standardisation; thus the PREFERENCE field MAY be used to select between NAPTRs > holding the same ORDER field value". Sure. That's the conclusion. But without understanding why the DDDS has them you really wouldn't be able to understand why that requirement is what it is. And when some people read these things they assume that since they don't see any harm that there isn't any. > For reference, the 1.3 from 2916bis-03 doesn't mention the ORDER field at all: > " > The preference field in the NAPTR is a request from the holder of the > E.164 in what order the records are to be used. It is to be noted > that the party looking up the records MAY apply a local policy for in > what order the records are to be used based on a combination of the > service fields and URI schemes. This overrides the MUST requirement > in the DDDS algorithm. > " Actually it does. It uses the term 'order' as the 4th word in the 2nd line. After talking to those that wrote 1.3 it became obvious that what 1.3 said and what it was intended to mean were two different things. Plus it just wasn't clear at all which MUST was being overridden. > I wonder if we're adding in text on "End System" policy; wouldn't this > be better in a subsequent BCP rather than a Protocol Standard document? NO. This stuff is extremely important to how the DDDS algorithm works and is based on many other applications that ENUM is extremely similar to. At this point many here have extremely simplistic views of what their ENUM applications will be like. But I can guarantee you that they won't remain that simplistic for very long. If this core algorithm stuff isn't right then the future pain will be horrible. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 23:12:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12090 for ; Wed, 5 Mar 2003 23:12:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h264Msr19537 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 23:22:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264MeO19526; Wed, 5 Mar 2003 23:22:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264I9O19395 for ; Wed, 5 Mar 2003 23:18:09 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12002 for ; Wed, 5 Mar 2003 23:06:48 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 6 Mar 2003 05:12:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DF02C@oefeg-s02.oefeg.loc> Thread-Topic: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Thread-Index: AcLjM+/QVxO04CQJSqa/zLRCiN3ahwAYVKQN From: "Stastny Richard" To: "Michael Mealling" , "Conroy, Lawrence (SMTP)" Cc: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h264IDO19397 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit MM wrote >NO. This stuff is extremely important to how the DDDS algorithm works >and is based on many other applications that ENUM is extremely similar >to. At this point many here have extremely simplistic views of what >their ENUM applications will be like. But I can guarantee you that they >won't remain that simplistic for very long. If this core algorithm stuff >isn't right then the future pain will be horrible. Last IETF I somehow got the impression that many here (as you state above) had the extremely simplistic view that an ENUM domain contains only ONE NAPTR record with a sip URI, so you do not need any order or preference at all. Is it this what you are talking about? On the other hand, I did not see any real example in any real implementations where the order is really needed. regards Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 23:31:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12357 for ; Wed, 5 Mar 2003 23:31:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h264g8F20935 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 23:42:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264g6O20930; Wed, 5 Mar 2003 23:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264dSO20833 for ; Wed, 5 Mar 2003 23:39:28 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12318 for ; Wed, 5 Mar 2003 23:28:07 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 05 Mar 2003 10:07:29 -0500 Subject: Re: AW: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: Stastny Richard Cc: "Conroy, Lawrence (SMTP)" , Richard Shockey , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF02C@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF02C@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046924988.4798.116.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 23:29:49 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 23:12, Stastny Richard wrote: > MM wrote > > >NO. This stuff is extremely important to how the DDDS algorithm works > >and is based on many other applications that ENUM is extremely similar > >to. At this point many here have extremely simplistic views of what > >their ENUM applications will be like. But I can guarantee you that they > >won't remain that simplistic for very long. If this core algorithm stuff > >isn't right then the future pain will be horrible. > > Last IETF I somehow got the impression that many here (as you state > above) had the extremely simplistic view that an ENUM domain contains > only ONE NAPTR record with a sip URI, so you do not need any order > or preference at all. Is it this what you are talking about? Yep. And that has very little impact on the zone maintainer. The issue here is how a client gets implemented. Its perfectly fine for a server to have only one record but its not fine for a client to act as though no one will ever do otherwise. A server can change the zone data whenever they like. But if we get the clients wrong you'll always be hamstrung. For the longest time we had problems with DNS implementations that fell on their face when presented with unknown RR types. We're still hamstrung by the getXbyY APIs that assumed incorrectly that A records was all anyone cared about. If you aren't writing client code for public consumption then you can ignore everything I'm saying here. But if you are then your code is going to have to live not only with your zones, but others as well. > On the other hand, I did not see any real example in any real > implementations where the order is really needed. You do not have perfect knowledge of the future uses and implementation requires of ENUM based applications. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 23:43:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12673 for ; Wed, 5 Mar 2003 23:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h264s9F21404 for enum-archive@odin.ietf.org; Wed, 5 Mar 2003 23:54:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264s8O21399; Wed, 5 Mar 2003 23:54:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h264ppO21331 for ; Wed, 5 Mar 2003 23:51:51 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12645 for ; Wed, 5 Mar 2003 23:40:28 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 6 Mar 2003 05:46:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DF02D@oefeg-s02.oefeg.loc> Thread-Topic: AW: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt Thread-Index: AcLjmZs0g209FD6rSUqzwu/d1f4fdwAAQ+a/ From: "Stastny Richard" To: "Michael Mealling" Cc: "Conroy, Lawrence (SMTP)" , "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h264ppO21332 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >You do not have perfect knowledge of the future uses and implementation >requires of ENUM based applications. I have to admit, no I have not. But my problem currently is to explain normal people all over the world how ENUM is intended to work in principle. Your examples are not very helpful in this regard, especially if I have troubles to understand them myself ;-) They a way off the basics. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 5 23:54:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12868 for ; Wed, 5 Mar 2003 23:54:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26556m21778 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 00:05:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26555O21773; Thu, 6 Mar 2003 00:05:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2652JO21685 for ; Thu, 6 Mar 2003 00:02:19 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12836 for ; Wed, 5 Mar 2003 23:50:57 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 05 Mar 2003 10:30:19 -0500 Subject: Re: AW: AW: AW: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-04.txt From: Michael Mealling To: Stastny Richard Cc: "Conroy, Lawrence (SMTP)" , Richard Shockey , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF02D@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF02D@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046926359.4798.126.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 23:52:39 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 23:46, Stastny Richard wrote: > >You do not have perfect knowledge of the future uses and implementation > >requires of ENUM based applications. > > I have to admit, no I have not. But my problem currently is to explain > > normal people all over the world how ENUM is intended to work in > > principle. I understand. But what you have to explain to them is that 80% of the time its pretty simple, but 20% of the time it can get complicated. > Your examples are not very helpful in this regard, especially if > I have troubles to understand them myself ;-) They a way off the basics. Exactly. If all you're interested in is the basics then I'm sure what I'm saying is frustrating. You don't want to have to deal with anything complicated if you can at all help it. But what I'm suggesting isn't complicated to implement: simply take all the NAPTRs you received and put them in order based on the Order field. That's a fairly simple thing to do. The complexity is an emergent property. The algorithm is simple, but when you run certain things through it, it can appear complex. I implemented the URI resolution version of this algorithm in about a hundred lines of code. The part dealing with the Order field was about 2 lines (using a built in sorter). I'm going to try my best to get you some examples of the things you can do with this if you just implement the algorithm. But I'm concerned that you wont' find them compelling if I'm not delivering products next week using them.... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 08:08:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11598 for ; Thu, 6 Mar 2003 08:08:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26DJjZ02653 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 08:19:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DJcO02624; Thu, 6 Mar 2003 08:19:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DGxO02465 for ; Thu, 6 Mar 2003 08:16:59 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11255 for ; Thu, 6 Mar 2003 08:05:26 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18qv5u-0006CT-00 for ; Thu, 06 Mar 2003 15:07:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15975.18450.314787.378401@harjus.eng.song.fi> Date: Thu, 6 Mar 2003 15:07:30 +0200 To: enum@ietf.org X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Subject: [Enum] draft-brandner-enumservice-vovi-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit someone pointed me to draft-brandner-enumservice-vovi-00.txt, which i think is a VERY BAD idea at least for sip. the enum entry of my phone number would simply point to sip:jh@song.fi without any service types, since those change all the time depending on what kind terminals i have registered with the proxy of song.fi. there are caller preferences and so on that tell the capabilities of my current registered terminals. is this document really somehow endorsed my the enum working group? if i remember correctly, this issue was discussed at atlanta and many people shared the above view. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 14:14:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07157 for ; Thu, 6 Mar 2003 14:14:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JPEp05443 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 14:25:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JP7O05438; Thu, 6 Mar 2003 14:25:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JIeO05116 for ; Thu, 6 Mar 2003 14:18:40 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06903 for ; Thu, 6 Mar 2003 14:06:59 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA06811; Thu, 6 Mar 2003 20:09:01 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id UAA21360; Thu, 6 Mar 2003 20:08:27 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 20:08:48 +0100 Message-ID: From: Brandner Rudolf To: "'jh@lohi.eng.song.fi'" Cc: enum@ietf.org, "'rudis@brandner-web.de'" Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Thu, 6 Mar 2003 20:08:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26JIeO05117 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Juha, folks, the issue you are trying to get at has been discussed on the list and on IETF meetings. However, the issue has not been solved so far, IMHO. You point out, that the enumservice registrations in the draft are very bad, at least for SIP. You do not point out, what the bad thing is. In your case, where you have just one SIP proxy/registrar, the enumservice 'voice:sip' might not be very useful. Well, AFAIK, we did not say that this enumservice is mandatory, nor that it is useful in your or every case. Nevertheless, there are other circumstances, where the enumservice 'voice:sip' has its benefits and value. The reason we included a way to hint that this SIP-based Service would be used for Real-Time Communications whilst that would be used for IM is simple; a significant group of folk that I know have two different accounts - one with Redmond for IM, with another with Richardson for voice. If you try the Richardson account, you won't find anyone listening for IM; if you try to voice-call my IM account, you won't get much joy. Now...which entry do I put in my ENUM domain? Our answer is both; yours is just one, as you only have one SIP-based service. Having both entries gives you a hint which one to use if you want to have, as an example, real-time voice communication. To say that it's (always) a BAD IDEA to give these hints is not, IMHO, proven, just because it is not appropriate for some configurations. best regards, Rudi > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Donnerstag, 6. März 2003 14:07 > To: enum@ietf.org > Subject: [Enum] draft-brandner-enumservice-vovi-00.txt > > > someone pointed me to draft-brandner-enumservice-vovi-00.txt, which i > think is a VERY BAD idea at least for sip. the enum entry of my phone > number would simply point to sip:jh@song.fi without any service types, > since those change all the time depending on what kind > terminals i have > registered with the proxy of song.fi. there are caller > preferences and > so on that tell the capabilities of my current registered terminals. > > is this document really somehow endorsed my the enum working > group? if > i remember correctly, this issue was discussed at atlanta and many > people shared the above view. > > -- juha > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Mar 6 14:43:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08476 for ; Thu, 6 Mar 2003 14:43:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26JslO07899 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 14:54:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JsbO07894; Thu, 6 Mar 2003 14:54:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26JaVO06139 for ; Thu, 6 Mar 2003 14:36:31 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07683 for ; Thu, 6 Mar 2003 14:24:50 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 06 Mar 2003 01:04:07 -0500 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt From: Michael Mealling To: Brandner Rudolf Cc: "'jh@lohi.eng.song.fi'" , enum@ietf.org, "'rudis@brandner-web.de'" In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 Organization: Harriman Heavy Industries, Inc. Message-Id: <1046978789.4809.204.camel@blackdell.neonym.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 14:26:29 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Thu, 2003-03-06 at 14:08, Brandner Rudolf wrote: > Hi Juha, folks, > > the issue you are trying to get at has been discussed on the list and on IETF meetings. However, the issue has not been solved so far, IMHO. > > You point out, that the enumservice registrations in the draft are very bad, at least for SIP. You do not point out, what the bad thing is. > > In your case, where you have just one SIP proxy/registrar, the enumservice 'voice:sip' might not be very useful. Well, AFAIK, we did not say that this enumservice is mandatory, nor that it is useful in your or every case. > > Nevertheless, there are other circumstances, where the enumservice 'voice:sip' has its benefits and value. The reason we included a way to hint that this SIP-based Service would be used for Real-Time Communications whilst that would be used for IM is simple; a significant group of folk that I know have two different accounts - one with Redmond for IM, with another with Richardson for voice. If you try the Richardson account, you won't find anyone listening for IM; if you try to voice-call my IM account, you won't get much joy. Now...which entry do I put in my ENUM domain? Our answer is both; yours is just one, as you only have one SIP-based service. Having both entries gives you a hint which one to use if you want to have, as an example, real-time voice communication. > > To say that it's (always) a BAD IDEA to give these hints is not, IMHO, proven, just because it is not appropriate for some configurations. I'd like to voice some support here for Rudi's point. The point of ENUM Services being speced the way they are is so that multiple services can exist side by side without interfering with each other. If one services chooses to be SIP only with no other information specified then that's fine. Its also fine to do it Rudi's way. Both are two different enumservices doing two different things. One is free to ignore the other. SIP is not the only protocol in the universe.... -MM > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: Donnerstag, 6. März 2003 14:07 > > To: enum@ietf.org > > Subject: [Enum] draft-brandner-enumservice-vovi-00.txt > > > > > > someone pointed me to draft-brandner-enumservice-vovi-00.txt, which i > > think is a VERY BAD idea at least for sip. the enum entry of my phone > > number would simply point to sip:jh@song.fi without any service types, > > since those change all the time depending on what kind > > terminals i have > > registered with the proxy of song.fi. there are caller > > preferences and > > so on that tell the capabilities of my current registered terminals. > > > > is this document really somehow endorsed my the enum working > > group? if > > i remember correctly, this issue was discussed at atlanta and many > > people shared the above view. > > > > -- juha > > > > _______________________________________________ > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 15:18:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11028 for ; Thu, 6 Mar 2003 15:18:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26KU0n10816 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 15:30:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KTuO10800; Thu, 6 Mar 2003 15:29:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KDiO09772 for ; Thu, 6 Mar 2003 15:13:44 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09212 for ; Thu, 6 Mar 2003 15:02:02 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18r1b3-0006gO-00; Thu, 06 Mar 2003 22:04:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15975.43445.217950.295118@harjus.eng.song.fi> Date: Thu, 6 Mar 2003 22:04:05 +0200 To: Michael Mealling Cc: Brandner Rudolf , enum@ietf.org, "'rudis@brandner-web.de'" Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt In-Reply-To: <1046978789.4809.204.camel@blackdell.neonym.net> References: <1046978789.4809.204.camel@blackdell.neonym.net> X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Mealling writes: > SIP is not the only protocol in the universe.... it is ok with me to use different enum entries for sip and other protocols. my comment was about the usefulness of having several entries for sip (voice, video, im, presence, ..) since we one entry with caller preferences solves the problem in a better way. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 15:56:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12166 for ; Thu, 6 Mar 2003 15:56:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26L7BY13848 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 16:07:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26L79O13786; Thu, 6 Mar 2003 16:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26KZAO11289 for ; Thu, 6 Mar 2003 15:35:10 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11233 for ; Thu, 6 Mar 2003 15:23:28 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 06 Mar 2003 02:02:47 -0500 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt From: Michael Mealling To: jh@lohi.eng.song.fi Cc: Brandner Rudolf , enum@ietf.org, "'rudis@brandner-web.de'" In-Reply-To: <15975.43445.217950.295118@harjus.eng.song.fi> References: <1046978789.4809.204.camel@blackdell.neonym.net> <15975.43445.217950.295118@harjus.eng.song.fi> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046982309.4798.212.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 15:25:10 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 15:04, jh@lohi.eng.song.fi wrote: > Michael Mealling writes: > > > SIP is not the only protocol in the universe.... > > it is ok with me to use different enum entries for sip and other > protocols. my comment was about the usefulness of having several > entries for sip (voice, video, im, presence, ..) since we one entry > with caller preferences solves the problem in a better way. But the point (and realities) of others is that it is proving impossible to actually do that due to policies associated with who controls that SIP gateway. Its also the case that many will want to support SIP in a limited sense for a particular application instead of the entire SIP standard. One entry with caller preferences assumes SIP is my preferred method when that is not true in my case or many others. You're assuming SIP is the primary method when what Rudi and I are assuming is that its a non-preferred, minimalist gateway function to provide interoperability with those who only have SIP for some reason. Rudi wants a way of saying "ok, use SIP if you have to but it only works for voice and its not the best choice for interacting with this system". Just telling him to chunk it all use SIP everywhere isn't solving his problem. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 16:47:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14393 for ; Thu, 6 Mar 2003 16:47:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26LwY818667 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 16:58:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LwUO18662; Thu, 6 Mar 2003 16:58:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26LvIO18575 for ; Thu, 6 Mar 2003 16:57:18 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14278 for ; Thu, 6 Mar 2003 16:45:35 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h26Ll4C25572; Thu, 6 Mar 2003 21:47:04 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 16:47:11 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" Cc: enum@ietf.org, "'rudis@brandner-web.de'" Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Thu, 6 Mar 2003 16:47:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , I wanted to make some comments about this issue. From my perspective, this discussion is really not about ENUM at all. ENUM is a system for transforming one kind of identifier into another kind of identifier. This is a question about how SIP is used. The problem is that you describe a scenario below for the usage of SIP in which it is preferable for users to have multiple identifiers for a target, each of which is associated with a different capability or service - it really doesn't matter whether these identifiers were acquired from ENUM, from a web page, or wherever. The only important point is that SIP is not a protocol that profits from having multiple identifiers sorted by the capabilities associated with these identifiers. One of the primary purposes of SIP is to due away with the need to learn multiple identifiers for a particular user - this is the whole point of dynamic registration, forking, presence and many of SIP's other virtues. When your argument is predicated on a benefit that SIP user agent clients will derive from holding multiple identifiers for a target that each represent a different service or capability, this shows up to SIP people as a misunderstanding. SIP user agents would not benefit from this, and in fact, there are ways in which it seems obviously detrimental. It is moreover not how most SIP user agents operate - they assume that you plug in a single URI and let SIP take care of the rest. The reason why this is 'bad' is that this model suggests that the way to manage the set of URIs you use for SIP is to publish them in ENUM, rather than registering them in SIP. This is problematic because: - ENUM is not necessarily a prerequisite for using SIP - sometimes people may try to reach me with SIP without first using ENUM. Because I want to make all of my identifiers available to people who use SIP without consulting ENUM first (because they already have a URI, not a telephone number), we cannot replace SIP registration with ENUM records - we'd have to keep them in SIP as well. Provisioning multiple URIs in ENUM will always have to be redundant with SIP registration. This raises questions of synchronization and the usual issues that arise with (undesirable) redundancy. - SIP has a built-in method for registering a URI under another URI, with lots of apparatus for security, privacy, refreshes, expirations, priority, capability, and so on. Any SIP compliant (2543 or 3261) user agent will support this method. Most SIP user agents register automatically when they boot or come online. I don't think we've yet identified a way for applications to similarly publish information into ENUM. For many applications that would be identified by ENUM (like email clients or web pages) the concept isn't even meaningful. - SIP registrations may have very brief durations. I may only be associated with a device (and hence the devices URI) for a short amount of time. It isn't clear that the DNS is the best place to express very short term relationships of this nature. DNS scales most effectively when entries can be cached for more significant durations (at least hours). SIP is optimized for real-time establishment and termination of registrations. - The capabilities expressed by primitives like 'voice' and 'video' are both too coarse and too strict for SIP. They are too coarse because they will always be redundant with SIP's own SDP-based negotiation upon session establishment, which gets into far greater details about what 'video' entails (codecs and intervals, and so on) - if two SIP endpoints both support 'video' that doesn't mean they'll be able to communicate. The primitives are too strict because the SIP process is designed to find the best way for two user agents to communicate, taking into account the capabilities and preferences of both. Designating that a SIP URI is a 'voice' URI doesn't even really make sense. If you don't need this capability negotiation function of SIP, you probably don't need SIP as such. In the example below, users do not register their Redmond SIP URI under their Richardson SIP URI or vice versa. There is presumably some non-technical reason for this (presumably service provider policies forbid it). However, in light of RFC3261 I find this somewhat unlikely. There's no mechanism that allows a registrar to 'reject' a registration of a contact URI under an address-of-record on the grounds that that they don't like that contact - there's not a way to reject particular contacts at all. Registrars don't even inspect the contact URIs themselves for semantics - they are a black box to the registrar which it doles out when people ask how to reach a user. The registrar doesn't even have to understand the URI scheme. Now, the entire registration can be rejected if the registering user agent isn't authenticated, of course, but this is just a matter of whether or not a shared secret is known by the operator of the user agent. I'm not sure what enforceable constraint could be applied that would block these sorts of Redmond-under-Richardson registrations. I suspect that this is a kind of pseudoproblem. I have no doubt that users could elect to selectively register at different registrars, thereby impoverishing SIP's overall functionality. But it is certainly no less difficult to put multiple URIs in ENUM than it is to register them in SIP, and I suspect, given SIP's built-in dynamic registration capabilities, it is easier to do it with SIP. Even if it were impossible, somehow, to register Redmond under Richardson, one could still go get an iptel.org SIP URI and register both under that. Try it - it's free and easy. We shouldn't try to mandate that implementers and users cannot use SIP is ways other than its designers intended - such a mandate would be pointless. What we should do, however, is not produce standards that use other standards incorrectly, or misunderstand their applicability. These proposals are essentially describing an alternative architectural model for SIP, one that is not friendly to the architecture in the SIP specification. In this strawman version of SIP, it might appear that ENUM provides capabilities that SIP lacks and desperately needs. But from my vantage that need is illusory. Let's not standardize a way of using ENUM and SIP together that makes assumptions contrary to the way SIP can and does work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Brandner Rudolf [mailto:rudolf.brandner@siemens.com] > Sent: Thursday, March 06, 2003 11:09 AM > To: 'jh@lohi.eng.song.fi' > Cc: enum@ietf.org; 'rudis@brandner-web.de' > Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt > > > Hi Juha, folks, > > the issue you are trying to get at has been discussed on the > list and on IETF meetings. However, the issue has not been > solved so far, IMHO. > > You point out, that the enumservice registrations in the > draft are very bad, at least for SIP. You do not point out, > what the bad thing is. > > In your case, where you have just one SIP proxy/registrar, > the enumservice 'voice:sip' might not be very useful. Well, > AFAIK, we did not say that this enumservice is mandatory, nor > that it is useful in your or every case. > > Nevertheless, there are other circumstances, where the > enumservice 'voice:sip' has its benefits and value. The > reason we included a way to hint that this SIP-based Service > would be used for Real-Time Communications whilst that would > be used for IM is simple; a significant group of folk that I > know have two different accounts - one with Redmond for IM, > with another with Richardson for voice. If you try the > Richardson account, you won't find anyone listening for IM; > if you try to voice-call my IM account, you won't get much > joy. Now...which entry do I put in my ENUM domain? Our answer > is both; yours is just one, as you only have one SIP-based > service. Having both entries gives you a hint which one to > use if you want to have, as an example, real-time voice communication. > > To say that it's (always) a BAD IDEA to give these hints is > not, IMHO, proven, just because it is not appropriate for > some configurations. > > best regards, > Rudi > > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: Donnerstag, 6. März 2003 14:07 > > To: enum@ietf.org > > Subject: [Enum] draft-brandner-enumservice-vovi-00.txt > > > > > > someone pointed me to > draft-brandner-enumservice-vovi-00.txt, which i > > think is a VERY BAD idea at least for sip. the enum entry > of my phone > > number would simply point to sip:jh@song.fi without any > service types, > > since those change all the time depending on what kind > > terminals i have > > registered with the proxy of song.fi. there are caller > > preferences and > > so on that tell the capabilities of my current registered terminals. > > > > is this document really somehow endorsed my the enum working > > group? if > > i remember correctly, this issue was discussed at atlanta and many > > people shared the above view. > > > > -- juha > > > > _______________________________________________ > > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 17:30:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15930 for ; Thu, 6 Mar 2003 17:30:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26MfIo23039 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 17:41:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MfGO23034; Thu, 6 Mar 2003 17:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26MeDO22989 for ; Thu, 6 Mar 2003 17:40:13 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15909 for ; Thu, 6 Mar 2003 17:28:29 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 22:30:33 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8ANPK; Thu, 6 Mar 2003 22:30:29 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" Cc: enum@ietf.org, "'rudis@brandner-web.de'" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> Date: Thu, 6 Mar 2003 22:30:25 +0000 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 4:47 pm -0500 6/3/03, Peterson, Jon wrote: >I wanted to make some comments about this issue. >We shouldn't try to mandate that implementers and users cannot use SIP is >ways other than its designers intended - such a mandate would be pointless. >What we should do, however, is not produce standards that use other >standards incorrectly, or misunderstand their applicability. These proposals >are essentially describing an alternative architectural model for SIP, one >that is not friendly to the architecture in the SIP specification. In this >strawman version of SIP, it might appear that ENUM provides capabilities >that SIP lacks and desperately needs. But from my vantage that need is >illusory. Let's not standardize a way of using ENUM and SIP together that >makes assumptions contrary to the way SIP can and does work. > >Jon Peterson >NeuStar, Inc. Hi Jon, folks, First, congrats. Second, are you speaking Ex Cathedra here? (Particularly the last sentence) all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 18:17:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18031 for ; Thu, 6 Mar 2003 18:17:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26NTCn25749 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 18:29:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NT9O25744; Thu, 6 Mar 2003 18:29:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26NPFO25627 for ; Thu, 6 Mar 2003 18:25:15 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17892 for ; Thu, 6 Mar 2003 18:13:30 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 06 Mar 2003 04:52:47 -0500 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt From: Michael Mealling To: "Peterson, Jon" Cc: "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" , enum@ietf.org, "'rudis@brandner-web.de'" In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1046992509.11302.226.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 18:15:09 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 16:47, Peterson, Jon wrote: > I wanted to make some comments about this issue. > From my perspective, this discussion is really not about ENUM at all. > ENUM is a system for transforming one kind of identifier into another > kind of identifier. Correct... > This is a question about how SIP is used. The > problem is that you describe a scenario below for the usage of SIP in > which it is preferable for users to have multiple identifiers for a > target, each of which is associated with a different capability or > service - it really doesn't matter whether these identifiers were > acquired from ENUM, from a web page, or wherever. The only important > point is that SIP is not a protocol that profits from having multiple > identifiers sorted by the capabilities associated with these > identifiers. One of the primary purposes of SIP is to due away with > the need to learn multiple identifiers for a particular user - this > is the whole point of dynamic registration, forking, presence and > many of SIP's other virtues. > > When your argument is predicated on a benefit that SIP user agent > clients will derive from holding multiple identifiers for a target > that each represent a different service or capability, this shows up > to SIP people as a misunderstanding. SIP user agents would not > benefit from this, and in fact, there are ways in which it seems > obviously detrimental. It is moreover not how most SIP user agents > operate - they assume that you plug in a single URI and let SIP take > care of the rest. I think this is where the misunderstanding is coming in. You are incorrectly assuming we are talking about a SIP user agent in its fullest sense when what we are talking about is a user agent that does other things better. It isn't a fully compliant SIP user agent. Its implementation of SIP would be only what is required to accomplish one single task (voice, or IM, not both). > there is no argument with them> > > We shouldn't try to mandate that implementers and users cannot use > SIP is ways other than its designers intended - such a mandate would > be pointless. What we should do, however, is not produce standards > that use other standards incorrectly, or misunderstand their > applicability. The point is not that SIP is being misunderstood. Everyone knows full well that SIP is meant to hide other identifiers this way. We know that. But we're coming from a world where SIP is not and probably never will be widely adopted for the simple reason that it just doesn't do what's needed. > These proposals are essentially describing an > alternative architectural model for SIP, one that is not friendly to > the architecture in the SIP specification. We're not describing an alternative architectural model for SIP. We're describing an architectural model for something wholly and completely different but which allows someone to use a SIP connection as a tunnel for that application. Its like suggesting that since web browsers can handle gopher: URLs that HTTP is redefining the gopher architectural model. > In this strawman version > of SIP, it might appear that ENUM provides capabilities that SIP > lacks and desperately needs. But from my vantage that need is > illusory. Let's not standardize a way of using ENUM and SIP together > that makes assumptions contrary to the way SIP can and does work. Again, we're not attempting to standardize any behavior for SIP. What we're after is something more than SIP or any particular protocol. It just so happens that you can use SIP with it. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 19:06:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20278 for ; Thu, 6 Mar 2003 19:06:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h270HLp30759 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 19:17:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270HJO30754; Thu, 6 Mar 2003 19:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h270GXO30711 for ; Thu, 6 Mar 2003 19:16:33 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20222 for ; Thu, 6 Mar 2003 19:04:47 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2706IC27870; Fri, 7 Mar 2003 00:06:18 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 19:06:24 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EC9@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" Cc: enum@ietf.org, "'rudis@brandner-web.de'" Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Thu, 6 Mar 2003 19:06:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Thanks Mr. Conroy, and you are quite correct to ask - I should clarify that I am not speaking here as Transport-Area-Director-elect, or something, but just as a working group participant. The transition is slated to occur in the middle of the SF IETF meeting (after ENUM meets, incidentally). Even afterwards, I wouldn't expect to be seeing ex cathedra pronouncements from me here anytime soon. That much said, I do think that last sentence of mine cited below is good advice. I think it would be inadvisable to base enumservices for any IETF protocols on assumptions that are incompatible with their respective specifications. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Thursday, March 06, 2003 2:30 PM > To: Peterson, Jon; 'Brandner Rudolf'; 'jh@lohi.eng.song.fi' > Cc: enum@ietf.org; 'rudis@brandner-web.de' > Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt > > > At 4:47 pm -0500 6/3/03, Peterson, Jon wrote: > >I wanted to make some comments about this issue. > > > > >We shouldn't try to mandate that implementers and users > cannot use SIP is > >ways other than its designers intended - such a mandate > would be pointless. > >What we should do, however, is not produce standards that use other > >standards incorrectly, or misunderstand their applicability. > These proposals > >are essentially describing an alternative architectural > model for SIP, one > >that is not friendly to the architecture in the SIP > specification. In this > >strawman version of SIP, it might appear that ENUM provides > capabilities > >that SIP lacks and desperately needs. But from my vantage > that need is > >illusory. Let's not standardize a way of using ENUM and SIP > together that > >makes assumptions contrary to the way SIP can and does work. > > > >Jon Peterson > >NeuStar, Inc. > > Hi Jon, folks, > First, congrats. > Second, are you speaking Ex Cathedra here? > (Particularly the last sentence) > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 20:09:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22511 for ; Thu, 6 Mar 2003 20:09:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271L0R02824 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 20:21:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KwO02816; Thu, 6 Mar 2003 20:20:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271IxO02579 for ; Thu, 6 Mar 2003 20:18:59 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22404 for ; Thu, 6 Mar 2003 20:07:11 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 01:09:15 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8ANSW; Fri, 7 Mar 2003 01:09:10 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" , richard.stastny@oefeg.at Cc: enum@ietf.org, "'rudis@brandner-web.de'" , Richard@stastny.com Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EC9@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EC9@stntexch2.va.neustar.com> Date: Fri, 7 Mar 2003 01:09:04 +0000 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, Folks, Mr. Conroy? - Ouch! Thanks; I guessed that but it needed to be said. Re. Last sentence - yup, agreed; trying to break any protocol with any enumservice spec is wrong. Whether or not draft-brandner-enumservice-vovi-00.txt is incompatible with the SIP spec is a question - I don't think so as I use SIP and ENUM entries like this, so we must have not phrased it correctly :( I'm not REQUIRED to use a single AoR, no more than I need a single email address. I COULD use a single email address and filter/redirect according to my policies. However, I choose to use two different accounts - one for basic emails that will get SMS'd to me and the other for "normal" email (i.e. the stuff telling me that I can add 3 inches in a week, ...). Nowhere in the draft was it ever intended that folk MUST use these enumservices for their SIP URIs. If folk want to use a single SIP service, fine. (Nor does it say or imply that in ETSI TS102 172). Heck, folk can even use a single 'h323' enumservice of it gets them through the night. Re. stating that DNS is not the place to to put highly dynamic information; we had thought, in the immortal words of John Cleese and Connie Booth, that that was "stating the bleedin' obvious". However, we can put that into the drafts if it helps. Note that the URIs we had ASSUMED that folk would put into ENUM would be AoRs, not transient contact addresses - that's a idea that simply hadn't occurred to me people would even consider. Again, we can add text that says that you shouldn't avoid a SIP Registration by putting a SIP contact URI in it. That, of course, doesn't stop really determined folk putting IP addresses and SRV records into their ENUM domains, but the A record is always with us (or the AAAA, or ...). Seems to me that the confusion here is a great deal of assumption on what this simple draft is actually saying, and my lack of understanding of the odd things folk might think of doing with it. We can spell out these things in the next turn - we're in blackout now so it won't be out until after SF. all the best, Lawrence At 7:06 pm -0500 6/3/03, Peterson, Jon wrote: >Thanks Mr. Conroy, and you are quite correct to ask - I should clarify that >I am not speaking here as Transport-Area-Director-elect, or something, but >just as a working group participant. The transition is slated to occur in >the middle of the SF IETF meeting (after ENUM meets, incidentally). Even >afterwards, I wouldn't expect to be seeing ex cathedra pronouncements from >me here anytime soon. > >That much said, I do think that last sentence of mine cited below is good >advice. I think it would be inadvisable to base enumservices for any IETF >protocols on assumptions that are incompatible with their respective >specifications. > >Jon Peterson >NeuStar, Inc. > > > >> >We shouldn't try to mandate that implementers and users >> cannot use SIP is >> >ways other than its designers intended - such a mandate >> would be pointless. >> >What we should do, however, is not produce standards that use other >> >standards incorrectly, or misunderstand their applicability. >> These proposals >> >are essentially describing an alternative architectural >> model for SIP, one >> >that is not friendly to the architecture in the SIP >> specification. In this >> >strawman version of SIP, it might appear that ENUM provides >> capabilities >> >that SIP lacks and desperately needs. But from my vantage >> that need is >> >illusory. Let's not standardize a way of using ENUM and SIP >> together that >> >makes assumptions contrary to the way SIP can and does work. >> > >> >Jon Peterson >> >NeuStar, Inc. >> >> Hi Jon, folks, >> First, congrats. >> Second, are you speaking Ex Cathedra here? >> (Particularly the last sentence) > > >> all the best, >> Lawrence >> -- >> -------------------------------------------------------------- >> --------- >> Roke Manor Research : This information is provided "as is" >> and is not >> : intended to create any contractual or legal >> : relationship. >> -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 20:09:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22538 for ; Thu, 6 Mar 2003 20:09:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271L5002883 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 20:21:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271L5O02878; Thu, 6 Mar 2003 20:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271KRO02673 for ; Thu, 6 Mar 2003 20:20:27 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22430 for ; Thu, 6 Mar 2003 20:08:39 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2719fC28524; Fri, 7 Mar 2003 01:09:41 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 20:09:47 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214ECB@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Mealling'" Cc: "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" , enum@ietf.org, "'rudis@brandner-web.de'" Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Thu, 6 Mar 2003 20:09:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Mealling [mailto:michael@neonym.net] > Sent: Thursday, March 06, 2003 3:15 PM > To: Peterson, Jon > Cc: 'Brandner Rudolf'; 'jh@lohi.eng.song.fi'; enum@ietf.org; > 'rudis@brandner-web.de' > Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt > [snip] > > > > When your argument is predicated on a benefit that SIP user agent > > clients will derive from holding multiple identifiers for a target > > that each represent a different service or capability, this shows up > > to SIP people as a misunderstanding. SIP user agents would not > > benefit from this, and in fact, there are ways in which it seems > > obviously detrimental. It is moreover not how most SIP user agents > > operate - they assume that you plug in a single URI and let SIP take > > care of the rest. > > I think this is where the misunderstanding is coming in. You are > incorrectly assuming we are talking about a SIP user agent in its > fullest sense when what we are talking about is a user agent that does > other things better. It isn't a fully compliant SIP user agent. Its > implementation of SIP would be only what is required to accomplish one > single task (voice, or IM, not both). > Well, I don't necessarily think this was Mr. Brandner's example - he was speaking to a case in which a particular user had two SIP URIs, without reference to compliance of user agents, and whatnot. His problem seemed to have something to do with a purported inability to register URIs cross-domain. I would point out, though, that I think it is questionable to build our cases for SIP enumservices on the assumption that SIP user agents are not SIP-compliant. > > > there is no argument with them> > > > > We shouldn't try to mandate that implementers and users cannot use > > SIP is ways other than its designers intended - such a mandate would > > be pointless. What we should do, however, is not produce standards > > that use other standards incorrectly, or misunderstand their > > applicability. > > The point is not that SIP is being misunderstood. Everyone knows full > well that SIP is meant to hide other identifiers this way. We know that. > But we're coming from a world where SIP is not and probably never will > be widely adopted for the simple reason that it just doesn't do what's > needed. > Please do enlighten us then - but perhaps we should move this thread to SIP or SIPPING? I'm not really sure where this is going... certainly, if SIP is for whatever reason inadequate, I would welcome you to use another protocol of your choosing, or propose ways that we might improve SIP. I thought what we were trying to do in this thread was to discuss an enumservice appropriate for SIP URIs. I hope we'd all agree that an enumservice for SIP is not supposed to change the way SIP operates, right? What's being misunderstood by some, I suspect, is the justification for 'hiding' identifiers in SIP, and the material technical differences between doing so in SIP and doing so in ENUM (four of which I discussed in my last mail, and a fifth was mentioned by Mr. Heinanen). If you have no argument with the four points of mine, then hopefully we're on the same page that using multiple SIP identifiers in ENUM is problematic, and that there's no technical impediment to using a single identifier in ENUM. This is only point I was trying to establish, in response to Mr. Brandner's mail. > > These proposals are essentially describing an > > alternative architectural model for SIP, one that is not friendly to > > the architecture in the SIP specification. > > We're not describing an alternative architectural model for SIP. We're > describing an architectural model for something wholly and completely > different but which allows someone to use a SIP connection as a tunnel > for that application. Its like suggesting that since web browsers can > handle gopher: URLs that HTTP is redefining the gopher architectural > model. > Again, you're really losing me here. I agree that ENUM describes a generic architecture for converting TN numbers to URIs associated with particular protocols or services, and that is indeed broader than SIP. A particular device on which a SIP implementation resides may have many other applications that handle other sorts of protocols and services. None of this is being contested here, as far as I know. I thought we were talking about enumservices for SIP. I think I do understand your analogy in the last sentence, but I'm not sure it applies. I acknowledge that there is a 'service browser' concept for ENUM in circulation, and I don't necessarily have a problem with that idea per se. But concepts like "vovi" entail behavioral and architectural changes for SIP elements. They may make it harder to do SIP's job. I have no doubt that these same concepts are more applicable to other protocols. > > In this strawman version > > of SIP, it might appear that ENUM provides capabilities that SIP > > lacks and desperately needs. But from my vantage that need is > > illusory. Let's not standardize a way of using ENUM and SIP together > > that makes assumptions contrary to the way SIP can and does work. > > Again, we're not attempting to standardize any behavior for SIP. What > we're after is something more than SIP or any particular protocol. It > just so happens that you can use SIP with it. > I do hope that's what ENUM is after, yes. But that's not what Mr. Brandner's mail, or the vovi draft in so far as it relates to SIP, seemed to be speaking to. I certainly want ENUM to be able to use SIP, and vice versa, in a way that is profitable for both. Was there something we disagreed about, here? > -MM > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 6 21:30:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24734 for ; Thu, 6 Mar 2003 21:30:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h272fqc09112 for enum-archive@odin.ietf.org; Thu, 6 Mar 2003 21:41:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h272flO09107; Thu, 6 Mar 2003 21:41:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h272eAO09063 for ; Thu, 6 Mar 2003 21:40:10 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24694 for ; Thu, 6 Mar 2003 21:28:20 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h272U7j02970 for ; Thu, 6 Mar 2003 18:30:07 -0800 Message-Id: <5.2.0.9.2.20030306132945.0160ea40@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Mar 2003 13:29:59 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-ietf-vpim-routing-04.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI >To: IETF-Announce: ; >Cc: vpim@lists.neystadt.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-vpim-routing-04.txt >Date: Wed, 05 Mar 2003 06:32:57 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Voice Profile for Internet Mail Working >Group of the IETF. > > Title : Voice Message Routing Service > Author(s) : G. Vaudreuil > Filename : draft-ietf-vpim-routing-04.txt > Pages : 10 > Date : 2003-3-4 > >Voice messaging is traditionally addressed using telephone number >addressing. This document describes two techniques for routing voice >messages based on a telephone number. The VPIM Directory service >provides a directory mechanism to lookup a VPIM email address with a >telephone number and confirm that the address is both valid and the >associated with the intended recipient. However this service will >take time become widely deployed in the nearest term. This document >also describes a more limited send-and-pray service useful simply to >route and deliver messages using only the ENUM telephone number >resolution service and the existing DNS mail routing facilies. >Please send comments on this document to the VPIM working group >mailing list > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-vpim-routing-04.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-vpim-routing-04.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. >Content-Type: text/plain >Content-ID: <2003-3-4174603.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-vpim-routing-04.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 00:59:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00673 for ; Fri, 7 Mar 2003 00:59:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h276Awx07340 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 01:10:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h276AhO07331; Fri, 7 Mar 2003 01:10:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2766QO06294 for ; Fri, 7 Mar 2003 01:06:26 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00552 for ; Fri, 7 Mar 2003 00:54:33 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18rAqF-0007NK-00; Fri, 07 Mar 2003 07:56:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15976.13446.977603.135056@harjus.eng.song.fi> Date: Fri, 7 Mar 2003 07:56:22 +0200 To: "Conroy, Lawrence (SMTP)" Cc: "Peterson, Jon" , "'Brandner Rudolf'" , richard.stastny@oefeg.at, enum@ietf.org, "'rudis@brandner-web.de'" , Richard@stastny.com Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt In-Reply-To: References: <15A2739B7DAA624D8091C65981D7DA8101214EC9@stntexch2.va.neustar.com> X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Conroy, Lawrence (SMTP) writes: > Nowhere in the draft was it ever intended that folk MUST use these > enumservices for their SIP URIs. If folk want to use a single SIP > service, fine. (Nor does it say or imply that in ETSI TS102 172). may be so, but i was told that based on this draft, authorities in one european country had mandated the use of either voice or video service in SIP enum entries that correspond to phone numbers of that country. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 03:29:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14536 for ; Fri, 7 Mar 2003 03:29:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h278eh929801 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 03:40:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278eaO29793; Fri, 7 Mar 2003 03:40:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h278bMO29289 for ; Fri, 7 Mar 2003 03:37:22 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14459 for ; Fri, 7 Mar 2003 03:25:25 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h278QoC31905; Fri, 7 Mar 2003 08:26:50 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 03:26:58 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214ED5@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "'Brandner Rudolf'" , "'jh@lohi.eng.song.fi'" , richard.stastny@oefeg.at Cc: enum@ietf.org, "'rudis@brandner-web.de'" , Richard@stastny.com Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Fri, 7 Mar 2003 03:26:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Some notes inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Thursday, March 06, 2003 5:09 PM > To: Peterson, Jon; 'Brandner Rudolf'; 'jh@lohi.eng.song.fi'; > richard.stastny@oefeg.at > Cc: enum@ietf.org; 'rudis@brandner-web.de'; Richard@stastny.com > Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt > > > Hi Jon, Folks, > Mr. Conroy? - Ouch! I almost always address my colleagues in the IETF by their surnames on the mailing lists - no offense was intended. > Thanks; I guessed that but it needed to be said. > > Re. Last sentence - yup, agreed; trying to break any protocol with any > enumservice spec is wrong. > > Whether or not draft-brandner-enumservice-vovi-00.txt is incompatible > with the SIP spec is a question - I don't think so as I use SIP and > ENUM entries like this, so we must have not phrased it correctly :( > I do think there are cases where you can get into trouble with this, but I have no doubt that there are implementations in which SIP and ENUM entries are managed in the fashion of the "vovi" draft. Mr. Stasny demonstrated such at one of the prior IETFs, if memory serves. Unfortunately, there are implementations of a lot of technology that are well-meaning, and beneficial to users, but which still are not aligned with IETF standards. > I'm not REQUIRED to use a single AoR, no more than I need a single > email address. I COULD use a single email address and filter/redirect > according to my policies. However, I choose to use two different > accounts - one for basic emails that will get SMS'd to me and the > other for "normal" email (i.e. the stuff telling me that I can add > 3 inches in a week, ...). > Sure, though as an aside there's some question in the SIP case if there are more sophisticated policy instruments that can be applied to that problem than just keeping separate accounts. Rudi's case, anyway, seemed to be one where he wanted to be able to reach people with either voice and IM and was kind of foxed because of some constraint that prevented them from having a unified single service. I was further exploring that constraint. I have numerous SIP AoR's myself - I have one for FWD, one for iptel.org, etc. The underlying question here, though, for the "vovi" proposal is one of how my devices are associated with these AoRs, and what capabilities are available at each of these AoRs. > Nowhere in the draft was it ever intended that folk MUST use these > enumservices for their SIP URIs. If folk want to use a single SIP > service, fine. (Nor does it say or imply that in ETSI TS102 172). > Heck, folk can even use a single 'h323' enumservice of it gets > them through the night. > One concern is that if we publish multiple alternative SIP enumservices as standards, implementers will probably have no choice but to support all of them, with the different behaviors that would entail. Not the most desirable outcome, if we can come to a consensus on one method it would be preferable. I think Darwinism should be a last resort. > Re. stating that DNS is not the place to to put highly dynamic > information; we had thought, in the immortal words of John Cleese > and Connie Booth, that that was "stating the bleedin' obvious". > > However, we can put that into the drafts if it helps. > Glad we agree about that. But see below... > Note that the URIs we had ASSUMED that folk would put into ENUM > would be AoRs, not transient contact addresses - that's a idea > that simply hadn't occurred to me people would even consider. > > Again, we can add text that says that you shouldn't avoid a SIP > Registration by putting a SIP contact URI in it. > Well, while of course I think this is good counsel, I'm not sure it's really compatible with the "vovi" proposal as I understand it. The problem is that SIP AoRs don't have 'capability' as such - an AoR isn't a 'voice' AoR or 'video' AoR. A device that registers under an AoR has voice or video capabilities, and for the duration of the registration, those capabilities become available to user agents that send requests to the AoR. So, effectively, by saying that an AoR supports 'voice', you are assuming that some contact address representing a device that supports voice is permanently registered under it - but SIP assumes that registrations are not permanent in this way. URIs that represent devices (which are commonly used as contact addresses) do have these sorts of permanent capabilities, though - so I assumed you must be talking about them. Similarly, by provisioning that a URI has 'voice' capability in the DNS, you are putting that very 'highly dynamic information' about registrations in the DNS, as far as I can tell. > That, of course, doesn't stop really determined folk putting IP > addresses and SRV records into their ENUM domains, but the A record > is always with us (or the AAAA, or ...). Of course it won't stop people from doing the wrong thing. But our point here is to generate standards that recommend the right thing. People can and will implement all sorts of non-standard stuff anyway. > > Seems to me that the confusion here is a great deal of assumption > on what this simple draft is actually saying, and my lack of > understanding of the odd things folk might think of doing with it. > Please do let me know if I misunderstand the draft on any of the point above. > We can spell out these things in the next turn - we're in blackout > now so it won't be out until after SF. > > all the best, > Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 03:55:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15038 for ; Fri, 7 Mar 2003 03:55:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2797HQ31760 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 04:07:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2797GO31733; Fri, 7 Mar 2003 04:07:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27943O31297 for ; Fri, 7 Mar 2003 04:04:04 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14971 for ; Fri, 7 Mar 2003 03:52:06 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 7 Mar 2003 09:57:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DF030@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] draft-brandner-enumservice-vovi-00.txt Thread-Index: AcLkbtpa1YmBjnaUSnWbDuk86ApMXgAF1dTE From: "Stastny Richard" To: , "Conroy, Lawrence (SMTP)" Cc: "Peterson, Jon" , "Brandner Rudolf" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h27944O31298 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Conroy, Lawrence (SMTP) writes: > Nowhere in the draft was it ever intended that folk MUST use these > enumservices for their SIP URIs. If folk want to use a single SIP > service, fine. (Nor does it say or imply that in ETSI TS102 172). may be so, but i was told that based on this draft, authorities in one european country had mandated the use of either voice or video service in SIP enum entries that correspond to phone numbers of that country. -- juha Could you elaborate where you got this from? I as the rapporteur of the above mentioned document would be very interested to get the information which authorities MANDATED the use of voice:sip and as Lawrence stated above feel free to to use either voice:sip or sip. It is also clearly stated in ETSI TS 102 172 that a client shall look always FIRST for sip and then he may look for voice:sip or video:sip Also as chair of the Austrian ENUM Trial Platform would be interested to get information on this, because it is definitely not Austria which mandated this and I do not know any other trial sofar mandating something. So I object strongly to bring up rumors and hearsay in this dicussion. Maybe you misunderstood something. Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 04:01:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15190 for ; Fri, 7 Mar 2003 04:01:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h279DEP32454 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 04:13:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279DDO32449; Fri, 7 Mar 2003 04:13:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279AHO32356 for ; Fri, 7 Mar 2003 04:10:17 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15129 for ; Fri, 7 Mar 2003 03:58:19 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18rDi0-0007b4-00; Fri, 07 Mar 2003 11:00:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15976.24468.418398.904616@harjus.eng.song.fi> Date: Fri, 7 Mar 2003 11:00:04 +0200 To: "Stastny Richard" Cc: "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "Brandner Rudolf" , , , Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt In-Reply-To: <06CF906FE3998C4E944213062009F1620DF030@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF030@oefeg-s02.oefeg.loc> X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stastny Richard writes: > Conroy, Lawrence (SMTP) writes: > may be so, but i was told that based on this draft, authorities in one > european country had mandated the use of either voice or video service > in SIP enum entries that correspond to phone numbers of that country. > > -- juha > > Could you elaborate where you got this from? i heard it from a user of a proxy who asked to make a modification to the code to support it. i may have misunderstod the mandated part. he later told me that it was not actually mandated to use the voice thing, but that is was decided do so by the enum pilot participants. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 04:24:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15690 for ; Fri, 7 Mar 2003 04:24:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h279aEc01627 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 04:36:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279aCO01620; Fri, 7 Mar 2003 04:36:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h279XQO01296 for ; Fri, 7 Mar 2003 04:33:26 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15521 for ; Fri, 7 Mar 2003 04:21:29 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 7 Mar 2003 10:27:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DF034@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] draft-brandner-enumservice-vovi-00.txt Thread-Index: AcLkiH3tnV2mjKsQTOya7Vvk6ij6EAAAjSt6 From: "Stastny Richard" To: Cc: "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "Brandner Rudolf" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h279XQO01297 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Juha wrote: >i heard it from a user of a proxy who asked to make a modification to >the code to support it. i may have misunderstod the mandated part. he >later told me that it was not actually mandated to use the voice thing, >but that is was decided do so by the enum pilot participants. To which I reply: Aha, and there was also no "decision", because you me use both, as I said. We where just using voice:sip, voice:h323 (YES) and voice:tel, because we where using all three of them for VOICE services ONLY. BTW, we where also using fax:tel, sms:tel, etc. Since out trial is compatible with ETSI TS 102 172. one could also have used sip or h323 only, both provisioning system and all available clients are supporting this. So as I assumed, a misunderstanding. best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 07:27:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25486 for ; Fri, 7 Mar 2003 07:27:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Cd1919809 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 07:39:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CcxO19802; Fri, 7 Mar 2003 07:38:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CaoO18785 for ; Fri, 7 Mar 2003 07:36:50 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25140 for ; Fri, 7 Mar 2003 07:24:48 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 12:26:47 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8A3QD; Fri, 7 Mar 2003 12:26:45 -0000 From: "Conroy, Lawrence (SMTP)" To: Jon , Richard , Rudi Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 7 Mar 2003 12:26:40 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] VOVI draft 'voice:sip' enumservice Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, (Thread re-named - I assume that this is the issue ?) How does the enumservice 'voice:sip' in the vovi draft break SIP? I'm bemused, as it works for me - I've used it. My SIP hard 'phone is a single function device; it can be plugged in pretty much anywhere and registers itself with a SIP Service Provider. In the "real world", for some of the voice services provided, they expect to be paid. As Scott Petrack discovered, "the IETF doesn't do Business Relationships", so consider this an aside to explain why I have two service-specific accounts. My VirtualPC fires up and handles only IM - it doesn't have a microphone connected so it doesn't support RTC. It registers itself with another SIP Service Provider; this fine bunch don't have my credit card info. Until I can fathom out how to get a microphone and RTC working in VirtualPC, the capability of the device(s) behind this SIP registration is not going to change soon either. These *ARE* single function devices - whilst there are a lot of people "out there" with multi-function devices (e.g. .NET Messenger with RTC and IM support), those of us with hard 'phones have a defined service profile; this will not change short of re-flashing the 'phone. This is not a highly dynamic entry, at least not anytime soon. Note that even if I register several 'phones with the same AoR, they're all just voice terminals. I had thought that what goes into ENUM is the AoR, not the individual contact URIs. However, I've been convinced that a contact URI would work as well; I learn. Thus, if you try to IM to this 'phone, you will waste your time. It doesn't support T.38 so you can't fax to it - it just does voice. If I as a Registrant want to give a hint that you will only be successful if you do an INVITE with a voice media offer, then I can't see how this breaks SIP, or is even unhelpful. If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip', that's fine. Support for this enumservice consists solely of ignoring the hint and treating it as a standard 'sip' enumservice. Of course, anything to the account I have registered my 'phone with other than an INVITE with a voice media offer will be rejected . The 'phone fully supports 3261 but does not engage in all possible (non-media) sessions. It's a 'phone. Similarly, if anyone wants to try to INVITE my Virtual PC to a voice session, it will be rejected. It's also 3261 compliant, but only handles an IM session, due to my incompetence. Now, if anyone thinks that giving this hint is a BAD choice on the part of the registrant, that's a valid opinion, and there are many privacy issues with ENUM that we need to spell out (not just in this draft) so that folks can make informed choices on the information they publish. No-one is forced to publish information that they don't want the world to know - we have the 'I'm not telling you any more information here' enumservices as well. I still don't understand how this draft is not aligned with IETF standards, specifically 3261. I'm willing to believe that SIP with CallerPrefs could allow a client to negotiate a kind of service; I'm a little surprised that support for this is REQUIRED as the only solution if we're to avoid extended offer/rejection cycles. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 07:28:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25693 for ; Fri, 7 Mar 2003 07:28:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Ce6p20135 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 07:40:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ce6O20130; Fri, 7 Mar 2003 07:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CcsO19791 for ; Fri, 7 Mar 2003 07:38:54 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25382 for ; Fri, 7 Mar 2003 07:26:53 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 12:28:52 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8A3Q2; Fri, 7 Mar 2003 12:28:47 -0000 From: "Conroy, Lawrence (SMTP)" To: Rudi Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 7 Mar 2003 12:28:44 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] VOVI draft 'voice:sip' enumservice Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , FYI - sent already to your on the road account, enum, and the rest of the crowd. ---- Hi Folks, (Thread re-named - I assume that this is the issue ?) How does the enumservice 'voice:sip' in the vovi draft break SIP? I'm bemused, as it works for me - I've used it. My SIP hard 'phone is a single function device; it can be plugged in pretty much anywhere and registers itself with a SIP Service Provider. In the "real world", for some of the voice services provided, they expect to be paid. As Scott Petrack discovered, "the IETF doesn't do Business Relationships", so consider this an aside to explain why I have two service-specific accounts. My VirtualPC fires up and handles only IM - it doesn't have a microphone connected so it doesn't support RTC. It registers itself with another SIP Service Provider; this fine bunch don't have my credit card info. Until I can fathom out how to get a microphone and RTC working in VirtualPC, the capability of the device(s) behind this SIP registration is not going to change soon either. These *ARE* single function devices - whilst there are a lot of people "out there" with multi-function devices (e.g. .NET Messenger with RTC and IM support), those of us with hard 'phones have a defined service profile; this will not change short of re-flashing the 'phone. This is not a highly dynamic entry, at least not anytime soon. Note that even if I register several 'phones with the same AoR, they're all just voice terminals. I had thought that what goes into ENUM is the AoR, not the individual contact URIs. However, I've been convinced that a contact URI would work as well; I learn. Thus, if you try to IM to this 'phone, you will waste your time. It doesn't support T.38 so you can't fax to it - it just does voice. If I as a Registrant want to give a hint that you will only be successful if you do an INVITE with a voice media offer, then I can't see how this breaks SIP, or is even unhelpful. If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip', that's fine. Support for this enumservice consists solely of ignoring the hint and treating it as a standard 'sip' enumservice. Of course, anything to the account I have registered my 'phone with other than an INVITE with a voice media offer will be rejected . The 'phone fully supports 3261 but does not engage in all possible (non-media) sessions. It's a 'phone. Similarly, if anyone wants to try to INVITE my Virtual PC to a voice session, it will be rejected. It's also 3261 compliant, but only handles an IM session, due to my incompetence. Now, if anyone thinks that giving this hint is a BAD choice on the part of the registrant, that's a valid opinion, and there are many privacy issues with ENUM that we need to spell out (not just in this draft) so that folks can make informed choices on the information they publish. No-one is forced to publish information that they don't want the world to know - we have the 'I'm not telling you any more information here' enumservices as well. I still don't understand how this draft is not aligned with IETF standards, specifically 3261. I'm willing to believe that SIP with CallerPrefs could allow a client to negotiate a kind of service; I'm a little surprised that support for this is REQUIRED as the only solution if we're to avoid extended offer/rejection cycles. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 07:39:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26858 for ; Fri, 7 Mar 2003 07:39:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Coe721161 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 07:50:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CoeO21156; Fri, 7 Mar 2003 07:50:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CncO21047 for ; Fri, 7 Mar 2003 07:49:38 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26708 for ; Fri, 7 Mar 2003 07:37:37 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18rH8X-0007rq-00; Fri, 07 Mar 2003 14:39:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15976.37645.125030.167923@harjus.eng.song.fi> Date: Fri, 7 Mar 2003 14:39:41 +0200 To: "Conroy, Lawrence (SMTP)" Cc: Jon , Richard , Rudi , enum@ietf.org Subject: [Enum] VOVI draft 'voice:sip' enumservice In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit lawrence, > I still don't understand how this draft is not aligned with IETF > standards, specifically 3261. I'm willing to believe that SIP with > CallerPrefs could allow a client to negotiate a kind of service; > I'm a little surprised that support for this is REQUIRED as the only > solution if we're to avoid extended offer/rejection cycles. there are several sip ways to tell what capabilities my UA has. here is how my multifunction "phone" registers: REGISTER sip:sip.song.fi SIP/2.0 Via: SIP/2.0/UDP 195.10.149.20 CSeq: 26 REGISTER To: "Juha Heinanen" Expires: 0 From: "Juha Heinanen" Call-ID: 480602329@195.10.149.20 Content-Length: 0 User-Agent: KPhone/3.0 Event: registration Allow-Events: presence Contact: "Juha Heinanen" ;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK" the registration thus tells that the device supports invites and some other methods. i don't need to list that info in enum. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 08:00:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28451 for ; Fri, 7 Mar 2003 08:00:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27DCKv23194 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 08:12:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DCIO23189; Fri, 7 Mar 2003 08:12:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DBwO23168 for ; Fri, 7 Mar 2003 08:11:58 -0500 Received: from relay12.austria.eu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28348 for ; Fri, 7 Mar 2003 07:59:55 -0500 (EST) Received: from mah9.eunet.at (unknown [81.223.16.194]) by relay12.austria.eu.net (Postfix) with ESMTP id 45912C410F; Fri, 7 Mar 2003 14:01:48 +0100 (CET) Message-Id: <5.2.0.9.2.20030307135851.0327cff0@pop.eunet.at> X-Sender: peu89005@pop.eunet.at X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Mar 2003 14:01:46 +0100 To: jh@lohi.eng.song.fi, "Conroy, Lawrence (SMTP)" From: Michael Haberler Subject: Re: [Enum] VOVI draft 'voice:sip' enumservice Cc: Jon , Richard , Rudi , enum@ietf.org In-Reply-To: <15976.37645.125030.167923@harjus.eng.song.fi> References: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-7CC15B3F; boundary="=======4A097CE7=======" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --=======4A097CE7======= Content-Type: text/plain; x-avg-checked=avg-ok-7CC15B3F; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit sorry for the stupid question, but: Is ENUM intended to resolve only into SIP endpoints and SIP controlled services? If yes, Juha has a point, but then I dont see it that way educate me -Michael At 14:39 07.03.2003 +0200, jh@lohi.eng.song.fi wrote: >lawrence, > > > I still don't understand how this draft is not aligned with IETF > > standards, specifically 3261. I'm willing to believe that SIP with > > CallerPrefs could allow a client to negotiate a kind of service; > > I'm a little surprised that support for this is REQUIRED as the only > > solution if we're to avoid extended offer/rejection cycles. > >there are several sip ways to tell what capabilities my UA has. here is >how my multifunction "phone" registers: > >REGISTER sip:sip.song.fi SIP/2.0 >Via: SIP/2.0/UDP 195.10.149.20 >CSeq: 26 REGISTER >To: "Juha Heinanen" >Expires: 0 >From: "Juha Heinanen" >Call-ID: 480602329@195.10.149.20 >Content-Length: 0 >User-Agent: KPhone/3.0 >Event: registration >Allow-Events: presence >Contact: "Juha Heinanen" >;methods="INVITE, MESSAGE, INFO, >SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK" > >the registration thus tells that the device supports invites and some >other methods. i don't need to list that info in enum. > >-- juha > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum --=======4A097CE7=======-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 08:48:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01667 for ; Fri, 7 Mar 2003 08:48:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27DxcJ26622 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 08:59:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DxZO26617; Fri, 7 Mar 2003 08:59:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DwaO26585 for ; Fri, 7 Mar 2003 08:58:36 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01649 for ; Fri, 7 Mar 2003 08:46:32 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 13:48:35 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8A3W5; Fri, 7 Mar 2003 13:48:32 -0000 From: "Conroy, Lawrence (SMTP)" To: Michael Haberler , jh@lohi.eng.song.fi Cc: Jon , Richard , Rudi , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.2.0.9.2.20030307135851.0327cff0@pop.eunet.at> References: <5.2.0.9.2.20030307135851.0327cff0@pop.eunet.at> Date: Fri, 7 Mar 2003 13:48:28 +0000 Subject: Re: [Enum] VOVI draft 'voice:sip' enumservice Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Michael, Juha, Folks, This is a SIPPING issue, so I mention it only in passing on the ENUM list; we seem to be having confusion over 'Service' or even 'Method' versus 'Teleservice'. I suggest that SIPPING is the list for discussions on how a SIP Registrant AND a SIP Caller can specify the ->Teleservices<- they support or in which they want to engage. Let's just take it as read that they can by some means. As for whether or not ENUM is intended only for resolution to SIP endpoints (or intermediaries that support/hide the end point): Unless I'm instructed that this is the case, I don't see that. We have tel: URIs in several of the enumservices. These might end up as SIP end points (or H323 ones), but they may not. The GSTN is still working, and "steam phones" or handys may end up as ENUM-published targets. Thus the re-name for this thread - I ASSUME that the issue is only with whether or not 'voice:sip' or 'video:sip' breaks SIP or is unusable/unhelpful. If anyone thinks that the other parts of the drafts will not work, please holler. all the best, Lawrence At 2:01 pm +0100 7/3/03, Michael Haberler wrote: >sorry for the stupid question, but: > >Is ENUM intended to resolve only into SIP endpoints and SIP >controlled services? >If yes, Juha has a point, but then I dont see it that way >educate me > >-Michael > At 14:39 07.03.2003 +0200, jh@lohi.eng.song.fi wrote: -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 11:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13606 for ; Fri, 7 Mar 2003 11:16:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GS1j09142 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 11:28:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GRwO09134; Fri, 7 Mar 2003 11:27:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GQQO09030 for ; Fri, 7 Mar 2003 11:26:26 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13418 for ; Fri, 7 Mar 2003 11:14:21 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h27GG8j07725 for ; Fri, 7 Mar 2003 08:16:08 -0800 Message-Id: <5.2.0.9.2.20030307111003.0570eed0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 07 Mar 2003 11:16:02 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Questions Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A. I'm soooo glad we have a 2 1/2 hour slot in SF... B. The objections here are only to the vovi-00 text as it relates to SIP and presumably H.323. Correct? Granular descriptions as it might relate to tel are acceptable as in E2U+voice:tel ? C. Does the list see problems with similar constructs described in msg-00 or webft-00? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 7 13:22:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21478 for ; Fri, 7 Mar 2003 13:22:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27IXrX23613 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 13:33:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IXnO23607; Fri, 7 Mar 2003 13:33:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IUQO23455 for ; Fri, 7 Mar 2003 13:30:26 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21360 for ; Fri, 7 Mar 2003 13:18:18 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h27IKHC09572; Fri, 7 Mar 2003 18:20:17 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 13:20:25 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214ED9@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Questions Date: Fri, 7 Mar 2003 13:20:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > A. I'm soooo glad we have a 2 1/2 hour slot in SF... > Really? I would have thought a 20 minute meeting slot would be preferable from your perspective. ;) > B. The objections here are only to the vovi-00 text as it relates to SIP > and presumably H.323. Correct? > To SIP, anyway. I'll let the advocates of the E2U+h323 enumservice characterize their own position. > Granular descriptions as it might relate to tel are acceptable as in > E2U+voice:tel ? > No objection from me on these grounds. > C. Does the list see problems with similar constructs described in msg-00 > or webft-00? > No, not similar problems. As far as I'm concerned, the problems in this thread are specific to SIP enumservices. I think the authors of the former compendium draft made a good strategic decision by splitting these enumservices out into multiple drafts. I haven't really yet done enough analysis of msg-00 and webft-00, however, to say that there are or aren't unrelated concerns there. Jon Peterson NeuStar, Inc. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Mar 7 15:12:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27008 for ; Fri, 7 Mar 2003 15:12:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KOYo02972 for enum-archive@odin.ietf.org; Fri, 7 Mar 2003 15:24:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KOEO02948; Fri, 7 Mar 2003 15:24:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KMfO02857 for ; Fri, 7 Mar 2003 15:22:41 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26802 for ; Fri, 7 Mar 2003 15:10:29 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h27KCSC12716; Fri, 7 Mar 2003 20:12:29 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 15:12:36 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EDA@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Richard , Rudi Cc: enum@ietf.org Date: Fri, 7 Mar 2003 15:12:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Let me try to clear up a few things here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Friday, March 07, 2003 4:27 AM > To: Jon; Richard; Rudi > Cc: enum@ietf.org > Subject: VOVI draft 'voice:sip' enumservice > > > Hi Folks, > (Thread re-named - I assume that this is the issue ?) > The issue is with any enumservices that identify capabilities of SIP URIs, presumably for the benefit of some sort of SIP-based client. > How does the enumservice 'voice:sip' in the vovi draft break SIP? > I'm bemused, as it works for me - I've used it. > This is an important point. There is no question that there are numerous cases in which this enumservice could be deployed in which it will work, and break absolutely nothing. The most obvious is when it is the only SIP enumservice record in an ENUM resource record set, and the only device(s) you have just do voice and register at that URI. That is, if you have one record that identifies 'voice:sip', then when a client acquires it, provided it supports voice capability, it will place a request to the resulting URI, and everything works. One case in which this doesn't work (though there are others, some of which I've discussed earlier): if, for whatever reason, you boot up on IM client, and register it at your SIP address of record (the one represented by a 'voice:sip' record in ENUM), then your AoR now effectively has an IM capability, at least for the moment. If someone who only had SIP IM capability subsequently downloaded your ENUM record, though, they would not find an 'im:sip' record, and subsequently they would assume they are unable to contact you. This is breakage for SIP - when I register a device, I expect people to be able to reach it. The user would presumably also have to put an 'im:sip' record in the DNS when they register the IM device under their AoR in order for this ENUM-based capability negotiation scheme to work. Then we begin to get into the differences between real-time registrations and DNS publications, synchronization between SIP and ENUM, etc. The only way to rectify this for AoRs is to apply a policy contraint at a register than prevent registration of non-voice devices under the AoR identified by the 'voice:sip' enumservice. That seems unenforceable to me for several reasons, and even if it were enforceable it would also be breakage for SIP. The conclusion has to be that one cannot publish an AoR associated with a 'voice:sip' ENUM resource record; it has to be a contact address, not an AoR. And THAT is the real problem - the publication of contact addresses in ENUM. More on that below... > My SIP hard 'phone is a single function device; it can be plugged in > pretty much anywhere and registers itself with a SIP Service Provider. > In the "real world", for some of the voice services provided, they > expect to be paid. As Scott Petrack discovered, "the IETF doesn't do > Business Relationships", so consider this an aside to explain why I > have two service-specific accounts. > > My VirtualPC fires up and handles only IM - it doesn't have a microphone > connected so it doesn't support RTC. It registers itself with another > SIP Service Provider; this fine bunch don't have my credit card info. > Until I can fathom out how to get a microphone and RTC working in > VirtualPC, the capability of the device(s) behind this SIP registration > is not going to change soon either. > Again, I invite you to sign up for FWD or iptel.org, two free and painless SIP services that will accept whatever registrations you'd like. And thus I still don't understand why you need to have two service-specific accounts, why your devices for one capability need to register in one places, and devices for another capability need to register in another place. If you only -want- certain capabilities to be available at certain identifiers for you, that makes sense - but then, why put both identifiers in ENUM, and make them all available for everyone there? Either you want people to be able to reach these devices or not. The point being, your devices are not forced to register anywhere, and registrars are not rejecting cross-domain subscriptions, or something - and even if they were, you can just put both your AoRs under a single iptel.org AoR, if you want both to be available in SIP (go back to the first bullet point in my original mail in the thread for more about this). Obviously, this is orthogonal to whether or not your VirtualPC can support voice or not; there's no technical or policy impediment to registering both of your devices under a single AoR. > These *ARE* single function devices - whilst there are a lot of people > "out there" with multi-function devices (e.g. .NET Messenger with RTC > and IM support), those of us with hard 'phones have a defined service > profile; this will not change short of re-flashing the 'phone. This is > not a highly dynamic entry, at least not anytime soon. > I also have a hard phone, yes, and it is similarly just a phone. That's not a point of contention - there are single function devices in the world. The fact that there are multi-function devices is an important part of overall puzzle about the SIP enumservice, but is unrelated to the specific points we're discussing here. > Note that even if I register several 'phones with the same AoR, they're > all just voice terminals. I had thought that what goes into ENUM is the > AoR, not the individual contact URIs. However, I've been convinced that > a contact URI would work as well; I learn. > Right, now we're getting to the point - publishing contact URIs in ENUM is what you have to be doing in order for these URIs to have capability as such. It's also what I most vehemently oppose. The reasons that I am opposed this were the subject of my first mail in this thread (in which I presented four specific reasons why this is bad). If the authors of "vovi" really think that contact URIs should be published in ENUM (and I think you more or less have to be committed to this), I think at least those four bullet points need to be addressed, though they are not exhaustive. > Thus, if you try to IM to this 'phone, you will waste your time. It > doesn't support T.38 so you can't fax to it - it just does voice. If I > as a Registrant want to give a hint that you will only be successful if > you do an INVITE with a voice media offer, then I can't see how this > breaks SIP, or is even unhelpful. > > If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip', > that's fine. Support for this enumservice consists solely of ignoring > the hint and treating it as a standard 'sip' enumservice. Sure - in my problem case above, it might be tempting to say that when an application with a SIP IM capability looks at the ENUM resource records for SIP, it should be willing to try sending an IM to the 'voice:sip' entry. If you agree with that, though, then I think you basically agree with my proposal to have a 'sip' enumservice without any capability semantics. That hint is semantically disregarded by SIP applications. > > Of course, anything to the account I have registered my 'phone with other > than an INVITE with a voice media offer will be rejected . The 'phone > fully supports 3261 but does not engage in all possible (non-media) > sessions. It's a 'phone. > > Similarly, if anyone wants to try to INVITE my Virtual PC to a voice > session, it will be rejected. It's also 3261 compliant, but only handles > an IM session, due to my incompetence. > That's all true, yes. Of course, if you just registered the two at the same AoR, then attempts to contact you for either capability at that AoR would succeed. > Now, if anyone thinks that giving this hint is a BAD choice on the part > of the registrant, that's a valid opinion, and there are many privacy > issues with ENUM that we need to spell out (not just in this draft) so > that folks can make informed choices on the information they publish. > No-one is forced to publish information that they don't want the world > to know - we have the 'I'm not telling you any more information here' > enumservices as well. > Privacy is at least one other reason why publishing contact addresses in ENUM is undesirable, yes. Superficially, the concept of the hint isn't anathema to privacy, but since it entails publication of contact addresses it is troublesome. > I still don't understand how this draft is not aligned with IETF > standards, specifically 3261. I'm willing to believe that SIP with > CallerPrefs could allow a client to negotiate a kind of service; > I'm a little surprised that support for this is REQUIRED as the only > solution if we're to avoid extended offer/rejection cycles. > Service negotiation goes well beyond caller prefs, which as you surmise is not REQUIRED. See my previous note, especially the fourth bullet point, on why primitives like 'voice' aren't really suitable for SIP capability negotiation. Incidentally, in parallel forking cases that are likely when scanning multiple devices for a given capability, the offer/answer cycles occur simultaneously, and don't result in any appreciable delay. > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Mar 8 09:00:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17245 for ; Sat, 8 Mar 2003 09:00:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28ECK504295 for enum-archive@odin.ietf.org; Sat, 8 Mar 2003 09:12:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28EC5O04290; Sat, 8 Mar 2003 09:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28E6MO03427 for ; Sat, 8 Mar 2003 09:06:22 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16024 for ; Sat, 8 Mar 2003 08:53:46 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Mar 2003 13:55:51 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AQFH; Sat, 8 Mar 2003 13:55:47 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , Richard , Rudi on the road Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EDA@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EDA@stntexch2.va.neustar.com> Date: Sat, 8 Mar 2003 13:55:45 +0000 Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, folks, Thanks for the useful points - I think that they help to zero in on the problem - without which we can't fix it. Herewith my response - I apologise for quoting all of Jon's text below, but these ARE important points that should be read in conjunction. ============ I think that the key points here seems to be the use of contact addresses, and assumptions that there is some protocol feature required to check that an avowed Registrant policy is being enforced, and that the ENUM client MUST follow the hints published. My bad, as none of these these are intended in the VOVI draft. In the VOVI draft, there is NO protocol feature proposed or required of SIP. There is NO check that, if an end user says that this account is associated with RTC, all of the contacts represented by this AoR ARE capable of RTC. The end user can make a mistake or lie and register one kind of device "under" an account that they tell the world is actually associated with another kind of service. It seems (to me) perfectly valid for a SIP subscriber to choose to register an IM device, for example, under an account that, ->in ENUM<-, is shown as being associated with only voice teleservice. This means that SIP users (who have the URI already containing this AoR) may negotiate any supported session (including IM), whilst those using ENUM will normally only select this account if they intend to place a voice call. At the extreme, there is no compulsion on a Registrant to install a NAPTR referring to a particular SIP account at all; thus ENUM users won't use that account, whilst SIP users who have the AoR will continue to use it. IMHO, this doesn't break either SIP or ENUM. I assert that ENUM is a pure opt-in service and the Registrant is free to select the information they wish to publish in it (and the information they choose NOT to publish). SIP is no different from other information here. The label that a particular account and its AoR is associated with one kind of service is a hint that a Registrant MAY choose to put into ENUM, and that the querying program MAY choose to present to its end user or to act on if the end user has pre-specified their policy. The Registrant MAY instead choose NOT to give a hint that a particular subset of communication session types may be associated with a particular account and AoR; in this case they just use the "pure" sip enumservice. Apart from the hint the information presented is exactly the same. Similarly, the querying end user's program MAY choose to ignore a hint within a NAPTR and treat this as a standard SIP account capable of negotiating and initiating any communications session; they can treat this NAPTR as if it were a standard 'sip' enumservice. There is no compulsion here, either to publish a NAPTR with a hint as to the service expected from this account or to use this hint when receiving the NAPTR. Nothing is mandatory. It is equally possible for a determined Registrant to put a contact URI into either a NAPTR with 'sip' enumservice OR with a 'voice:sip' enumservice; it's dumb, but I trust we don't expect a DNS Service Provider to check somehow before publishing the domain data in DNS in these cases. ---- I agree that when an AoR is installed in a NAPTR it does not intrinsically have any teleservice capability associated with it. The teleservice capability of the end systems registered "behind" that AoR defines the communications session that may be negotiated via this account. I'm willing to believe that communication session type can be negotiated within the SIP process once it has begun, and that starting the SIP process can expose the teleservice capability of end units associated with an AoR in a controlled manner. I agree that if a particular account is associated with a set of end systems that have varying capability then the use of teleservice- specific hints associated with the AoR is inappropriate, due to the intrinsic latency in updating DNS and so the ENUM data being "out of date". However, for those cases where (i) an AoR is associated over the long term with a set of end systems that have only a single function, and (ii) the Registrant chooses to register only devices that have a specified teleservice capability under this particular AoR, then giving a hint to this capability within ENUM seems (to me) to be both possible and may be useful *TO A QUERYING END USER*. If a SIP UAC is all that will process ENUM data, then as pointed out there is little need for ENUM as the end user may have a SIP URI already, and any data in ENUM is intrinsically redundant. However, I suggest that there could be other programs that query, receive and process this information. The "Generic ENUM Client" is an example of a program that can process the returned results, possibly display them to an end user so that they select a particular option and so "break the tie" in the DDDS processing round, and then fire up the appropriate communications program with the resulting URI. That program may well be a SIP UAC; however, the SIP UAC will not have checked ENUM at all, as this has been done by an external ENUM client. In the specific case of a NAPTR with 'voice:sip' enumservice, it is possible for the Registrant to lie, indicating an account that only has devices registered "behind" the AOR that do not support voice. The end user's SIP UAC will fail in its attempts to initiate a voice call. Will the end user be unhappy? - possibly. Is this a protocol issue? - I don't think so. If it were, then we'd need protocol mechanisms to block someone putting an incorrect MX record or even an incorrect SOA record into DNS. Equally, we'd require a Telephone Service Provider to check that an entry in the White Pages that indicated a Fax machine really DID have a fax machine plugged in. It would seem that these applicability points are not clear in the current draft. Given that these can be spelled out in the "other information that the authors deem useful" section of the registration, is there still an objection on technical grounds (i.e. why won't it work?). ============ At 3:12 pm -0500 7/3/03, Peterson, Jon wrote: >Let me try to clear up a few things here. > >Jon Peterson >NeuStar, Inc. > >> -----Original Message----- >> From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] >> Sent: Friday, March 07, 2003 4:27 AM >> To: Jon; Richard; Rudi >> Cc: enum@ietf.org >> Subject: VOVI draft 'voice:sip' enumservice >> >> >> Hi Folks, >> (Thread re-named - I assume that this is the issue ?) >> > >The issue is with any enumservices that identify capabilities of SIP URIs, >presumably for the benefit of some sort of SIP-based client. > >> How does the enumservice 'voice:sip' in the vovi draft break SIP? >> I'm bemused, as it works for me - I've used it. >> > >This is an important point. There is no question that there are numerous >cases in which this enumservice could be deployed in which it will work, and >break absolutely nothing. The most obvious is when it is the only SIP >enumservice record in an ENUM resource record set, and the only device(s) >you have just do voice and register at that URI. That is, if you have one >record that identifies 'voice:sip', then when a client acquires it, provided >it supports voice capability, it will place a request to the resulting URI, >and everything works. > >One case in which this doesn't work (though there are others, some of which >I've discussed earlier): if, for whatever reason, you boot up on IM client, >and register it at your SIP address of record (the one represented by a >'voice:sip' record in ENUM), then your AoR now effectively has an IM >capability, at least for the moment. If someone who only had SIP IM >capability subsequently downloaded your ENUM record, though, they would not >find an 'im:sip' record, and subsequently they would assume they are unable >to contact you. This is breakage for SIP - when I register a device, I >expect people to be able to reach it. The user would presumably also have to >put an 'im:sip' record in the DNS when they register the IM device under >their AoR in order for this ENUM-based capability negotiation scheme to >work. Then we begin to get into the differences between real-time >registrations and DNS publications, synchronization between SIP and ENUM, >etc. > >The only way to rectify this for AoRs is to apply a policy contraint at a >register than prevent registration of non-voice devices under the AoR >identified by the 'voice:sip' enumservice. That seems unenforceable to me >for several reasons, and even if it were enforceable it would also be >breakage for SIP. > >The conclusion has to be that one cannot publish an AoR associated with a >'voice:sip' ENUM resource record; it has to be a contact address, not an >AoR. And THAT is the real problem - the publication of contact addresses in >ENUM. More on that below... > >> My SIP hard 'phone is a single function device; it can be plugged in >> pretty much anywhere and registers itself with a SIP Service Provider. >> In the "real world", for some of the voice services provided, they >> expect to be paid. As Scott Petrack discovered, "the IETF doesn't do >> Business Relationships", so consider this an aside to explain why I >> have two service-specific accounts. >> >> My VirtualPC fires up and handles only IM - it doesn't have a microphone >> connected so it doesn't support RTC. It registers itself with another >> SIP Service Provider; this fine bunch don't have my credit card info. >> Until I can fathom out how to get a microphone and RTC working in >> VirtualPC, the capability of the device(s) behind this SIP registration >> is not going to change soon either. >> > >Again, I invite you to sign up for FWD or iptel.org, two free and painless >SIP services that will accept whatever registrations you'd like. > >And thus I still don't understand why you need to have two service-specific >accounts, why your devices for one capability need to register in one >places, and devices for another capability need to register in another >place. If you only -want- certain capabilities to be available at certain >identifiers for you, that makes sense - but then, why put both identifiers >in ENUM, and make them all available for everyone there? Either you want >people to be able to reach these devices or not. > >The point being, your devices are not forced to register anywhere, and >registrars are not rejecting cross-domain subscriptions, or something - and >even if they were, you can just put both your AoRs under a single iptel.org >AoR, if you want both to be available in SIP (go back to the first bullet >point in my original mail in the thread for more about this). Obviously, >this is orthogonal to whether or not your VirtualPC can support voice or >not; there's no technical or policy impediment to registering both of your >devices under a single AoR. > >> These *ARE* single function devices - whilst there are a lot of people >> "out there" with multi-function devices (e.g. .NET Messenger with RTC >> and IM support), those of us with hard 'phones have a defined service >> profile; this will not change short of re-flashing the 'phone. This is >> not a highly dynamic entry, at least not anytime soon. >> > >I also have a hard phone, yes, and it is similarly just a phone. That's not >a point of contention - there are single function devices in the world. The >fact that there are multi-function devices is an important part of overall >puzzle about the SIP enumservice, but is unrelated to the specific points >we're discussing here. > >> Note that even if I register several 'phones with the same AoR, they're >> all just voice terminals. I had thought that what goes into ENUM is the >> AoR, not the individual contact URIs. However, I've been convinced that >> a contact URI would work as well; I learn. >> > >Right, now we're getting to the point - publishing contact URIs in ENUM is >what you have to be doing in order for these URIs to have capability as >such. It's also what I most vehemently oppose. The reasons that I am opposed >this were the subject of my first mail in this thread (in which I presented >four specific reasons why this is bad). If the authors of "vovi" really >think that contact URIs should be published in ENUM (and I think you more or >less have to be committed to this), I think at least those four bullet >points need to be addressed, though they are not exhaustive. > >> Thus, if you try to IM to this 'phone, you will waste your time. It >> doesn't support T.38 so you can't fax to it - it just does voice. If I >> as a Registrant want to give a hint that you will only be successful if >> you do an INVITE with a voice media offer, then I can't see how this >> breaks SIP, or is even unhelpful. >> >> If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip', >> that's fine. Support for this enumservice consists solely of ignoring >> the hint and treating it as a standard 'sip' enumservice. > >Sure - in my problem case above, it might be tempting to say that when an >application with a SIP IM capability looks at the ENUM resource records for >SIP, it should be willing to try sending an IM to the 'voice:sip' entry. If >you agree with that, though, then I think you basically agree with my >proposal to have a 'sip' enumservice without any capability semantics. That >hint is semantically disregarded by SIP applications. > >> >> Of course, anything to the account I have registered my 'phone with other >> than an INVITE with a voice media offer will be rejected . The 'phone >> fully supports 3261 but does not engage in all possible (non-media) >> sessions. It's a 'phone. >> >> Similarly, if anyone wants to try to INVITE my Virtual PC to a voice >> session, it will be rejected. It's also 3261 compliant, but only handles >> an IM session, due to my incompetence. >> > >That's all true, yes. Of course, if you just registered the two at the same >AoR, then attempts to contact you for either capability at that AoR would >succeed. > >> Now, if anyone thinks that giving this hint is a BAD choice on the part >> of the registrant, that's a valid opinion, and there are many privacy >> issues with ENUM that we need to spell out (not just in this draft) so >> that folks can make informed choices on the information they publish. >> No-one is forced to publish information that they don't want the world >> to know - we have the 'I'm not telling you any more information here' >> enumservices as well. >> > >Privacy is at least one other reason why publishing contact addresses in >ENUM is undesirable, yes. Superficially, the concept of the hint isn't >anathema to privacy, but since it entails publication of contact addresses >it is troublesome. > >> I still don't understand how this draft is not aligned with IETF >> standards, specifically 3261. I'm willing to believe that SIP with >> CallerPrefs could allow a client to negotiate a kind of service; >> I'm a little surprised that support for this is REQUIRED as the only >> solution if we're to avoid extended offer/rejection cycles. >> > >Service negotiation goes well beyond caller prefs, which as you surmise is >not REQUIRED. See my previous note, especially the fourth bullet point, on >why primitives like 'voice' aren't really suitable for SIP capability >negotiation. Incidentally, in parallel forking cases that are likely when >scanning multiple devices for a given capability, the offer/answer cycles >occur simultaneously, and don't result in any appreciable delay. > >> all the best, >> Lawrence >> -- >> -------------------------------------------------------------- >> --------- >> Roke Manor Research : This information is provided "as is" >> and is not >> : intended to create any contractual or legal >> : relationship. >> >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sat Mar 8 17:53:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28294 for ; Sat, 8 Mar 2003 17:53:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28N5Am12696 for enum-archive@odin.ietf.org; Sat, 8 Mar 2003 18:05:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28N4qO12677; Sat, 8 Mar 2003 18:04:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28N0SO12547 for ; Sat, 8 Mar 2003 18:00:28 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27317 for ; Sat, 8 Mar 2003 17:47:46 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Mar 2003 22:49:50 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AQKV; Sat, 8 Mar 2003 22:49:44 -0000 From: "Conroy, Lawrence (SMTP)" To: jon.peterson@neustar.biz, Rudi on the road , richard.stastny@oefeg.at Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sat, 8 Mar 2003 22:49:41 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] VOVI draft enumservice 'voice:sip' - and there's more Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, folks, I've put this as a separate posting as it has a different purpose and strictly may be out of scope for the IETF - it's just to explain why we bother with this enumservice, even though it is, apparently, contentious. Consider this scenario: A company has a mixed voice infrastructure with "steam 'phones", gateways, and SIP "hard phones", plus the Registrar/Proxy and firewall/ALG sub-systems. These are all under the administrative control of the Telecomms group in the Facilities department. None of the employees are allowed to register ANYTHING with this Proxy other than these SIP phones; to do so is treated as "Gross Industrial Misconduct". AoRs assigned to the 'phones and Registered with this Proxy are made available through the company's ENUM entries. Note - these are AoRs, NOT the contact addresses of the 'phones themselves. Such contact addresses would be of little use, as the 'phones are NATTED and visible to the "outside world" only via the ALG that is part of the voice infrastructure (and under control of the Telecomms group). The employees can use the I.T. department's proxy to register their SIP-based IM programs. These breach the firewall at a separate ALG (under the control of the I.T. department). The employees are assigned -separate- IM identities (AoRs) through the I.T. department Proxy/Registrar. Company rules do NOT allow employees to use company connections for voice or video calls other than those provided by the company and going through the Telecomms group systems. I agree that it is possible to combine more than one AoR at a third party SIP provider. However... Much as I've tried, it isn't easy to explain to I.T. departments that this is not a bad thing, and that potential incoming forking behaviour from external INVITEs is not a sign of a DoS attack - remember, these are the same folk that believed that being slashdotted was a sign of an intentional cyberattack, and pulled the plug. You might think that a strange reaction, but I couldn't possibly comment. Not only am I not a lawyer nor play one on TV, I am not a Personnel / Human Resources specialist, and do not understand the logic here - I take it as a given. Thus the company has personnel and I.T./Telecomms policies (not subject to any technical standardisation that I understand) that mean that the 'voice' account WILL only have voice capable devices associated with it. There are no protocol features involved in this, just the threat of dismissal if employees break the rules - IMHO, a pretty effective constraint. I suggest that this is not an uncommon scenario, and that indicating 'voice:sip' in the NAPTR holding an AoR "provided by the Telecomms group", with a separate NAPTR indicating 'im:sip' with an AoR "provided by the I.T. department" is valid and may be useful; if these ENUM records are presented to a human being, then they can select the entry accordingly. I'm sure I speak for all of the authors in agreeing that publishing SIP contact addresses in ENUM is a BAD and EVIL THING; to be honest I hadn't even considered it until it was mentioned as a possibility. In this example, all of the SIP URIs published in ENUM would be full AoRs. They would have an implied capability simply through the company's choice of systems configuration, and enforcement of policies. Finally, in the above scenario, the constraints are not technical but administrative and the reasons for two accounts are bureaucratic. I'm happy to explain to potential customers that they don't need this separation; I'm happy to show that they can probably same money with a combined system. The I.T. department might not have to deal with a W2K Server and ALG, or the Telecomms group might come to love W2K. However, I'm not in a position to tell a potential customer that they can't have a system that fits their bureaucratic designs just because it's unnecessary. At least in the Real World we now have web servers and file servers managed by the same group - things do change. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 9 01:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18284 for ; Sun, 9 Mar 2003 01:02:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h296EXr04976 for enum-archive@odin.ietf.org; Sun, 9 Mar 2003 01:14:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h296ESO04967; Sun, 9 Mar 2003 01:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2969FO04862 for ; Sun, 9 Mar 2003 01:09:15 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17275 for ; Sun, 9 Mar 2003 00:56:22 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h295wIC30758; Sun, 9 Mar 2003 05:58:22 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 00:58:28 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE1@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Richard , Rudi on the road Cc: enum@ietf.org Subject: RE: [Enum] RE: VOVI draft 'voice:sip' enumservice Date: Sun, 9 Mar 2003 00:58:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Quick summary: As far I can tell, you are not phased by the first bullet point from my original mail, in which I maintain that service-specific enumservices can obstruct communications attempts that should succeed - instead, you're suggesting that SIP be constrained in certain ways in the environment that "vovi" is deployed to prevent this from arising. Although your mail focuses more on AoRs than contact addresses, there is still a suggestion below that we should not counterindicate the appearance of device URIs in ENUM, even though you seem to agree with the substance of my second and third bullet points, which show why this would be problematic. I haven't seen any response of my fourth bullet point, which raises concerns about the granularity of concepts like 'voice' when compared with SIP capability negotiation. I think I've been able to substantiate ways in which these enumservices entail changes to SIP behavior. Finally, there are plenty of issues we haven't even begun to discuss, like the considerations surrounding multiservice clients, or privacy. I think there are still substantial technical objections on the table. More below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Saturday, March 08, 2003 5:56 AM > To: Peterson, Jon; Richard; Rudi on the road > Cc: enum@ietf.org > Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice > > > Hi Jon, folks, > Thanks for the useful points - I think that they help to zero > in on the problem - without which we can't fix it. > > Herewith my response - I apologise for quoting all of Jon's text > below, but these ARE important points that should be read in > conjunction. > > ============ > I think that the key points here seems to be the use of contact > addresses, and assumptions that there is some protocol feature > required to check that an avowed Registrant policy is being enforced, > and that the ENUM client MUST follow the hints published. My bad, as > none of these these are intended in the VOVI draft. > > In the VOVI draft, there is NO protocol feature proposed or required > of SIP. There is NO check that, if an end user says that this account > is associated with RTC, all of the contacts represented by this AoR > ARE capable of RTC. The end user can make a mistake or lie and > register one kind of device "under" an account that they tell the > world is actually associated with another kind of service. > It doesn't propose features for SIP, it (inadvertantly or no) entails them. Architecting a system in the way that the "vovi" draft suggests leaves you with little choice other than to make the sort of changes I was detailing, if you want the behavior of the system to be coherent. > It seems (to me) perfectly valid for a SIP subscriber to choose to > register an IM device, for example, under an account that, ->in > ENUM<-, is shown as being associated with only voice teleservice. > This means that SIP users (who have the URI already containing this > AoR) may negotiate any supported session (including IM), whilst those > using ENUM will normally only select this account if they intend to > place a voice call. > Valid in what sense? Surely not the sense 'desirable'. These enumservices obstruct attempts to communicate that would ordinarily succeed. > At the extreme, there is no compulsion on a Registrant to install a > NAPTR referring to a particular SIP account at all; thus ENUM users > won't use that account, whilst SIP users who have the AoR will > continue to use it. IMHO, this doesn't break either SIP or ENUM. I > assert that ENUM is a pure opt-in service and the Registrant is free > to select the information they wish to publish in it (and the > information they choose NOT to publish). SIP is no different from > other information here. > Nothing I disagree with here - but this doesn't seem to argue either way the matter at hand (the syntax of SIP-based enumservices). All of the above should be true regardless of what enumservices we choose to standardize. We both want ENUM and SIP to play together, the only question is what approach we adopt. > The label that a particular account and its AoR is associated with > one kind of service is a hint that a Registrant MAY choose to put > into ENUM, and that the querying program MAY choose to present to its > end user or to act on if the end user has pre-specified their policy. > Well, be careful here about that second MAY. I think ENUM and DDDS compel you to evaluate enumservices in a very specific way. Saying that the ENUM querying program MAY choose to present a service and URI to an end user or communications application is one thing - much more important is whether or not the application asks the user, before it queries ENUM, 'what kind of sessions are you looking for, enter one or more of of: voice, video, im?' or something. If you assume that you are only looking for voice, that leads to the restriction of options - the DDDS algorithm doesn't present the user with ENUM options for unsought enumservices. I take it you envision that your application will look only for some enumservices and not others (based on the capability of available communications applications) - if you envision otherwise, that's a DDDS compliance issue. > The Registrant MAY instead choose NOT to give a hint that a > particular subset of communication session types may be associated > with a particular account and AoR; in this case they just use the > "pure" sip enumservice. Apart from the hint the information presented > is exactly the same. If there were not mandatory DDDS behavior associated with it, I would be more comfortable calling the enumservice name a 'hint'. As it stands, it's a mandate. If I don't recognize or support the enumservice I can't use it. > > Similarly, the querying end user's program MAY choose to ignore a > hint within a NAPTR and treat this as a standard SIP account capable > of negotiating and initiating any communications session; they can > treat this NAPTR as if it were a standard 'sip' enumservice. > Well, the program doesn't 'ignore' hints - the DDDS algorithm tells the program how to evaluate enumservices. This is why it is significant how the enumservice string is strcutured, and what criteria the application uses to determine which enumservices are valid. I don't think applications are permitted by the ENUM standard to ignore the DDDS rules. > There is no compulsion here, either to publish a NAPTR with a hint as > to the service expected from this account or to use this hint when > receiving the NAPTR. Nothing is mandatory. > Again, there is a compulsion to use the hint when receiving the NAPTR, as I've said. There are plenty of mandatory statements in RFC340x and rfc2916bis to this effect. > It is equally possible for a determined Registrant to put a contact > URI into either a NAPTR with 'sip' enumservice OR with a 'voice:sip' > enumservice; it's dumb, but I trust we don't expect a DNS Service > Provider to check somehow before publishing the domain data in DNS in > these cases. > Well, I agree with you there. It is within our power, however, to recommend in IETF standards that users do not put contact addresses for SIP into ENUM. The "vovi" proposal, as far as I can tell, entails that contact addresses are used (or, worse, constraints are applied to SIP). It would seem to be a strong recommendation in the opposite direction. I would prefer that we not put device-specific URIs in the DNS, and I have offered significant arguments to the contrary, arguments which, again, I do not think are contested here. > ---- > > I agree that when an AoR is installed in a NAPTR it does not > intrinsically have any teleservice capability associated with it. The > teleservice capability of the end systems registered "behind" that > AoR defines the communications session that may be negotiated via > this account. > > I'm willing to believe that communication session type can be > negotiated within the SIP process once it has begun, and that > starting the SIP process can expose the teleservice capability of end > units associated with an AoR in a controlled manner. > > I agree that if a particular account is associated with a set of end > systems that have varying capability then the use of teleservice- > specific hints associated with the AoR is inappropriate, due to the > intrinsic latency in updating DNS and so the ENUM data being "out of > date". > > However, for those cases where (i) an AoR is associated over the long > term with a set of end systems that have only a single function, and > (ii) the Registrant chooses to register only devices that have a > specified teleservice capability under this particular AoR, then > giving a hint to this capability within ENUM seems (to me) to be both > possible and may be useful *TO A QUERYING END USER*. > Well, here's the thing. As I said in my original note, "vovi" works when you have one SIP enumservice in your ENUM resource record set expressing one capability - I'm not questioning that. Whether or not it's actually more beneficial to the end user than using the 'sip' enumservice, however, is arguable, since if there were one 'sip' enumservice in stead of one 'voice:sip' enumservice, then the same behavior would result (i.e. you only get back one record, and you use it). In the single record case it is no more useful to a querying user as far as I can see, and possibly less useful if the querying user would rather communicate in some other way, and the "vovi" record erroneously suggests that it would not be possible. But anyway, the real problems arise when you have multiple ENUM resource records containing SIP URIs, especially when they're advertising different capabilities. This was the thrust of my argument and objections in my previous note. This was the use-case that Rudi brought to the table that sparked this thread (one AoR for 'voice', one for 'im'). I think this is where the 'value' in having service-specific enumservices arises, and it's also where you start to have problems. Moreover, I think that in order for the 'voice:sip' enumservice not to cause problems, the constraints (i) or (ii) above need to be enforced somehow, and this is a SIP behavioral change. It's not enough that you say an AoR tends, over the long term, to have UAs with only one capability registered under it. That's true of my FWD AoR, but I might decide to register IM there at any moment, and quite fleetingly. The point is that these enumservices constrain user behavior for SIP registrations, and either users have to remember that they are so constrained, or that constraint needs to be enforced programmatically by SIP registrars. Both seem unnecessarily inflexible to me, especially given the presence of an alternative that does not require this (i.e. the 'sip' enumservice). No matter how you slice it, this entails changes to SIP behavior because of the choice of enumservice. > If a SIP UAC is all that will process ENUM data, then as pointed out > there is little need for ENUM as the end user may have a SIP URI > already, and any data in ENUM is intrinsically redundant. > Well, no. ENUM lets you turn a telephone number in to a URI - if you're SIP-capable, then potentially into a SIP URI. That's a tremendous value, and there's plenty of need for ENUM. Having a telephone number doesn't give you any idea how to reach a resource on the Internet. That is the problem that ENUM solves, and it's a very important problem. So I don't think that just because SIP shouldn't use ENUM to negotiate service-specific capabilities, ENUM is somehow useless to SIP. That much said, I agree that the redundancy of provisioning contact addresses in ENUM and provisioning contact addresses in SIP would be troublesome, though, for many reasons given in my original note. > However, I suggest that there could be other programs that query, > receive and process this information. The "Generic ENUM Client" is an > example of a program that can process the returned results, possibly > display them to an end user so that they select a particular option > and so "break the tie" in the DDDS processing round, and then fire up > the appropriate communications program with the resulting URI. > Right, I understand the application you have in mind, I think. I'd refer you to rfc2916bis-04 section 2.6, just to make sure we're on the same page about how DDDS works, especially regarding tie-breaking. Your concept is allowed by 2.6 in my reading, though with some important caveats. > That program may well be a SIP UAC; however, the SIP UAC will not > have checked ENUM at all, as this has been done by an external ENUM > client. Sure, the resolver may be discrete from any particular communications application. bis section 2.6 discusses this as well. > > In the specific case of a NAPTR with 'voice:sip' enumservice, it is > possible for the Registrant to lie, indicating an account that only > has devices registered "behind" the AOR that do not support voice. > The end user's SIP UAC will fail in its attempts to initiate a voice > call. Sounds more like a mistake than a lie. But agreed that this is possible; this is a less-harmful corollary of the problem I brought up in my previous mail. > Will the end user be unhappy? - possibly. Is this a protocol issue? - > I don't think so. If it were, then we'd need protocol mechanisms to > block someone putting an incorrect MX record or even an incorrect SOA > record into DNS. Equally, we'd require a Telephone Service Provider > to check that an entry in the White Pages that indicated a Fax > machine really DID have a fax machine plugged in. > Misprovisioning problems that are comparable to bad MX records and whatnot exist irrespective of enumservices. I can mistype a URI for SIP, leading to a nonsensical result, whether I use 'voice:sip' or 'sip' as my enumservice. I don't think this helps to decide between the two enumservice alternatives in any way. Anyway, my version of this problem (in which an IM client registers under an AoR attributed to a 'voice:sip' ENUM record) is a protocol issue created by the 'voice:sip' enumservice that does not exist for the 'sip' enumservice. I don't think it's really comparable to this. This would be more like if you had MX records that were specific to the capability of some mail client (like Eudora versus Outlook) and insisted that you'd make sure somehow that people only used the right client to retrieve emails. > It would seem that these applicability points are not clear in the > current draft. Given that these can be spelled out in the "other > information that the authors deem useful" section of the > registration, is there still an objection on technical grounds (i.e. > why won't it work?). > Unfortunately, from my perspective, you haven't answered my objections by a long shot, and I don't see any easy path to addressing them for "vovi". I don't think an applicability statement could resolve this concern. See the summary at the start of the mail. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 9 01:05:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18900 for ; Sun, 9 Mar 2003 01:05:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h296HoZ05050 for enum-archive@odin.ietf.org; Sun, 9 Mar 2003 01:17:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h296HoO05045; Sun, 9 Mar 2003 01:17:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h296D0O04920 for ; Sun, 9 Mar 2003 01:13:00 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17929 for ; Sun, 9 Mar 2003 01:00:07 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h29629C30825; Sun, 9 Mar 2003 06:02:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 01:02:20 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE2@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Rudi on the road , richard.stastny@oefeg.at Cc: enum@ietf.org Date: Sun, 9 Mar 2003 01:02:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: VOVI draft enumservice 'voice:sip' - and there's more Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Some more below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Saturday, March 08, 2003 2:50 PM > To: jon.peterson@neustar.biz; Rudi on the road; > richard.stastny@oefeg.at > Cc: enum@ietf.org > Subject: VOVI draft enumservice 'voice:sip' - and there's more > > > Hi Jon, folks, > I've put this as a separate posting as it has a different purpose and > strictly may be out of scope for the IETF - it's just to explain why we > bother with this enumservice, even though it is, apparently, > contentious. > > Consider this scenario: > A company has a mixed voice infrastructure with "steam 'phones", gateways, > and SIP "hard phones", plus the Registrar/Proxy and firewall/ALG sub-systems. > These are all under the administrative control of the Telecomms group in the > Facilities department. > > None of the employees are allowed to register ANYTHING with this Proxy other > than these SIP phones; to do so is treated as "Gross Industrial Misconduct". > I wonder about what this policy is supposed to accomplish, but we'll return to that later. > AoRs assigned to the 'phones and Registered with this Proxy are made available > through the company's ENUM entries. Note - these are AoRs, NOT the contact > addresses of the 'phones themselves. Such contact addresses would be of > little use, as the 'phones are NATTED and visible to the "outside world" > only via the ALG that is part of the voice infrastructure (and under > control of the Telecomms group). > As an aside, I'd draw your attention to the considerable amount of work that has been done recently on the SIP concept of 'globally routable contact addresses'. These are needed for numerous conferences and transfer-control applications when devices use private IP address space. Anyway, just because a phone has been NAT'd does not mean that its contact addresses are of no use. These GRCA systems allow a lot of control to proxy operators, etc, and are probably a good solution to problems along these lines. > The employees can use the I.T. department's proxy to register their > SIP-based IM programs. These breach the firewall at a separate ALG > (under the control of the I.T. department). The employees are assigned > -separate- IM identities (AoRs) through the I.T. department Proxy/Registrar. > Company rules do NOT allow employees to use company connections for voice > or video calls other than those provided by the company and going through > the Telecomms group systems. > Deep in this is the capital-"P" Problem that I suspect has motivated a lot of the confusion about the need for these enumservices. Let's grant the AoR for Telecomms for a particular user is 'alice@atlanta.com', and their AoR for I.T. is 'amr@it.atlanta.com'. Two different AoRs, as you say. You say that company rules do not allow employees to use connections other than those provided by the company. Fine. It is, however, possible to register the AoR 'alice@atlanta.com' as a contact address under 'amr@it.atlanta.com'. Astonishingly enough, the Telecomms proxy would not even be able to distinguish whether a SIP request for 'alice@atlanta.com' had gone through the IT proxy or not (unless IT had some out-of-band way of notifying Telecomms of this, say). A request that goes through the IT proxy first will look like any other request for 'alice@atlanta.com', and would have the same security properties; no firewall circumvention would occur, or anything like that. Registering an AoR under another AoR is almost always the SIP solution for these problems. The user then distributes 'amr@it.atlanta.com' as their AoR for ENUM and any other purposes, so incoming requests will go to Telecomms or IT as appropriate. Now, if you introduce another constraint that the IT department also will not allow anything but SIP-based IM programs to register at their proxy (again, the enforceability of which is questionable), even that admits of a SIP solution. A single REGISTER request can contain multiple contact addresses which could include both the device URI for the IM program and the AoR for Telecomms. If, finally, you say that IT will not allow contact addresses for anything but a single device URI representing an IM program, then you might have a real policy deadlock, and a third-party AoR would be necessary. More on the Problem in a minute... > I agree that it is possible to combine more than one AoR at a third party > SIP provider. However... Much as I've tried, it isn't easy to explain to > I.T. departments that this is not a bad thing, and that potential incoming > forking behaviour from external INVITEs is not a sign of a DoS attack - > remember, these are the same folk that believed that being slashdotted > was a sign of an intentional cyberattack, and pulled the plug. You > might think that a strange reaction, but I couldn't possibly comment. > Well, sending a single INVITE to two places isn't exactly slashdotting. I'm surprised it would even be a detectable condition, especially since IT and Telecomms have separately administered systems. A more important question is what IT departments have to do with a third-party AoR. If you go get an iptel.org SIP URI, IT doesn't have to know about it or change their behavior in any way. They just receive SIP requests; the requests won't say that their Request-URI was learned at iptel.org. Your company doesn't have to do anything to support your IT AoR or Telecomms AoR being registered under iptel.org. Think of it like hyperlinking - by having a globally-reachable SIP AoR on the Internet, you're essentially doing something like putting up a web page. The question of whether somebody gets to your page by entering the URL into a browser application, or by clicking a link on another page, or by being redirected from another page, is more or less unanswerable by the operator of the page - they just get requests. In SIP, it is even more invisible than it is in HTTP - a redirect server (which I believe is how iptel.org works) leaves no trace of itself in subsequent requests. It is literally impossible for IT to detect or do anything about the fact that a client got their SIP URI from iptel.org. It would be no different than if they'd found the SIP URI on a web page or business card. Concerns that the above is not the case have often seemed to motivate arguments for multiple enumservices since all of this started. This property about how SIP registrations and proxy/redirection work is also what makes policies about registration seem absurd to me. It would be like if you had a globally-reachable web page up on your companies web site, and your company would fire you if you linked to that page from an external site, or something. It's a globally-reachable page - it's there to be reached! The idea that an Telecomm department's proxy, say, would not allow you to have a registration for your IT AoR as a matter of policy is like saying that your Telecomms department would not let you have a web link from your globally-reachable Telecomms web page to your globally-reachable IT group web page. In short, it's ludicrous. What problems is this policy supposed to prevent? Considering this for a few minutes, I can't come up with a single plausible answer to that question. Finally, it's important to point out that this sort of linking has no security implications whatsoever. Just because you learned the Telecomms AoR from the IT AoR or iptel.org doesn't mean you have any privileges at Telecomms. The Telecomms systems would treat your request like any other request - challenging and authorizating it as necessary. It goes through the same firewalls either way, and so on. Anyway, it's not strange that IT departments are conservative, and I can imagine there are enterprises that are not comfortable with SIP and that might believe all kinds of crazy things. What is strange is that you for some reason think putting the two AoRs in ENUM would not result in the same behavior from IT's perspective as putting the two under a third-party AoR. More on this below... > Not only am I not a lawyer nor play one on TV, I am not a Personnel / > Human Resources specialist, and do not understand the logic here - I > take it as a given. > > Thus the company has personnel and I.T./Telecomms policies (not subject > to any technical standardisation that I understand) that mean that the > 'voice' account WILL only have voice capable devices associated with it. > There are no protocol features involved in this, just the threat of > dismissal if employees break the rules - IMHO, a pretty effective > constraint. > > I suggest that this is not an uncommon scenario, and that indicating > 'voice:sip' in the NAPTR holding an AoR "provided by the Telecomms > group", with a separate NAPTR indicating 'im:sip' with an AoR "provided > by the I.T. department" is valid and may be useful; if these ENUM records > are presented to a human being, then they can select the entry accordingly. A number of things about this: First: what phone number for ENUM? Your PSTN steam-phone number? Or some personal number of yours? If it's the company's phone, then they are the assignee, and they decide what goes in your ENUM record, right? Given their ultra-paranoid policies about SIP registrations, I find it very hard to believe that they would not apply similar constraints to ENUM. This kind of begs the question of what their policies with regard to SIP were meant to prevent that ENUM does not allow. The question is, what's the non-technical difference between putting these AoRs in ENUM and registering them in a single SIP AoR? From an administrative perspective, these are identical concepts. If you put both AoRs in ENUM, someone can suck them up and spit out requests at either. Sure, a user who is calling you might select entries according to advertised capability, and only send appropriate requests to each, but then again, they might not - just because I receive a 'voice:sip' ENUM record does not mean I cannot offer video or IM in the SDP of my requests. Putting these AoRs in ENUM does not prohibit anyone from sending any sort of SIP request at either of them. Much more stringent policies could be enforced, incidentally, at the IT or Telecomms SIP proxy server if the AoRs were composed there, unlike the DNS which dumps all of the relevant records in the client's lap. Putting them in ENUM can and will lead to all the behaviors you sounded worried about above - 'incoming forking behavior from external INVITEs', and so on, especially if I have a multiservice client. Once the URIs are in the DNS, they are both fair game. Nothing about the URIs says 'I got these from ENUM'. So what was it, exactly, that IT and Telecomms wanted to prevent by prohibiting certain SIP registrations that they do not enable with ENUM? If you personally control the ENUM record (it's for some personal number of yours, maybe your cell-phone number), I think the same parallels arise, but it's more comparable to the iptel.org AoR. You have some external composition of the work AoRs in an offline system that isn't under the control of IT or Telecomms. They are similarly unable to determine whether or not your ENUM record was accessed to learn their URIs, or whether they came from iptel.org, or whether the client's user pulled the URIs from some agony column in the Guardian. Nor does it have any impact on policy one way or another whether or not the client did. Certainly, any justification to punish you for composing the AoRs at iptel.org would also be justification to punish you for doing so in ENUM. > > I'm sure I speak for all of the authors in agreeing that publishing > SIP contact addresses in ENUM is a BAD and EVIL THING; to be honest I > hadn't even considered it until it was mentioned as a possibility. > In this example, all of the SIP URIs published in ENUM would be full > AoRs. They would have an implied capability simply through the company's > choice of systems configuration, and enforcement of policies. > Okay... but... I'm really not sure how "vovi" works without contact addresses unless you're messing with SIP, as my other mail suggests. I agree that you're talking about AoRs in this mail, but your talking about AoRs with some sort of bizarre policy constraint. Policy constraints, however, doth not implementation standards make. The fact that someone -could- deploy a device in a policy-constrained environment in which the "vovi" standards make some sense would be no argument to standardize them, especially since the standard can be used outside of that environment, and that environment entails non-standard SIP behavior. In any event, I think the environment described above can also be realized without "vovi", as I hope I illustrated, and I would further contend that it can be better implemented without "vovi" (because stricter authentication-based policies at SIP proxies can govern the distribution of requests to devices). > Finally, in the above scenario, the constraints are not technical > but administrative and the reasons for two accounts are bureaucratic. > Agreed, but it's not at all clear what the policy is meant to accomplish, or what it's implications to ENUM would be. > I'm happy to explain to potential customers that they don't need this > separation; I'm happy to show that they can probably same money with > a combined system. The I.T. department might not have to deal with > a W2K Server and ALG, or the Telecomms group might come to love W2K. > > However, I'm not in a position to tell a potential customer that they > can't have a system that fits their bureaucratic designs just because > it's unnecessary. > Different criteria, however, may be applied to standards. Not all that is implemented is standardized. Also, there's the question of whether or not your specific enumservices are actually necessary to satisfy the bureaucratic requirements (not to mention - what are those requirements?). > At least in the Real World we now have web servers and file servers > managed by the same group - things do change. > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 9 15:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28220 for ; Sun, 9 Mar 2003 15:16:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29KT5Z03050 for enum-archive@odin.ietf.org; Sun, 9 Mar 2003 15:29:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29KSjO03041; Sun, 9 Mar 2003 15:28:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29KOXO02911 for ; Sun, 9 Mar 2003 15:24:33 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27097 for ; Sun, 9 Mar 2003 15:11:22 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 20:13:28 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AQXR; Sun, 9 Mar 2003 20:13:22 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , Richard , Rudi Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EDA@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EDA@stntexch2.va.neustar.com> Date: Sun, 9 Mar 2003 20:13:20 +0000 Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, folks, Re-reading the response from Jon to my re-named thread posting, I feel that a more point by point reaction may help - my more general response seemed to leave exactly the same misunderstandings that I was trying to dispel. > One case in which this doesn't work (though there are others, some of which > I've discussed earlier): if, for whatever reason, you boot up on IM client, > and register it at your SIP address of record (the one represented by a > 'voice:sip' record in ENUM), then your AoR now effectively has an IM > capability, at least for the moment. If someone who only had SIP IM > capability subsequently downloaded your ENUM record, though, they would not > find an 'im:sip' record, and subsequently they would assume they are unable > to contact you. This is breakage for SIP - when I register a device, I > expect people to be able to reach it. The user would presumably also have to > put an 'im:sip' record in the DNS when they register the IM device under > their AoR in order for this ENUM-based capability negotiation scheme to > work. Then we begin to get into the differences between real-time > registrations and DNS publications, synchronization between SIP and ENUM, > etc. > I summarise this as:'If an IM-capable device registers behind an AoR that is labelled with 'voice', then an end user, when retrieving the published ENUM data, will not choose that AoR if they have a SIP client that is only capable of IM. This is breakage for SIP'. It is true that the end user might assume that they are incapable of contacting a Registrant using this SIP AoR, but that may be the intention of the Registrant in publishing the information in this way; they are, in effect, stating that they only want voice calls via this AoR. A SIP UAC is still capable of contacting the Registrant's SIP UAS, *IF THEY ALREADY HAVE THE AoR*, so this does not break SIP. To summarise, it still works fine. > The only way to rectify this for AoRs is to apply a policy contraint at a > register than prevent registration of non-voice devices under the AoR > identified by the 'voice:sip' enumservice. That seems unenforceable to me > for several reasons, and even if it were enforceable it would also be > breakage for SIP. > > The conclusion has to be that one cannot publish an AoR associated with a > 'voice:sip' ENUM resource record; it has to be a contact address, not an > AoR. And THAT is the real problem - the publication of contact addresses in > ENUM. More on that below... 8-() It does not require any policy constraint on the part of the SIP infrastructure. If a Registrant chooses to SIP register a device that is capable of another service than the one with which the AoR is labelled in ENUM, then they may intend that information on this capability is not published in EMUM. They may have made a mistake. In either case, this does NOT stop SIP UACs working, nor does it require a change to SIP Registrar operation of any kind. We do not believe that publication of contact addresses is appropriate in ENUM. You continue to believe that we are actually proposing this, despite our protestations to the contrary, as you think that to do otherwise would require policy changes to SIP infrastructure to exclude inappropriate registrations against an AoR that was labelled with a particular capability. All I can do is to re-iterate our statement that AoRs are the only appropriate SIP entities to publish in ENUM, due to their long-term nature. Given the nature of ENUM, it is not possible to block a Registrant from publishing a contact address (or some AoR with which, for some reason, they have only a momentary association and then discard forever). We just don't think it's a good idea for the often repeated DNS update latency reasons. > Again, I invite you to sign up for FWD or iptel.org, two free and painless > SIP services that will accept whatever registrations you'd like. > > And thus I still don't understand why you need to have two service-specific > accounts, why your devices for one capability need to register in one > places, and devices for another capability need to register in another > place. If you only -want- certain capabilities to be available at certain > identifiers for you, that makes sense - but then, why put both identifiers > in ENUM, and make them all available for everyone there? Either you want > people to be able to reach these devices or not. > > The point being, your devices are not forced to register anywhere, and > registrars are not rejecting cross-domain subscriptions, or something - and > even if they were, you can just put both your AoRs under a single iptel.org > AoR, if you want both to be available in SIP (go back to the first bullet > point in my original mail in the thread for more about this). Obviously, > this is orthogonal to whether or not your VirtualPC can support voice or > not; there's no technical or policy impediment to registering both of your > devices under a single AoR. My reasons for having two accounts, each of which I use for registrations of teleservice-specific devices, is administrative (i.e. non-technical) and so not the subject of standardisation, except insofar as I am not allowed to do this by a draft including such labelling being blocked by the IETF. I understand that I could combine the two accounts under a third, or to register one account under the other. In so doing, the resulting "top" account would no longer be teleservice-specific, and so it would be inappropriate to label it so. However, I contend that it is perfectly possible to have two accounts and to use each one in a service-specific manner, and thus being able to label each one accordingly is appropriate. If others do not make this choice but instead decide on a single multi-capability account or simply choose not to label the entry, they won't have a use for a service- specific label and so will use the entry without it (i.e. use a "plain" 'sip' enumservice). I don't see how that means that my choice, and wish to indicate which account I would like folks to use for voice calls, is unacceptable. BTW, I'm not sure how your bullet 1 on provisioning multiple URIs in ENUM causing synchronisation issues that arise with (undesirable) redundancy fits here as these are long-term (and so stable) AoRs? > > Note that even if I register several 'phones with the same AoR, they're > > all just voice terminals. I had thought that what goes into ENUM is the > > AoR, not the individual contact URIs. However, I've been convinced that > > a contact URI would work as well; I learn. > > Right, now we're getting to the point - publishing contact URIs in ENUM is > what you have to be doing in order for these URIs to have capability as > such. It's also what I most vehemently oppose. The reasons that I am opposed > this were the subject of my first mail in this thread (in which I presented > four specific reasons why this is bad). If the authors of "vovi" really > think that contact URIs should be published in ENUM (and I think you more or > less have to be committed to this), I think at least those four bullet > points need to be addressed, though they are not exhaustive. > Again, if by my purely administrative actions I have two accounts, one I use exclusively for voice capable SIP registrations with the other that I use exclusively for IM capable SIP registrations, how does that state that I must mean that I'm installing contact addresses? The AoRs have no intrinsic technical service capability associated with them OTHER than that I assert by my administrative actions. I repeat, I am NOT suggesting the use of SIP contact addresses in ENUM. I was reminded that it would be possible to publish contact URIs in ENUM; OK, it is possible for someone to do this. We all agree that this is a bad idea as you quite correctly point out that contact addresses may be short term. > > If any ENUM client wants to treat 'voice:sip' -as if it were- 'sip', > > that's fine. Support for this enumservice consists solely of ignoring > > the hint and treating it as a standard 'sip' enumservice. > > Sure - in my problem case above, it might be tempting to say that when an > application with a SIP IM capability looks at the ENUM resource records for > SIP, it should be willing to try sending an IM to the 'voice:sip' entry. If > you agree with that, though, then I think you basically agree with my > proposal to have a 'sip' enumservice without any capability semantics. That > hint is semantically disregarded by SIP applications. If a Registrant chooses to label a SIP AoR with a hint as to its use, and I as an end user choose to ignore this advice, then there is no enforcement other than a SIP rejection. Outside of California, I can smoke; in so doing I ignore the label warning me that I will drop dead but only after I have poisoned the entire population. Is this wise? No. Will I be arrested for so doing? We'll see in SF. Seriously, if there is only one entry in ENUM with a SIP AoR, and this is labelled with 'voice', then it may be tempting to ignore this label and try to use the AoR for other kinds of communication. In so doing, the end user should not be surpised if an attempted SIP session results in a rejection. If I dial a phone number labeled as voice and attempt to send a fax, again, I should be unsurpised if a fax doesn't pop out of the callee's ear. The hint indicates a preference on the part of the Registrant. It SHOULD be considered by the end user when selecting between entries with different SIP AoRs, but it's possible for them to ignore this preference. ENUM can't block their actions subsequent on receiving the entries; if a DDDS implementation allows an end user to "break the tie" then this allows the end user to select any of the available entries. The only question that remains is whether or not a DDDS implementation with knowledge of local capabilities will display an entry to the end user if its knowledge leads it to believe that it cannot support the labeled communication type. Is that the whole issue here? > > I still don't understand how this draft is not aligned with IETF > > standards, specifically 3261. I'm willing to believe that SIP with > > CallerPrefs could allow a client to negotiate a kind of service; > > I'm a little surprised that support for this is REQUIRED as the only > > solution if we're to avoid extended offer/rejection cycles. > > > > Service negotiation goes well beyond caller prefs, which as you surmise is > not REQUIRED. See my previous note, especially the fourth bullet point, on > why primitives like 'voice' aren't really suitable for SIP capability > negotiation. Incidentally, in parallel forking cases that are likely when > scanning multiple devices for a given capability, the offer/answer cycles > occur simultaneously, and don't result in any appreciable delay. > In response to the "doesn't result in any appreciable delay", I have two comments: * You have obviously not tried to use some of the early SIP implementations on a 2G/2.5G 'phone :) * An ENUM lookup and resolution is a pre-call activity, particularly if the end user is involved in making a selection so "breaking the tie" in the final round of DDDS processing. It's pretty quick, with just one round trip of a short packet (in fact for some GPRS services, it isn't even charged :). A SIP resolution that leads into a call may well be perceived as a mid-call activity. Whether or not this is the case remains to be seen, until which time I'm conservative in terms of what constitutes an appreciable delay. Re. the points in your earliest posting, I will respond to that shortly. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 9 15:46:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02143 for ; Sun, 9 Mar 2003 15:46:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29KxE104683 for enum-archive@odin.ietf.org; Sun, 9 Mar 2003 15:59:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29Kx6O04672; Sun, 9 Mar 2003 15:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29Ku3O04579 for ; Sun, 9 Mar 2003 15:56:03 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01741 for ; Sun, 9 Mar 2003 15:42:53 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 20:44:59 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AQYB; Sun, 9 Mar 2003 20:44:54 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , Richard Cc: enum@ietf.org, Rudi on the road Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EC7@stntexch2.va.neustar.com> Date: Sun, 9 Mar 2003 20:44:52 +0000 Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 4:47 pm -0500 6/3/03, Peterson, Jon wrote: >I wanted to make some comments about this issue. Herewith my tardy response to Jon's original posting on the 'vovi' draft (from Thursday 030306). This consisted of 4 points that are referred to in later posts. Point 1:: > - ENUM is not necessarily a prerequisite for using SIP - sometimes > people may try to reach me with SIP without first using ENUM. Because I > want to make all of my identifiers available to people who use SIP > without consulting ENUM first (because they already have a URI, not a > telephone number), we cannot replace SIP registration with ENUM records > - we'd have to keep them in SIP as well. Provisioning multiple URIs in > ENUM will always have to be redundant with SIP registration. This raises > questions of synchronization and the usual issues that arise with > (undesirable) redundancy. I understand this to mean:- SIP doesn't need ENUM. For SIP to work at all, identifiers must be "known" to the SIP system. Thus, for SIP, ENUM entries are always redundant in that they merely duplicate information. Provisioning multiple URIs in ENUM will always have to be redundant with SIP Registration. Response:: The above point seems to assume that a SIP UAC will not be able to initiate a communications session to a remote destination unless information on that destination has been registered with SIP previously - that seems to be true only if the UAC or SIP intermediaries do not check ENUM and act accordingly. Also, to clarify: I *had* read your point 1 as discussing synchronisation errors and redundancy with SIP registrations for ENUM publication of multiple ->SIP<- URIs, but note that it actually talks of multiple URIs. Does this point only talk to SIP URIs in ENUM, or is it instead discussing a model where there is only ever a single URI published in ENUM, with SIP providing the registration, storage and discovery of all others? ---- Point 2:: > - SIP has a built-in method for registering a URI under another URI, > with lots of apparatus for security, privacy, refreshes, expirations, > priority, capability, and so on. Any SIP compliant (2543 or 3261) user > agent will support this method. Most SIP user agents register > automatically when they boot or come online. I don't think we've yet > identified a way for applications to similarly publish information into > ENUM. For many applications that would be identified by ENUM (like email > clients or web pages) the concept isn't even meaningful. I understand this to mean:- SIP has a mechanism for registration of a URI "below" another. SIP User Agents use this mechanism and most register automatically when they boot or come online. There is no such process by which an application can update published information in ENUM. For many applications (like email addresses or web pages) the concept isn't even meaningful. Response:: Agreed; SIP is ideal for resolving real-time transient associations, whilst the different DNS update procedures are not. Re. 'Mechanisms by which DNS updates can be requested by applications have not been identified'. Well...there are ENUM Trials in Europe to explore this (amongst other things) this. There are pretty standard (IXFR) techniques that are in the process of being tried; it's not hard. Re. 'not meaningful' - I beg to differ on this last. I may well have a web page associated with my phone number - you look up ENUM to find the URL. In fact, you could use CLI information you receive when getting an incoming PSTN call to do an ENUM lookup and display the phone-number associated web page. If you mean that an email client cannot use a phone number as a source or destination so an intermediary cannot perform an ENUM lookup on its behalf, this is another question that is not germane to the vovi draft. (and is also being covered in ENUM Trials, I think). ---- Point 3:: > - SIP registrations may have very brief durations. I may only be > associated with a device (and hence the devices URI) for a short amount > of time. It isn't clear that the DNS is the best place to express very > short term relationships of this nature. DNS scales most effectively > when entries can be cached for more significant durations (at least > hours). SIP is optimized for real-time establishment and termination of > registrations. I understand this to mean:- SIP registrations may be brief; DNS is not the place for highly dynamic information. Response: Of course; that's why we expect Registrants to publish AoRs, NOT transient contact URIs. In common for ALL ENUM entries, short-term associations are not appropriate due to update and latency (caching) issues. ---- Point 4: > - The capabilities expressed by primitives like 'voice' and 'video' are > both too coarse and too strict for SIP. They are too coarse because they > will always be redundant with SIP's own SDP-based negotiation upon > session establishment, which gets into far greater details about what > 'video' entails (codecs and intervals, and so on) - if two SIP endpoints > both support 'video' that doesn't mean they'll be able to communicate. > The primitives are too strict because the SIP process is designed to > find the best way for two user agents to communicate, taking into > account the capabilities and preferences of both. Designating that a SIP > URI is a 'voice' URI doesn't even really make sense. If you don't need > this capability negotiation function of SIP, you probably don't need SIP > as such. Point 4: (i) coarse I understand this to mean:- 'voice' or 'video' are too coarse - they do not guarantee that a media session to carry voice (or video) is possible between two end points, as these end points may not share a common codec. (ii) strict I understand this to mean:- 'voice' or 'video' are too strict. It is technically impossible to block an attempted registration under an AoR based on the capability of the device making the registration (or the AoR to be registered under the enclosing one). Thus it is incorrect to assert that a particular AoR will be associated only with devices that support the labelled capability. Responses: On "too coarse" - Agreed - any information in ENUM is perforce redundant, and does not guarantee media session interoperation between end points. So? This is a label, not a guarantee. True, we do not suggest indicating the codecs supported behind an AoR so that an end user may try and fail to make a call, but to add enough information to ENUM to avoid this would be fraught with problems, and pointless, as that's what an eventual SIP INVITE will do if the SIP entry is selected. On "too strict" - I repeat - there is no requirement on SIP to check the capabilities of devices registering with a particular AoR. If an AoR is labeled as being associated with a particular capability, and the devices registered under this AoR either do not support that capability, or in addition support other capabilities, then this is not a protocol problem; it's a problem for the publisher of incorrect data. Would mislabelling mean that a SIP AoR was not tried, even though it DID have a device registered behind it that actually fitted another (preferred) kind of communications session? Perhaps. I somehow doubt that adding any text would convince, but we could add something to state that, IF there is an entry that has a SIP AoR labeled with 'voice' or 'video' AND there is no entry with a pure 'sip' enumservice (i.e. without label), AND the local client is incapable of supporting voice or video, THEN the client may display the entry with a SIP AoR and allow the end user to select it. That's mighty far into local policy, but if it helps, we'll add it. If there were to be no labelling at all, as proposed by these arguments, then the only way that a user would know whether or not their preferred communication session type was supported behind a given AoR would be to engage in a SIP exchange. This way I can get a hint in a single packet exchange, and I can choose other sub-systems that do support my preferred communication session type without first gleaning information on whether or not the devices behind the SIP AoRs can support such a session type. I may miss a possible SIP communications chance due to a mistake on the part of the Registrant or by the Registrant's choice, but that isn't something we can avoid or would want to avoid. I have a perfectly adequate set of SIP phones; SIP does the codec and address/port negotiation very well. I DO need SIP. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 9 17:41:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21222 for ; Sun, 9 Mar 2003 17:41:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29Msbh11609 for enum-archive@odin.ietf.org; Sun, 9 Mar 2003 17:54:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29MsWO11603; Sun, 9 Mar 2003 17:54:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29MpFO11322 for ; Sun, 9 Mar 2003 17:51:15 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20314 for ; Sun, 9 Mar 2003 17:38:02 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 22:40:09 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AQZ0; Sun, 9 Mar 2003 22:40:01 -0000 From: "Conroy, Lawrence (SMTP)" To: jon.peterson@neustar.biz Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 9 Mar 2003 22:39:56 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: draft-enum-sip-00.txt - AoRs Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, folks, As the authors have tried to indicate over the chain of postings on the 'vovi' draft, we agree that all AoRs are not *intrisically* associated with a capability. However, we believe that an AoR may be *administratively* associated with a capability, and have described how this may happen through beurocratic choice. In the process of this discussion, I have had cause to read the 'sip' draft in some detail, and to attempt to explain it to others. I'm not sure I understand it fully, hence:: From the discussions so far, I understand that a device may register with a proxy when it boots or goes online. Thus it will have its own AoR; one associated purely with that device. Thus, I would argue that, in practice, dynamic associations may also be made between two independent AoRs; one tied to a device when it registers, with another tied to the end user who has registered their presence on this device *or has associated themselves with this device's AoR*. Section 3 of the 'sip' draft seems to skip mention of this association (device AoR with User AoR) in its attempts to imply (quite rightly) that contact addresses are not useful for ENUM. Note that, if the device registers on boot, it will have an AOR. Assuming that this device does have a given capability, this conflicts the suggestion in the 'sip' draft that AoRs NEVER have an associated capability, and that capabilities are ONLY associated with contact addresses. Some AoRs are capability-independent, or are associated with varying capability, whilst others are associated with devices that have a stable capability set. Is this correct, or am I missing something in the 'sip' draft? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 05:03:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07563 for ; Mon, 10 Mar 2003 05:03:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AAGD030299 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 05:16:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAG6O30292; Mon, 10 Mar 2003 05:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAEZO30224 for ; Mon, 10 Mar 2003 05:14:35 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07150 for ; Mon, 10 Mar 2003 05:01:06 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2AA2xC06871; Mon, 10 Mar 2003 10:03:06 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 05:03:12 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE4@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Richard Cc: enum@ietf.org, Rudi on the road Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt Date: Mon, 10 Mar 2003 05:03:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Okay, another helping. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Sunday, March 09, 2003 12:45 PM > To: Peterson, Jon; Richard > Cc: enum@ietf.org; Rudi on the road > Subject: RE: [Enum] draft-brandner-enumservice-vovi-00.txt > [snip] > > Point 1:: > > I understand this to mean:- SIP doesn't need ENUM. For SIP to work at > all, identifiers must be "known" to the SIP system. Thus, for SIP, ENUM > entries are always redundant in that they merely duplicate information. > Provisioning multiple URIs in ENUM will always have to be redundant with > SIP Registration. > This is orthogonal to whether or not SIP "needs" ENUM (which it does, when you have a telephone number and want a SIP URI). For SIP to work, SIP device URIs should be known to a SIP registrar, sure. Any AoRs you'd want to put in ENUM should be available to ordinary SIP clients that use URIs rather than telephone numbers. For that reason, this sort of provisioning in ENUM would be redundant with SIP registration. > Response:: > The above point seems to assume that a SIP UAC will not be able to > initiate a communications session to a remote destination unless > information on that destination has been registered with SIP previously > - that seems to be true only if the UAC or SIP intermediaries do not > check ENUM and act accordingly. > Right. So when do you check ENUM? When you have a telephone number and you want a URI. Well, what if you don't have a telephone number? What if you have a SIP URI? If an end user wants to be reachable through multiple SIP devices, they want to be reachable through them in the same way regardless of whether or not a caller only knows a telephone number for them, I think. ENUM shouldn't have to be a prerequisite for discovering all of the SIP AoRs or devices through which users are available. If we architect enumservices that assume that SIP is never used unless ENUM is used first, that's bad. > Also, to clarify: > I *had* read your point 1 as discussing synchronisation errors and > redundancy with SIP registrations for ENUM publication of multiple > ->SIP<- URIs, but note that it actually talks of multiple URIs. > I meant SIP URIs, sorry. > Does this point only talk to SIP URIs in ENUM, or is it instead > discussing a model where there is only ever a single URI published in > ENUM, with SIP providing the registration, storage and discovery of all > others? > No, I'm only talking about SIP here. This text points out that if you do not adopt a model in which a single SIP AoR is published in ENUM, you are left with the resulting ENUM-SIP synchronization problem, which is exacerbated by points 2 and 3. > ---- > > Point 2:: > > > I understand this to mean:- SIP has a mechanism for registration of a > URI "below" another. SIP User Agents use this mechanism and most > register automatically when they boot or come online. There is no such > process by which an application can update published information in > ENUM. > > For many applications (like email addresses or web pages) the concept > isn't even meaningful. > > Response:: > Agreed; SIP is ideal for resolving real-time transient associations, > whilst the different DNS update procedures are not. > > Re. 'Mechanisms by which DNS updates can be requested by applications > have not been identified'. > Well...there are ENUM Trials in Europe to explore this (amongst other > things) this. There are pretty standard (IXFR) techniques that are in > the process of being tried; it's not hard. > Well, I have no doubt that there are candidates for this. But these methods have not yet been identified as IETF standards for ENUM. I haven't seen a proposal in this WG yet for anything, I don't think. IXFR might turn out to be controversial (though let's not go there now!). RFC2916 was released without any way for applications to register themselves in ENUM (and I doubt this will come to be in scope for bis). RFC2543 was released with a REGISTER method. It just shows a different orientation of the standards; SIP was designed with dynamic registration in mind. I would say that the SIP community is a lot further along on registration than ENUM is. > Re. 'not meaningful' - I beg to differ on this last. I may well have a > web page associated with my phone number - you look up ENUM to find the > URL. In fact, you could use CLI information you receive when getting an > incoming PSTN call to do an ENUM lookup and display the phone-number > associated web page. > 'not meaningful' here signifies only that the web and email are not real-time communications in the sense, say, that instant messaging is. A web page does not disappear here and reappear there five times in an hour, all the while dynamically updating some directory service to point to its current location. Web and email URIs are comparatively static resources. Therefore the relatively static nature of DNS is not impactful to their registration. > If you mean that an email client cannot use a phone number as a source > or destination so an intermediary cannot perform an ENUM lookup on its > behalf, this is another question that is not germane to the > vovi draft. > (and is also being covered in ENUM Trials, I think). > No, I didn't mean that. > ---- > > Point 3:: > > I understand this to mean:- SIP registrations may be brief; DNS is not > the place for highly dynamic information. > > Response: > Of course; that's why we expect Registrants to publish AoRs, NOT > transient contact URIs. In common for ALL ENUM entries, short-term > associations are not appropriate due to update and latency (caching) > issues. > Seems like ample justification to recommend against putting contact addresses in ENUM. > ---- > > > Point 4: > (i) coarse > I understand this to mean:- 'voice' or 'video' are too coarse - they do > not guarantee that a media session to carry voice (or video) is possible > between two end points, as these end points may not share a common > codec. > > (ii) strict > I understand this to mean:- 'voice' or 'video' are too strict. > It is technically impossible to block an attempted registration under an > AoR based on the capability of the device making the registration (or > the AoR to be registered under the enclosing one). Thus it is incorrect > to assert that a particular AoR will be associated only with devices > that support the labelled capability. > > Responses: > On "too coarse" - > Agreed - any information in ENUM is perforce redundant, and does not > guarantee media session interoperation between end points. > So? This is a label, not a guarantee. Yes, this would beg the question of how effective a 'label' is, and what you hope to accomplish by supplying a label. > True, we do not suggest indicating the codecs supported behind an AoR so > that an end user may try and fail to make a call, but to add enough > information to ENUM to avoid this would be fraught with problems, and > pointless, as that's what an eventual SIP INVITE will do if the SIP > entry is selected. > Agreed, it would be terrifying to put further capability information into ENUM. But 'voice' is a slippery slope. It doesn't accomplish enough on its own to be able to determine that you'll be able to communicate before you call the URI, and yet we can't realistically supplement it with further information. > On "too strict" - > I repeat - there is no requirement on SIP to check the capabilities of > devices registering with a particular AoR. If an AoR is labeled as being > associated with a particular capability, and the devices registered > under this AoR either do not support that capability, or in addition > support other capabilities, then this is not a protocol problem; it's a > problem for the publisher of incorrect data. > No, it just illustrates that your enumservice concept is incoherent. If putting a URI in ENUM would make some SIP registrations 'incorrect' or incompatible with ENUM, then there's something wrong with the way we're using ENUM. ENUM is a way of turning telephone numbers into URIs; it should change the significance of those URIs in their native protocols. > Would mislabelling mean that a SIP AoR was not tried, even though it > DID have a device registered behind it that actually fitted another > (preferred) kind of communications session? Perhaps. > Yes, and that would be bad! > I somehow doubt that adding any text would convince, but we could add > something to state that, IF there is an entry that has a SIP AoR labeled > with 'voice' or 'video' AND there is no entry with a pure 'sip' > enumservice (i.e. without label), AND the local client is incapable of > supporting voice or video, THEN the client may display the entry with a > SIP AoR and allow the end user to select it. > That's mighty far into local policy, but if it helps, we'll add it. > Well, this is the DDDS compliance issue. Enumservice strings are literals - there's a list of them that are supported, and everything else is unsupported (as far as I understand DDDS), for a given client going through the algoirthm. So if a client has only IM capability, why would the DDDS algorithm ever return rules with 'voice' and 'video' in your case above? It would only do so if the client was looking for them, right? I don't think there's a DDDS concept of 'give me any old enumservice with the string *sip* in it'. But if a client looks for SIP-specific records regardless of its capability, then why not just have an 'e2u+sip' service and do away with this complexity and the resulting negative effects? > If there were to be no labelling at all, as proposed by these arguments, > then the only way that a user would know whether or not their preferred > communication session type was supported behind a given AoR would be to > engage in a SIP exchange. > > This way I can get a hint in a single packet exchange, and I can choose > other sub-systems that do support my preferred communication session > type without first gleaning information on whether or not the devices > behind the SIP AoRs can support such a session type. I may miss a > possible SIP communications chance due to a mistake on the part of the > Registrant or by the Registrant's choice, but that isn't something we > can avoid or would want to avoid. > Again, just seeing 'video' in the label doesn't mean that the remote device will support the same sorts of sessions that you do - you still have to send a SIP request in order to do SDP negotiation to see if compatible codecs are available. So you still need a SIP exchange to see what is supported behind the AoR. On the use of the term 'mistake' to characterize the IM-under-voice:sip example, I think it is an open question whether the mistake lies in registering a device with an 'incorrect' capability under a given AoR, or in using a service-specific enumservice in the first place. No registration for an extent URI is ever 'mistaken' in SIP. I think it would be nice if we could define enumservices for SIP that did not raise the possibility of turning registrations into mistakes. > I have a perfectly adequate set of SIP phones; SIP does the codec and > address/port negotiation very well. I DO need SIP. > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 05:05:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07953 for ; Mon, 10 Mar 2003 05:05:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AAI4Z30465 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 05:18:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAI4O30460; Mon, 10 Mar 2003 05:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAHVO30412 for ; Mon, 10 Mar 2003 05:17:31 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07715 for ; Mon, 10 Mar 2003 05:04:03 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2AA69C06896; Mon, 10 Mar 2003 10:06:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 05:06:22 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE6@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" Cc: enum@ietf.org Date: Mon, 10 Mar 2003 05:06:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: draft-enum-sip-00.txt - AoRs Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , A little more below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Sunday, March 09, 2003 2:40 PM > To: jon.peterson@neustar.biz > Cc: enum@ietf.org > Subject: Re: draft-enum-sip-00.txt - AoRs > > > Hi Jon, folks, > As the authors have tried to indicate over the chain of postings on > the 'vovi' draft, we agree that all AoRs are not *intrisically* > associated with a capability. However, we believe that an AoR may be > *administratively* associated with a capability, and have described > how this may happen through beurocratic choice. > > In the process of this discussion, I have had cause to read the 'sip' > draft in some detail, and to attempt to explain it to others. I'm not > sure I understand it fully, hence:: > > From the discussions so far, I understand that a device may register > with a proxy when it boots or goes online. Thus it will have its own > AoR; one associated purely with that device. Um, that's not what I meant, no. I have an address-of-record, sip:jon.peterson@iptel.org. When my devices (like my Cisco phone) boot, they all register their contact address (a device-specific URI) under that AoR. My AoR is not specific to that device; any number of devices may register there - my phone doesn't have its own AoR. I'd point you to section 10 of RFC3261 where the concepts of AoR and contact addresses are discussed. > > Thus, I would argue that, in practice, dynamic associations may also > be made between two independent AoRs; one tied to a device when it > registers, with another tied to the end user who has registered their > presence on this device *or has associated themselves with this > device's AoR*. Section 3 of the 'sip' draft seems to skip mention of > this association (device AoR with User AoR) in its attempts to imply > (quite rightly) that contact addresses are not useful for ENUM. > This analysis isn't very clear to me from a SIP perspective. A dynamic association exists between the device's contact address and the AoR (which is 'tied' to the end user). When a user uses a device, it registers under their AoR. You could, for example, come over to my SIP phone, configure your registrar and your credentials, and register from my device. Then my device would be available through your AoR. In other words, registering your presence on a device, and the registration of a device, are identical in SIP terms (again, see RFC3261 section 10) - I'm not sure what distinction you're drawing above. I think my draft is commensurable with the practices in RFC3261. > Note that, if the device registers on boot, it will have an AOR. > Assuming that this device does have a given capability, this > conflicts the suggestion in the 'sip' draft that AoRs NEVER have an > associated capability, and that capabilities are ONLY associated with > contact addresses. Some AoRs are capability-independent, or are > associated with varying capability, whilst others are associated with > devices that have a stable capability set. > Again, devices don't have AoRs, they have contact addresses (that's what a device URI is). AoRs are essentially pointers to a user, not a device. They're capability-independent necessarily. > Is this correct, or am I missing something in the 'sip' draft? > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 05:05:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07966 for ; Mon, 10 Mar 2003 05:05:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AAI6X30497 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 05:18:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAI5O30492; Mon, 10 Mar 2003 05:18:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AAHYO30424 for ; Mon, 10 Mar 2003 05:17:34 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07732 for ; Mon, 10 Mar 2003 05:04:06 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2AA69C06898; Mon, 10 Mar 2003 10:06:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 05:06:22 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE5@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Richard , Rudi Cc: enum@ietf.org Subject: RE: [Enum] RE: VOVI draft 'voice:sip' enumservice Date: Mon, 10 Mar 2003 05:06:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Sunday, March 09, 2003 12:13 PM > To: Peterson, Jon; Richard; Rudi > Cc: enum@ietf.org > Subject: [Enum] RE: VOVI draft 'voice:sip' enumservice > > > Hi Jon, folks, > > Re-reading the response from Jon to my re-named thread > posting, I feel that > a more point by point reaction may help - my more general > response seemed to > leave exactly the same misunderstandings that I was trying to dispel. > [snip] > > > I summarise this as:'If an IM-capable device registers behind an AoR > that is labelled with 'voice', then an end user, when retrieving the > published ENUM data, will not choose that AoR if they have a SIP client > that is only capable of IM. This is breakage for SIP'. > > It is true that the end user might assume that they are incapable of > contacting a Registrant using this SIP AoR, but that may be the > intention of the Registrant in publishing the information in this way; > they are, in effect, stating that they only want voice calls via this > AoR. > > A SIP UAC is still capable of contacting the Registrant's SIP UAS, > *IF THEY ALREADY HAVE THE AoR*, so this does not break SIP. > To summarise, it still works fine. > Well, to this last point, I think you understand what I'm saying, but your analysis ignores the consequences of this. Of course if someone already possesses the SIP AoR, they can use it normally. If they already possess the AoR, they don't need to be using ENUM to discover a SIP URI, right? The people for whom SIP is broken by your enumservice are the people that are using ENUM because they don't already possess the AoR - because they only have a telephone number. The point is that using ENUM with "vovi" enumservices potentially blinds them to the capabilities of devices registered at the AoR. Your point here amounts to "if you don't use ENUM, then the "vovi" enumservices won't affect your SIP behavior." To the second point, if the ENUM registrant hopes to somehow prevent non-voice media streams from being offered to the endpoint, then as I've illustrated before, this enumservice architecture will not prevent that unless you further assume further breakage of SIP - that is, unless you assume that the SDP offer will only contain voice-related codecs when the enumservice that resulted in the SIP INVITE was 'E2U+sip:voice'. That would be a serious SIP functional change. In other words, putting 'E2U+sip:voice' in the DNS will not in any way constrain SIP UACs from offering non-voice media lines to the URI in question. And finally, to the first point, it's not just a matter that an 'end user might assume they are incapable of contacting' the target - this is a DDDS question. If you support only IM, you look for an 'E2U+im:sip' record, or something, and it's not there. If the only capability the client possesses is im, it will not look for 'voice' records - I'm not sure how else to understand the "vovi" proposal. If the client is willing to get a 'voice' record even though it only supports IM, then essentially the 'voice' part is ignored - in which case you might as well have used an 'E2U+sip' enumservice for all the good the 'voice' does you, and you very well may be breaking compliance with DDDS. [snip] > > 8-() > > It does not require any policy constraint on the part of the SIP infrastructure. > If a Registrant chooses to SIP register a device that is capable of another > service than the one with which the AoR is labelled in ENUM, then they may > intend that information on this capability is not published in EMUM. > They may have made a mistake. In either case, this does NOT top SIP UACs > working, nor does it require a change to SIP Registrar operation of any kind. > My response to this can be found above. > We do not believe that publication of contact addresses is appropriate in ENUM. > You continue to believe that we are actually proposing this, despite our > protestations to the contrary, as you think that to do otherwise would > require policy changes to SIP infrastructure to exclude inappropriate > registrations against an AoR that was labelled with a > particular capability. > > All I can do is to re-iterate our statement that AoRs are the only appropriate > SIP entities to publish in ENUM, due to their long-term nature. > > Given the nature of ENUM, it is not possible to block a Registrant from > publishing a contact address (or some AoR with which, for some reason, > they have only a momentary association and then discard forever). > We just don't think it's a good idea for the often repeated DNS update > latency reasons. > The difference between our positions here, I think, is that I want the standard to offer some guidance about the matter. Your statements that it is not possible to block a registrant from entering a contact address is orthogonal to what we recommend in the standard. If we show people why this would be bad, and tell them not to do it, it will help. It is also possible to run IP over HTTP, but we recommend against it in the IETF and tell people why it is bad. [snip] > > My reasons for having two accounts, each of which I use for registrations > of teleservice-specific devices, is administrative (i.e. non-technical) and > so not the subject of standardisation, except insofar as I am not allowed to > do this by a draft including such labelling being blocked by the IETF. > > I understand that I could combine the two accounts under a third, or to > register one account under the other. In so doing, the resulting "top" > account would no longer be teleservice-specific, and so it would be > inappropriate to label it so. > > However, I contend that it is perfectly possible to have two accounts > and to use each one in a service-specific manner, and thus being able > to label each one accordingly is appropriate. If others do not make this > choice but instead decide on a single multi-capability account or simply > choose not to label the entry, they won't have a use for a service- > specific label and so will use the entry without it (i.e. use a "plain" > 'sip' enumservice). > > I don't see how that means that my choice, and wish to indicate which > account I would like folks to use for voice calls, is unacceptable. > Sure, it is possible to choose to have two service-specific AoRs. It defeats the whole purpose of the discovery and capability negotation aspects of SIP, but it's possible. It basically means that people who don't use ENUM need to remember two different AoRs for you, depending on what service they want to use. Remember, ENUM is used when you have a telephone number. Unless you mean that SIP users should NEVER distribute SIP URIs for themselves, but should ONLY distribute telephone numbers, in which case they would only have to remember one identifier. Which would, once again, be a change in how SIP works. All that said, let me pose you the question underlying the capital-"P" Problem again (the one in the email I don't think you've answered yet): what, exactly, is the point of a policy that prevents composing URIs in SIP, but instead composes them in ENUM? What does the SIP policy of having two service-specific AoRs try to prevent that ENUM does not enable? It isn't clear what composing this two service-specific AoRs in ENUM accomplishes because: - People can still send requests to your 'service specific' URIs that offer other services in SDP. - In my IM-under-voice:sip case, it blocks requests that should succeed. If there's some other policy objective that you hope to fulfill by having two service-specific SIP AoRs, it would really help if I understood what that was. > BTW, I'm not sure how your bullet 1 on provisioning multiple URIs in > ENUM causing synchronisation issues that arise with (undesirable) > redundancy fits here as these are long-term (and so stable) AoRs? > My bullet 1 point is applicable to the Problem question I pose above. [snip] > > > Again, if by my purely administrative actions I have two accounts, one > I use exclusively for voice capable SIP registrations with the other > that I use exclusively for IM capable SIP registrations, how does that > state that I must mean that I'm installing contact addresses? The AoRs > have no intrinsic technical service capability associated with them > OTHER than that I assert by my administrative actions. I repeat, I am NOT > suggesting the use of SIP contact addresses in ENUM. > Okay, I won't come back to this point. > I was reminded that it would be possible to publish contact URIs in ENUM; > OK, it is possible for someone to do this. We all agree that this is a bad > idea as you quite correctly point out that contact addresses may be short > term. > Possible, but we can counterindicate it. > > If a Registrant chooses to label a SIP AoR with a hint as to its use, > and I as an end user choose to ignore this advice, then there is no > enforcement other than a SIP rejection. > Yes, but you thus agree that labeling a URI with a service-specific enumservice doesn't prevent anyone from launch SIP requests offering SDP with other services, right? So what is the policy you're enabling here with the ENUM labels? > Outside of California, I can smoke; in so doing I ignore the label > warning me that I will drop dead but only after I have poisoned the > entire population. Is this wise? No. Will I be arrested for so doing? > We'll see in SF. > > Seriously, if there is only one entry in ENUM with a SIP AoR, and > this is labelled with 'voice', then it may be tempting to ignore > this label and try to use the AoR for other kinds of communication. > In so doing, the end user should not be surpised if an attempted SIP > session results in a rejection. If I dial a phone number labeled as > voice and attempt to send a fax, again, I should be unsurpised if > a fax doesn't pop out of the callee's ear. > > The hint indicates a preference on the part of the Registrant. It > SHOULD be considered by the end user when selecting between entries > with different SIP AoRs, but it's possible for them to ignore this > preference. ENUM can't block their actions subsequent on receiving > the entries; if a DDDS implementation allows an end user to "break > the tie" then this allows the end user to select any of the available > entries. > Well, just repeating myself here but two things: 1) Saying that the enumservice capability SHOULD be considered by the end users means that their SIP application SHOULD NOT offer SDP that advertises other services. That is, surprise surprise, a SIP behavior change that requires SIP UAs to be aware of the ENUM process and modify their offers accordingly, possibly to the detriment of SIP. Actually, my second thing is the subject of the paragraph immediately below. > The only question that remains is whether or not a DDDS implementation > with knowledge of local capabilities will display an entry to the end > user if its knowledge leads it to believe that it cannot support the > labeled communication type. > I think it's a little more cut-and-dry with that. The DDDS application will display Rules associated with supported enumservices to the end user. Applications presumably have to inform a DDDS resolver of which enumservices they support (the 'capability' part), or users have to configure DDDS with their understanding of this. I assume your vision is that if your device only supports IM, it'll only look for IM-based enumservices. Again, if not, then I don't see why 'E2U+sip' isn't good enough since the hint is essentially discarded (and you have to inform DDDS to look for every conceivable enumservice string that includes 'sip'). > Is that the whole issue here? > Well, this is one of six or so issues in circulation in this thread, but it's an important one, yes. > > > > > > > > Service negotiation goes well beyond caller prefs, which as you surmise is > > not REQUIRED. See my previous note, especially the fourth bullet point, on > > why primitives like 'voice' aren't really suitable for SIP capability > > negotiation. Incidentally, in parallel forking cases that are likely when > > scanning multiple devices for a given capability, the offer/answer cycles > > occur simultaneously, and don't result in any appreciable delay. > > > > In response to the "doesn't result in any appreciable delay", I have > two comments: > * You have obviously not tried to use some of the early SIP > implementations on a 2G/2.5G 'phone :) > I meant that SIP parallel forking does not result in any incremental delay (over and above the delay of sending a single SIP call attempt). > * An ENUM lookup and resolution is a pre-call activity, particularly if > the end user is involved in making a selection so "breaking the tie" > in the final round of DDDS processing. It's pretty quick, with just > one round trip of a short packet (in fact for some GPRS services, it > isn't even charged :). > > A SIP resolution that leads into a call may well be perceived as a > mid-call activity. > > Whether or not this is the case remains to be seen, until which time > I'm conservative in terms of what constitutes an appreciable delay. > I don't have too much to say to any of these, other than that they are implementation-specific points. A service provider could decide that DNS is free and all SIP requests are charged $100 no matter what they intend. They could also decide the reverse. Neither course is set in stone. > Re. the points in your earliest posting, I will respond to > that shortly. > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 10:09:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28290 for ; Mon, 10 Mar 2003 10:09:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AFMmS18395 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 10:22:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFMiO18389; Mon, 10 Mar 2003 10:22:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AFLFO18342 for ; Mon, 10 Mar 2003 10:21:15 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28019 for ; Mon, 10 Mar 2003 10:07:43 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2AF9KQ02127; Mon, 10 Mar 2003 07:09:20 -0800 Message-Id: <5.2.0.9.2.20030310095915.049e06e0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 10:09:42 -0500 To: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" From: Richard Shockey Subject: Re: [Enum] Questions Part 2 Cc: enum@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EE6@stntexch2.va.neus tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > > > > In the process of this discussion, I have had cause to read the 'sip' > > draft in some detail, and to attempt to explain it to others. I'm not > > sure I understand it fully, hence:: > > > > From the discussions so far, I understand that a device may register > > with a proxy when it boots or goes online. Thus it will have its own > > AoR; one associated purely with that device. > >Um, that's not what I meant, no. I have an address-of-record, >sip:jon.peterson@iptel.org. When my devices (like my Cisco phone) boot, they >all register their contact address (a device-specific URI) under that AoR. >My AoR is not specific to that device; any number of devices may register >there - my phone doesn't have its own AoR. I'd point you to section 10 of >RFC3261 where the concepts of AoR and contact addresses are discussed. For purposes of clarity ... A. I've seen no postings from authoritive H.323 types so I'm wondering if the discussion on SIP enumservice granularity ..is applicable for that protocol. The question then ..Is H.323 different enough from sip in the negotiation of capabilities that granularity aka voice:h323 is acceptable. B. What of the case where I have multiple SIP service providers... I have sip based IM from Microsoft and a sip based service from ... iptel ..whomever. What of the case where I as the ENUM registrant need to distinguish between the two im:sip .....use this AoR voice:sip ..use this AoR. the reason being that neither my sip based IM provider or SIP based voice provider has the capability of negotiating a redirection since neither service gives me the ability to configure my account appropriately. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 14:56:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10542 for ; Mon, 10 Mar 2003 14:56:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AK9lr10807 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 15:09:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AK9gO10794; Mon, 10 Mar 2003 15:09:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AK8HO10749 for ; Mon, 10 Mar 2003 15:08:17 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10493 for ; Mon, 10 Mar 2003 14:54:40 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2AJudC18702; Mon, 10 Mar 2003 19:56:39 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 14:56:52 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EE9@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Richard Shockey'" , "'Conroy, Lawrence (SMTP)'" Cc: enum@ietf.org Subject: RE: [Enum] Questions Part 2 Date: Mon, 10 Mar 2003 14:56:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Answers part 2 below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, March 10, 2003 7:10 AM > To: Peterson, Jon; 'Conroy, Lawrence (SMTP)'; Peterson, Jon > Cc: enum@ietf.org > Subject: Re: [Enum] Questions Part 2 > > [snip] > > For purposes of clarity ... > Yes, we need more of that, no doubt. I'm sorry if this debate has been rather murky. I've been hoping to post a summary (for general consumption) of the issues Mr. Conroy and I have been discussing soon. Maybe we can use some SF agenda time for this...? > A. I've seen no postings from authoritive H.323 types so I'm wondering if > the discussion on SIP enumservice granularity ..is applicable for that > protocol. The question then ..Is H.323 different enough from sip in the > negotiation of capabilities that granularity aka voice:h323 is acceptable. > I hope that Ms. Levin or other advocates of H.323 enumservice proposals can speak to that. I do think that the treatment of URIs and registration in H.323 is different, and therefore it is conceivable different conclusions could apply to H.323. > B. What of the case where I have multiple SIP service providers... I have > sip based IM from Microsoft and a sip based service from ... iptel > ..whomever. What of the case where I as the ENUM registrant need to > distinguish between the two > > im:sip .....use this AoR > voice:sip ..use this AoR. > > the reason being that neither my sip based IM provider or SIP based voice > provider has the capability of negotiating a redirection since neither > service gives me the ability to configure my account appropriately. > That doesn't happen to be discussed in the mail to which you are replying (which was about the internals of my proposal, not "vovi"), but has been the subject of lengthy previous correspondence in this thread. A few (non-exhaustive) points about this: First, it is worth pointing out that if those condition arose, it would be a SIP problem, and one that is orthogonal to ENUM. If a SIP service doesn't give you the capability to register arbitrarily, it probably isn't SIP RFC compliant (by the book, registrars don't evaluate the contact addresses in registrations, and the manner in whch registrars accept, store and expire them is specified in some detail). iptel.org, for example, doesn't happen to have this problem. Planning our enumservices for SIP around non-compliant SIP implementations seems somewhat questionable. This problem is always solvable in SIP without resorting to any other protocol or mechanism to compose the URIs. Even if we could solve this problem with ENUM, then we would only have solved the problem for users that hold your telephone number, not for the users of native SIP URIs (who apparently would have to juggle two URIs). If SIP behaves differently when you use ENUM than when you use SIP without it, I think there's something wrong with the way we're leveraging ENUM. Finally, if we take the "vovi" proposal outside the context of solving an artificial constraint in SIP, it still has various internal coherence problems that have also been discussed in this thread (relating to the purpose of service labels, the efficacy of policies enforced by labels, and the question of how useful these labels are for expressing capabilities of SIP endpoints). By standardizing "vovi" labels for SIP we would be encouraging the use of these artificial constraints (service-specific AoRs) in SIP - essentially, encouraging non-standard SIP deployments and behavior. It would be like if the existence of an enumservice pointing to a web page changed something about how you provision or reach the page. I would have hoped that ENUM would be more transparent to the services it advertises - that it would be a directory of URIs learned from a telephone number. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 16:46:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15932 for ; Mon, 10 Mar 2003 16:46:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AM02E22340 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 17:00:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALxfO22239; Mon, 10 Mar 2003 16:59:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ALwPO22199 for ; Mon, 10 Mar 2003 16:58:25 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15744 for ; Mon, 10 Mar 2003 16:44:45 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2ALkQQ23753; Mon, 10 Mar 2003 13:46:26 -0800 Message-Id: <5.2.0.9.2.20030310150434.02bc3b98@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 16:46:48 -0500 To: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" From: Richard Shockey Subject: RE: [Enum] Questions Part 2 Cc: enum@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EE9@stntexch2.va.neus tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 02:56 PM 3/10/2003 -0500, Peterson, Jon wrote: >Answers part 2 below. > >Jon Peterson >NeuStar, Inc. > > > > > For purposes of clarity ... > > > >Yes, we need more of that, no doubt. I'm sorry if this debate has been >rather murky. I've been hoping to post a summary (for general consumption) >of the issues Mr. Conroy and I have been discussing soon. Maybe we can use >some SF agenda time for this...? We have time ..it is my hope to get all non contentious issues off the table first before diving into this. I suspect this is going to be the central issue in dispute... though clarifying the DNSSEC text and partial E.164 resolution in 2916bis is second and will be at the top of the agenda. We need to be clear on what needs to be corrected or rewritten in 2916bis so the authors can prepare 05 and we can immediately go to last call. This is the most important task the WG has in San Francisco. I think there is enough wiggle room here for compromise on language. > > A. I've seen no postings from authoritive H.323 types so I'm wondering if > > the discussion on SIP enumservice granularity ..is applicable for that > > protocol. The question then ..Is H.323 different enough from sip in the > > negotiation of capabilities that granularity aka voice:h323 is acceptable. > > > >I hope that Ms. Levin or other advocates of H.323 enumservice proposals can >speak to that. I do think that the treatment of URIs and registration in >H.323 is different, and therefore it is conceivable different conclusions >could apply to H.323. Which was precisely the reason for my question. Clarity on the differences here between H.323 and SIP CU/A will be helpful. I'm personally not taking a position one way or another ..only that if there is substantive differences or similarities I'd like the list to see those flushed out. > > B. What of the case where I have multiple SIP service providers... I have > > sip based IM from Microsoft and a sip based service from ... iptel > > ..whomever. What of the case where I as the ENUM registrant need to > > distinguish between the two > > > > im:sip .....use this AoR > > voice:sip ..use this AoR. > > > > the reason being that neither my sip based IM provider or SIP based voice > > provider has the capability of negotiating a redirection since neither > > service gives me the ability to configure my account appropriately. > > > >That doesn't happen to be discussed in the mail to which you are replying >(which was about the internals of my proposal, not "vovi"), but has been the >subject of lengthy previous correspondence in this thread. A few >(non-exhaustive) points about this: > >First, it is worth pointing out that if those condition arose, it would be a >SIP problem, and one that is orthogonal to ENUM. If a SIP service doesn't >give you the capability to register arbitrarily, it probably isn't SIP RFC >compliant (by the book, registrars don't evaluate the contact addresses in >registrations, and the manner in whch registrars accept, store and expire >them is specified in some detail). iptel.org, for example, doesn't happen to >have this problem. Planning our enumservices for SIP around non-compliant >SIP implementations seems somewhat questionable. Well you see where I'm leading ... the discussion in previous messages was rather long with some "philosophical" undertones. I'm just trying to make sure we know exactly what the issue here is and the problem the "vovi" draft proports to solve as well as what SIP itself addresses. >This problem is always solvable in SIP without resorting to any other >protocol or mechanism to compose the URIs. Even if we could solve this >problem with ENUM, then we would only have solved the problem for users that >hold your telephone number, not for the users of native SIP URIs (who >apparently would have to juggle two URIs). If SIP behaves differently when >you use ENUM than when you use SIP without it, I think there's something >wrong with the way we're leveraging ENUM. > >Finally, if we take the "vovi" proposal outside the context of solving an >artificial constraint in SIP, it still has various internal coherence >problems that have also been discussed in this thread (relating to the >purpose of service labels, the efficacy of policies enforced by labels, and >the question of how useful these labels are for expressing capabilities of >SIP endpoints). I understand ..believe me. >By standardizing "vovi" labels for SIP we would be >encouraging the use of these artificial constraints (service-specific AoRs) >in SIP - essentially, encouraging non-standard SIP deployments and behavior. I understand your point, I've read the threads, but the clarity we should seek is practical. Realistically .. and this is a problem of ignorance with a variety of SIP C/UA implementations. We all know that I _should_ be able to register my SIP IM Client User Agent with any SIP proxy ..but as an example I can only REGISTER with one proxy in Windows Messenger. I cannot, therefore maintain a corporate Windows IM account using Windows Messenger and then REGISTER that C/UA again to another SIP server that deals with my personal AoR and ultimately bind that to my personal and E.164 number in ENUM. One of issues I see it is in the 1 to 1 relationship most SIP CU/A have with a proxy. This is not the case with most modern email clients that can be configured to handle multiple SMPT accounts. Were SIP CU/A able to REGISTER with multiple proxy's (now I'm ignorant here of other products) then I could see this whole argument as less interesting since a single CU/A could serve multiple AoR's and there map via ENUM to multiple TN's. The second issue is also practical .. given the input of a TN and the return of a NAPTR record with E2U+voice:sip it is also 'declares' to the calling party that the preference for communication is voice ..ergo do not even attempt to establish any other form of session since it is presumed that the called parties CU/A is either incapable or unwilling to accept sessions in any other form. That might be useful. Make no mistake ... the single SIP AoR is preferable for any number of reasons principally privacy but there are some cases ... >It would be like if the existence of an enumservice pointing to a web page >changed something about how you provision or reach the page. I would have >hoped that ENUM would be more transparent to the services it advertises - >that it would be a directory of URIs learned from a telephone number. > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > > or > > ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 10 20:36:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23467 for ; Mon, 10 Mar 2003 20:36:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B1o2Z06128 for enum-archive@odin.ietf.org; Mon, 10 Mar 2003 20:50:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1nsO06112; Mon, 10 Mar 2003 20:49:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B1mFO06064 for ; Mon, 10 Mar 2003 20:48:15 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23408 for ; Mon, 10 Mar 2003 20:34:31 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2B1aWC25895; Tue, 11 Mar 2003 01:36:32 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 20:36:45 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EF2@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Richard Shockey'" Cc: enum@ietf.org Subject: RE: [Enum] Questions Part 2 Date: Mon, 10 Mar 2003 20:36:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > [snip] > [JFP]: > >By standardizing "vovi" labels for SIP we would be > >encouraging the use of these artificial constraints (service-specific AoRs) > >in SIP - essentially, encouraging non-standard SIP deployments and behavior. > > I understand your point, I've read the threads, but the clarity we should > seek is practical. > > Realistically .. and this is a problem of ignorance with a variety of SIP > C/UA implementations. We all know that I _should_ be able to register my > SIP IM Client User Agent with any SIP proxy ..but as an example I can only > REGISTER with one proxy in Windows Messenger. I cannot, therefore maintain > a corporate Windows IM account using Windows Messenger and then REGISTER > that C/UA again to another SIP server that deals with my personal AoR and > ultimately bind that to my personal and E.164 number in ENUM. > Right, but my argument is not dependent on a SIP device being able to register its contact address under multiple AoRs (although many can). If your SIP IM client registers under the AoR sip:rshock@neustar.biz, that AoR can in turn be registered under your personal AoR - that's what I'm saying. The results will be the same - requests will trickle down from your personal AoR to your NeuStar AoR, and from there to your IM client. This does not mean that IM client needs to register itself under your personal AoR. As an aside, note that your IM client does also have voice capabilities (if it is indeed Windows Messenger), so the idea of ascribing a single service like 'voice' to it is somewhat suspect. > One of issues I see it is in the 1 to 1 relationship most SIP CU/A have > with a proxy. This is not the case with most modern email clients that can > be configured to handle multiple SMPT accounts. > I'm not sure I would say 'most' SIP UAs have a 1-to-1 relationship. On the FWD dialup mailing list, there has been a lot of discussion about registering SIP clients under multiple registrars. Anyway, my Cisco 7960 is registered under multiple AoRs right now. But again, this is not particularly material to my argument. > Were SIP CU/A able to REGISTER with multiple proxy's (now I'm ignorant here > of other products) then I could see this whole argument as less interesting > since a single CU/A could serve multiple AoR's and there map via ENUM to > multiple TN's. > Since AoRs are stackable, a single SIP UA can be reachable under multiple AoRs even if the UA only registers in one place. A single TN can map to the 'umbrella' AoR and reach all of the AoRs below it; there isn't really a need for multiple TNs to map to multiple AoRs. That doesn't mean that multiple TNs (i.e. different ENUM resource record sets) under your control can't all map SIP enumservices to the same AoR, or to different AoRs, if you like, though. > The second issue is also practical .. given the input of a TN and the > return of a NAPTR record with E2U+voice:sip it is also 'declares' to the > calling party that the preference for communication is voice ..ergo do not > even attempt to establish any other form of session since it is presumed > that the called parties CU/A is either incapable or unwilling to accept > sessions in any other form. That might be useful. > Well, but here's the rub: when you pass the URI from the E2U+voice:sip NAPTR record to the SIP application, is it forbidden for the UAC to offer SDP that contains non-voice media lines? If so, that's a significant change in SIP behavior (in which there's no such restriction on what you can offer to a given URI), and it moreover assumes a tightly-composed architecture for your DDDS resolver and SIP client. I think enumservices should work even if we assume that the rewrite is passed to an application that is decoupled from the resolver (granted that of course, the resolver must know what enumservices it's looking for). Once someone learns a URI through ENUM, they should be able to do anything with that URI that they'd be able to do with it if they read the URI on a web page, in my opinion. Otherwise ENUM becomes something more oppressive than just a directory service. If you have a preference for voice communications, that preference can be enforced by the SDP answer of your user agent server in a much more powerful manner. There are also means by which it can be enforced by your proxy server (though with less strict controls). It can even be enforced (to a yet more limited degree) by certain structures that appear in the URI you acquire from ENUM. But the UAS and proxy have a real-time awareness of your current capabilities that ENUM, and the data it contains, will not realistically possess. I would argue that this flexibility and real-time responsiveness is even more useful than labels, and that short-circuiting SIP with stale information in ENUM is harmful. This harmfulness can cause communication attempts to fail that should succeed, and does not prevent effectively unwanted communication attempts, as I've illustrated in practical examples in this thread. > Make no mistake ... the single SIP AoR is preferable for any number of > reasons principally privacy but there are some cases ... > > >It would be like if the existence of an enumservice pointing to a web page > >changed something about how you provision or reach the page. I would have > >hoped that ENUM would be more transparent to the services it advertises - > >that it would be a directory of URIs learned from a telephone number. > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > > NeuStar Inc. > > > 46000 Center Oak Plaza - Sterling, VA 20166 > > > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 > 815.333.1237 > > > or > > > > ; > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 11 15:10:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09338 for ; Tue, 11 Mar 2003 15:10:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BKNx529062 for enum-archive@odin.ietf.org; Tue, 11 Mar 2003 15:23:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKNrO29057; Tue, 11 Mar 2003 15:23:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BKMLO29008 for ; Tue, 11 Mar 2003 15:22:21 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08976 for ; Tue, 11 Mar 2003 15:08:12 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 11 Mar 2003 01:47:01 -0500 Subject: RE: [Enum] Questions Part 2 From: Michael Mealling To: "Peterson, Jon" Cc: "'Richard Shockey'" , "'Conroy, Lawrence \"\"(SMTP)'" , enum@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EE9@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EE9@stntexch2.va.neustar.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1047413381.1205.70.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2003 15:09:42 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2003-03-10 at 14:56, Peterson, Jon wrote: > > Finally, if we take the "vovi" proposal outside the context of solving an > artificial constraint in SIP, it still has various internal coherence > problems that have also been discussed in this thread (relating to the > purpose of service labels, the efficacy of policies enforced by labels, and > the question of how useful these labels are for expressing capabilities of > SIP endpoints). By standardizing "vovi" labels for SIP we would be > encouraging the use of these artificial constraints (service-specific AoRs) > in SIP - essentially, encouraging non-standard SIP deployments and behavior. Not non-standard, just alternative methods of getting to a SIP server. > It would be like if the existence of an enumservice pointing to a web page > changed something about how you provision or reach the page. I would have > hoped that ENUM would be more transparent to the services it advertises - > that it would be a directory of URIs learned from a telephone number. This is exactly what we did with the URI Resolution DDDS application. Given 'http://bar.foo.com/baz/foobaz' you can use two methods to get to the HTML resource bound to that URI. You can use the 'http:' standard method (get the A record for the host part and connect to that host via HTTP and request the page) or you can destruct the URI by looking up NAPTR records starting at http.uri.arpa. Once you find a terminal NAPTR you contact that server via some metadata protocol and ask it where you can find a copy of that resource. If you look at the HTTP standard it doesn't mention anything about using the DDDS. Does that make the URI Resolution Application invalid? No. Its just another method of finding out about the thing associated with some identifier. The URI Resolution application was always intended to be the method of last resort. If you received a 404 Not Found you could use the DDDS method to find someone who could tell you where it got moved to. With respect to ENUM, I think that's also valid to have multiple methods for getting information/services associated with some TN. I think its extremely dangerous for protocol specs to make applicability statements about things external to the actual on the wire use of identifiers. Especially if that protocol can deal with generic URI schemes. IMNSHO, SIP can suggest that SIP works best when one AoR is used and all, but it should not be allowed to make applicability statements about other systems that may choose to treat identifiers differently and which may desire to inter-operate with SIP. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 11 17:09:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14659 for ; Tue, 11 Mar 2003 17:09:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BMNJ305838 for enum-archive@odin.ietf.org; Tue, 11 Mar 2003 17:23:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMN1O05810; Tue, 11 Mar 2003 17:23:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMLmO05741 for ; Tue, 11 Mar 2003 17:21:48 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14551 for ; Tue, 11 Mar 2003 17:07:38 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2BM99C12439; Tue, 11 Mar 2003 22:09:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 17:09:23 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214EFE@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Mealling'" Cc: "'Richard Shockey'" , "'Conroy, Lawrence \"\"(SMTP)'" , enum@ietf.org Subject: RE: [Enum] Questions Part 2 Date: Tue, 11 Mar 2003 17:09:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , More, as always, below. Jon Peterson NeuStar, Inc > -----Original Message----- > From: Michael Mealling [mailto:michael@neonym.net] > Sent: Tuesday, March 11, 2003 12:10 PM > To: Peterson, Jon > Cc: 'Richard Shockey'; 'Conroy, Lawrence ""(SMTP)'; enum@ietf.org > Subject: RE: [Enum] Questions Part 2 > > > On Mon, 2003-03-10 at 14:56, Peterson, Jon wrote: > > > [snip] > > By standardizing "vovi" labels for SIP we would be > > encouraging the use of these artificial constraints (service-specific AoRs) > > in SIP - essentially, encouraging non-standard SIP deployments and behavior. > > Not non-standard, just alternative methods of getting to a SIP server. > Non-standard in the not-insignificant sense that RFC3261-compliant user agents behave differently than the "vovi" draft would like them to. Non-standard in the sense that because you used a different method to get to the server, you need to make different requests than you might have otherwise. > > It would be like if the existence of an enumservice pointing to a web page > > changed something about how you provision or reach the page. > > This is exactly what we did with the URI Resolution DDDS application. > Given 'http://bar.foo.com/baz/foobaz' you can use two methods to get to > the HTML resource bound to that URI. You can use the 'http:' standard > method (get the A record for the host part and connect to that host via > HTTP and request the page) or you can destruct the URI by looking up > NAPTR records starting at http.uri.arpa. Once you find a terminal NAPTR > you contact that server via some metadata protocol and ask it where you > can find a copy of that resource. If you look at the HTTP standard it > doesn't mention anything about using the DDDS. Does that make the URI > Resolution Application invalid? No. Its just another method of finding > out about the thing associated with some identifier. > I hear what you're saying, but I intended my analogy to be a little more narrow than that. To my mind, it would be like if, depending on whether you found the HTTP server using the A record method or the NAPTR method, it changed whether or not you could send POST requests to the HTTP server, and moreover what kind of information was allowed to appear on any web pages you got from the web server. The analogy would have to change something internal to HTTP, the way that "vovi" changes things that are internal to SIP. There's nothing wrong with your analysis of the web server case above, though. I would note that we in the SIP community found it necessary and useful to specify in our own standard the proper use of NAPTR records (as a first resort) for discovering SIP resources in addition to an A record method - perhaps if HTTP were to be revised today, they would do the same. > The URI Resolution application was always intended to be the method of > last resort. If you received a 404 Not Found you could use the DDDS > method to find someone who could tell you where it got moved to. With > respect to ENUM, I think that's also valid to have multiple methods for > getting information/services associated with some TN. > Well, not that I want to challenge anything about how HTTP and DDDS interact, but let me play devil's advocate, here. If a resource gets moved in HTTP, hopefully the server will use 3xx to tell you of that rather than giving you a 404 and forcing you to go back to the DNS. Otherwise, what would happen when people use the A record method, and not DDDS, try to hit the web page - DDDS leads to a redirection, the A record to a failure? Do you want the behavior for those that use the A method to result in one web page, and the DDDS method another? You could guarantee the same behavior by just sending 3xx from the HTTP server. What are the implications for the use of HTTP if redirection is handled intermittently by the DNS, depending on the URI resolution capabilities of the client? Consider the following text from RFC2616 section 10.3.2 (which describes client behavior on receipt of 301): Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. This text suggests that there is some benefit for clients in receiving an HTTP redirection that might not be realized by redirecting in the DNS. So what are the benefits of the DDDS way? I've been applying roughly the same argument to SIP and ENUM in this thread. Except ENUM, unlike DDDS, is not a general URI resolution system - ENUM is only invoked under very specific conditions (when you happen to hold a telephone number). I think the argument is even stronger in that case. > I think its extremely dangerous for protocol specs to make applicability > statements about things external to the actual on the wire use of > identifiers. Especially if that protocol can deal with generic URI > schemes. IMNSHO, SIP can suggest that SIP works best when one AoR is > used and all, but it should not be allowed to make applicability > statements about other systems that may choose to treat identifiers > differently and which may desire to inter-operate with SIP. > I agree that it's important that we only say that SIP works best when you use AoRs and not contact addresses, and so forth, rather than mandating something. I think to some degree you're right, I am suggesting an applicability statement about the use of SIP URIs. But the point is, I'm doing this in the context of two proposals in front of this WG at the moment - let's set aside for the moment whether they are compatible or competitive. The 'E2U+sip' proposal is sufficient, in my estimation, as an enumservice for SIP - and we appear to have some consensus to go forward with this proposal (i.e. this document is currently a WG item). So no one is saying that ENUM and SIP shouldn't interoperate. This is much more specific question of how ENUM and SIP should interoperate. Clearly it's possible that some ways are better than others (I can think of some really terrible ways no one has proposed yet), and I've put forward ramifications (for SIP behavior) of choosing one approach rather than another. The question is what we should standardize here in the IETF. Perhaps this need for applicability arises from the fact that SIP's use of URIs (as opaque identifiers behind which services and capabilities can change in real-time) is irregular. I don't know if there are other protocols that use URIs in the same way. I'm not sure, though, why we would necessarily think it's legitimate to 'treat identifiers differently' than they were intended for any protocol. I would think that there are risks that could arise from that, and in this particular thread it would seem there are some significant problems that result from treating SIP's identifiers as if they signified something other than what they do. SIP AoR URIs are identities that serve as a conduit to a resource discovery and session negotiation protocol. > -MM > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 11 20:50:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22568 for ; Tue, 11 Mar 2003 20:50:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C23qF21454 for enum-archive@odin.ietf.org; Tue, 11 Mar 2003 21:03:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C23mO21445; Tue, 11 Mar 2003 21:03:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C22YO21423 for ; Tue, 11 Mar 2003 21:02:34 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22550 for ; Tue, 11 Mar 2003 20:48:18 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 01:50:26 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8A4WQ; Wed, 12 Mar 2003 01:50:22 -0000 From: "Conroy, Lawrence (SMTP)" To: Jon , Michael , Rich Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Wed, 12 Mar 2003 01:50:18 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: Questions Part 2 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Jon, Michael, Rich, Folks, OK - internally incoherent, the assertion that ascribing only one service to Windows Messenger is suspect when I still can't get my ******* iMic to work with VirtualPC and Windows Messenger so it IS only capable of handling IM, and finally that a SIP UA does not behave as the 'vovi' draft would like it to - I'll bite. There are two options when an entry has a Teleservice Label. Either: The label is purely an item "for display" that is presented to an end user when they "break the tie" in a DDDS round with no further action or interpretation on the part of the DDDS client program, Or.. there is some mandatory feature, in which case the DDDS client will NOT present an entry that is so tagged if either the end user has pre-specified that they are not interested in this teleservice, or the local equipment is incapable of supporting the tagged teleservice. In the latter case there ARE some real issues, and we have been discussing the minutiae of these for some time. My reason for exploring these (at some length) is that several groups out in the R.W. have suggested that an end user might be allowed to pre-select the teleservices they're interested in with a "user-friendly" ENUM client and provisioning systems, in which case any entry that isn't identifiable as being tied to a teleservice or that isn't tagged with some teleservice label will be discarded. Whether I think it's a good idea or not, I believe that these clients will be released simply because the marketing folk think that "Joe Punter" just about understands 'voice' or 'video' or 'fax' or 'email' or 'sms' but that plain 'sip' is going to look like 'pandora's box'; it's going to be hard to explain that this is a special case, and you can't know in advance what you're going to get. Will such a filtering system have odd side effects? - quite probably and it's something I've been trying to get my head around, with Jon's help. This is made more fun by working out how to explain that you only need one AoR and Mr. Punter should combine them with iptel.org, or that a Telecomms group in a company is not going to be in a turf war (with different preferred suppliers) from the IT group, and that they shouldn't both be arguing over who gets to control the ALG(s) and who has to open what pinholes on whose say so. However, back to 'vovi'... In the former "permissive" or "soft hint" case we originally envisaged in "vovi", the labels are not used to filter entries where an end user has made some pre-selected choice or where local equipment is incapable of handling the tagged teleservice. The end system may still filter out those protocols that it cannot handle, of course, so some tagged entries may not be presented for other reasons. Also, the end system MAY use the labels (or lack of them) to highlight or sequence presentation of the entries to the end user; this is purely a matter of local implementation and not subject to protocol standardisation as it doesn't affect DDDS operation. I think that, in this case, the beef seems to be that the label, when tagged to an entry that uses the SIP protocol, may not be valid or useful. An AoR is not intrinsically associated with any teleservice. The argument would seem to be that the IETF should not condone indications that are (or may be) invalid. The counter-argument is that the label can be argued to be purely a matter between the Registrant and the End User, with the "ENUM protocol" merely carrying this data. Thus the validity or otherwise (or even the sense in labelling an entry) is not a protocol issue. The Registrant could equally label an entry "pink" as far as DDDS is concerned. The AoR MAY happen to be associated with a teleservice only by administrative (non-technical) means, but that is an issue for the Registrant who applies the label and registers their presence with SIP devices of that given capability, not of SIP infrastructure or of ENUM and the DDDS client. If the Registrant labels an entry, then they SHOULD ensure that devices capable of supporting that teleservice are available "behind" that AoR, so that the standard negotiation mechanisms will resolve to the indicated service. That is what was meant in section 3.2 and 4.2 (albeit stated that offering other services SHOULD not happen). The SHOULD NOT was intended to occur purely because the Registrant had arranged for the labelled teleservice to be supported. The onus is on them to register devices that support the labelled teleservice. If they don't, then the ENUM user MAY be offered another type of communication, as it says there. Given that there is no impact on "ENUM protocol" operation, you know which way I would move, were I voting in this County today. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 12 00:23:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26736 for ; Wed, 12 Mar 2003 00:23:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C5b1o02004 for enum-archive@odin.ietf.org; Wed, 12 Mar 2003 00:37:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5avO01949; Wed, 12 Mar 2003 00:36:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5ZBO01898 for ; Wed, 12 Mar 2003 00:35:11 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26715 for ; Wed, 12 Mar 2003 00:20:52 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18syhd-0005sz-00; Wed, 12 Mar 2003 07:22:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15982.50225.556597.580963@harjus.eng.song.fi> Date: Wed, 12 Mar 2003 07:22:57 +0200 To: "Peterson, Jon" Cc: "'Michael Mealling'" , "'Richard Shockey'" , "'Conroy, Lawrence \"\"(SMTP)'" , enum@ietf.org Subject: RE: [Enum] Questions Part 2 In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214EFE@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214EFE@stntexch2.va.neustar.com> X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Non-standard in the sense that because you used a different method to > get to the server, you need to make different requests than you might have > otherwise. this started when i was asked to add voice:sip and video:sip support to the enum module of a sip proxy. in many cases enum lookups are done by proxies and not directly by sip uas (many of which don't today have enum lookup capabilities). without caller preferences in the request (which is the normal case today) what should my proxy do if it finds both voice:sip and voice:video record for the aor of an invite? should it scan the sdp of the invite in order to find out if it contains mlines for video or voice? what if it has both? in any case, the result is behavior which is very different from how sip proxies work today. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 12 05:05:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27767 for ; Wed, 12 Mar 2003 05:05:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CAJ2930944 for enum-archive@odin.ietf.org; Wed, 12 Mar 2003 05:19:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CAIwO30935; Wed, 12 Mar 2003 05:18:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CAGBO30849 for ; Wed, 12 Mar 2003 05:16:11 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27751 for ; Wed, 12 Mar 2003 05:01:46 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 10:03:54 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNK8AVF1; Wed, 12 Mar 2003 10:03:50 -0000 From: "Conroy, Lawrence (SMTP)" To: jh@lohi.eng.song.fi, Jon Cc: Michael , Rich , enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <15982.50225.556597.580963@harjus.eng.song.fi> References: <15A2739B7DAA624D8091C65981D7DA8101214EFE@stntexch2.va.neustar.com> <15982.50225.556597.580963@harjus.eng.song.fi> Date: Wed, 12 Mar 2003 10:03:45 +0000 Subject: RE: [Enum] Questions Part 2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 7:22 am +0200 12/3/03, jh@lohi.eng.song.fi wrote: >Peterson, Jon writes: > > > Non-standard in the sense that because you used a different method to > > get to the server, you need to make different requests than you might have > > otherwise. > >this started when i was asked to add voice:sip and video:sip support to >the enum module of a sip proxy. in many cases enum lookups are done by >proxies and not directly by sip uas (many of which don't today have enum >lookup capabilities). > >without caller preferences in the request (which is the normal case >today) what should my proxy do if it finds both voice:sip and >voice:video record for the aor of an invite? should it scan the sdp of >the invite in order to find out if it contains mlines for video or >voice? what if it has both? in any case, the result is behavior which >is very different from how sip proxies work today. > >-- juha To which I reply: Good Morning Juha, folks, One thing's for sure, with the PUA you are not going to do the "interactive" tie-breaking that has been discussed. The proxy still resolves a destination address the same as it always has - in this case it has an E.164 number and so needs to do an ENUM lookup. It doesn't HAVE an AoR at this point. First, a side-comment: in the following text I'm making the assumption that the proxy has a valid DDDS client, and so the DDDS round will complete with a single Result. Thus, if there are two sip entries, the proxy doesn't just fork to them both. See 2916bis-04 section 2.6 for a clarification on Note 1 of RFC3402. In particular, pargraph 3 applies to the Proxy. The proxy doesn't have a local end user to break the tie in a DDDS round (from the Order fields being the same value) so it uses the standard approach of taking the entry with the "best" preference field value. This whole discussion has been on the last two paragraphs of section 1.3 of 2916bis-04, and in particular the last sentence. The standard SIP proxy has no local policy, so I wouldn't expect it to over-ride the preference field value. Not having a local end user to whom to present all of the NAPTRs for "tie breaking", the proxy falls back to using preference as a tie breaker. I'm sure that there are other views on this, but that process will work as it always has. In this case, 'voice:sip" and 'video:sip' are treated exactly the same as plain, unlabeled 'sip'. In your case of having both a 'voice:sip' and a 'video:sip' entry in ENUM for the E.164 number you have, then you have two SIP AoRs...select based on preference field value for these entries. (BTW, I hope you meant "video:sip" rather than "voice:video" - if not then you're on your own :). all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 12 05:55:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28982 for ; Wed, 12 Mar 2003 05:55:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CB9Tq02771 for enum-archive@odin.ietf.org; Wed, 12 Mar 2003 06:09:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CB9SO02766; Wed, 12 Mar 2003 06:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CB8lO02737 for ; Wed, 12 Mar 2003 06:08:47 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28952 for ; Wed, 12 Mar 2003 05:54:21 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2CAtdC19329; Wed, 12 Mar 2003 10:55:39 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 05:55:54 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214F06@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "Peterson, Jon" , Michael , Rich Cc: enum@ietf.org Date: Wed, 12 Mar 2003 05:55:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] RE: Questions Part 2 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Feeling somewhat Energizer-rabbit-like but, more within. Michael, I'd appreciate it if you would comment on the first issue. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Tuesday, March 11, 2003 5:50 PM > To: Jon; Michael; Rich > Cc: enum@ietf.org > Subject: Re: Questions Part 2 > [snip] > There are two options when an entry has a Teleservice Label. > Either: > The label is purely an item "for display" that is presented to an end > user when they "break the tie" in a DDDS round with no further action or > interpretation on the part of the DDDS client program, > Or.. > there is some mandatory feature, in which case the DDDS client will NOT > present an entry that is so tagged if either the end user has > pre-specified that they are not interested in this teleservice, or the > local equipment is incapable of supporting the tagged teleservice. > Well, let's be more specific. A 'teleservice label' is part of the string that constitutes an enumservice. Enumservices are not 'hints' - they are literal strings, and either you match them or you don't. DDDS is quite specific about this matter. So I guess the first of your two options above is immediately disqualified... or is it? I think the text in rfc2916bis 2.6 could appear to qualify this point in its description of an 'intelligent' resolver. Essentially, the intelligent resolver text clarifies the meaning of Step 4 of the DDDS algorithm a bit, in so far as it suggests that the process of selecting Rules based on service may involve GUI calls, etc. However, I didn't take 2.6 to mean that enumservices themselves were ignored at the client's discretion. I'm not sure that it means that "intelligent" resolvers have no list of supported enumservices, and will thus display all NAPTR records to the user's GUI regardles of enumservice. Tie-breaking is one thing - that's a reasonable justification for a GUI event. But I've heard some other things in this thread that I'm not so comfortable with - like the idea that client that supports only SIP IM, say, might decide to try to use an 'E2U+voice:sip' enumservice, presumably based on some GUI selection. In that case, the GUI makes enumservices meaningless - it might as well just hand all the URIs over to the user and let them choose irrespective of enumservices. Even with the most generous interpretation of 2.6, I think that enumservices should be required to function for either an "intelligent" resolver or a "dumb" resolver. After all, the author of NATPR records has no way to anticipate whether clients that ask for records will have intelligent or dumb resolvers (ENUM is a public resource that anyone can access - it isn't constrained to an environment in which you have some assurance that all resolvers are smart). If there are problems with these enumservices for "dumb" resolvers, I think that's a problem for the whole proposal. Michael? > In the latter case there ARE some real issues, and we have been > discussing the minutiae of these for some time. My reason for exploring > these (at some length) is that several groups out in the R.W. have > suggested that an end user might be allowed to pre-select the > teleservices they're interested in with a "user-friendly" ENUM client and > provisioning systems, in which case any entry that isn't identifiable as > being tied to a teleservice or that isn't tagged with some teleservice > label will be discarded. > > Whether I think it's a good idea or not, I believe that these clients > will be released simply because the marketing folk think that "Joe > Punter" just about understands 'voice' or 'video' or 'fax' or 'email' or > 'sms' but that plain 'sip' is going to look like 'pandora's box'; it's > going to be hard to explain that this is a special case, and you can't > know in advance what you're going to get. > This is the IETF. We make standards. You have proposed a standard to the IETF that uses these labels. People out in the R.W., including marketing folk, are empowered to build ENUM products using whatever they like, including Limburger cheese. If we don't standardize these things, the sin is not on our head, anyway. > Will such a filtering system have odd side effects? - quite probably and > it's something I've been trying to get my head around, with Jon's help. > Glad to be of service. > This is made more fun by working out how to explain that you only need > one AoR and Mr. Punter should combine them with iptel.org, or that a > Telecomms group in a company is not going to be in a turf war (with > different preferred suppliers) from the IT group, and that they shouldn't > both be arguing over who gets to control the ALG(s) and who has to > open what pinholes on whose say so. > [As an aside - Actually, in my explanation of the example of Telecomms and IT I was very specific that firewall traversal is unchanged by the manner that URIs are composed in SIP. I don't know any simpler way to put it. If you go to IT, and they redirect you to Telecomms, the request will approach all of Telecomms systems, including their firewalls, just like any other request to Telecomms from the outside world. This does not raise any questions about control of firewalls or ALGs - that stays exactly as it is now.] > However, back to 'vovi'... > > In the former "permissive" or "soft hint" case we originally envisaged in > "vovi", the labels are not used to filter entries where an end user has made > some pre-selected choice or where local equipment is incapable of handling > the tagged teleservice. > > The end system may still filter out those protocols that it cannot > handle, of course, so some tagged entries may not be presented for other > reasons. > > Also, the end system MAY use the labels (or lack of them) to highlight > or sequence presentation of the entries to the end user; this is purely > a matter of local implementation and not subject to protocol > standardisation as it doesn't affect DDDS operation. > Right, I think I understand what you mean, though this is a greyish area for DDDS and ENUM, as I discuss above. > I think that, in this case, the beef seems to be that the label, when > tagged to an entry that uses the SIP protocol, may not be valid or > useful. An AoR is not intrinsically associated with any teleservice. The > argument would seem to be that the IETF should not condone indications > that are (or may be) invalid. > That's a big helping of the beef, anyway. Enough to chew on for one mail. > The counter-argument is that the label can be argued to be purely a > matter between the Registrant and the End User, with the "ENUM protocol" > merely carrying this data. Thus the validity or otherwise (or even the > sense in labelling an entry) is not a protocol issue. The Registrant > could equally label an entry "pink" as far as DDDS is concerned. > Well, of course the DNS just carries this data - ENUM queries return what has been provisioned. Agreed that users could provision the "E2U+cheese:limburger" enumservice in a NAPTR record, they just shouldn't expect anyone to be interoperable with it because it's unstandardized. Users can also put 'mailto' records for 'president@whitehouse.gov?Subject=@!%&?' in their NAPTR records, they just shouldn't expect to get any mail. I could take your argument to be that we should standardize the "vovi" labels on the grounds that people should be able to provision whatever they want in ENUM anyway. Or does this have any bearing on whether or not to standardize a label? More below... > The AoR MAY happen to be associated with a teleservice only by > administrative (non-technical) means, but that is an issue for the > Registrant who applies the label and registers their presence with SIP > devices of that given capability, not of SIP infrastructure or of ENUM > and the DDDS client. > The fact that when you apply a label to an enumservice, registrars shouldn't accept certain registrations is not a SIP infrastructure issue? The fact that when I acquire a record using one of these labels, my UAC should constrain the media types I offer is not a SIP infrastructure issue? Hmm. If we give people tools that make it easy for them to make mistakes or misunderstand the interactions of complicated sets of systems, we shouldn't be surprised when interoperability doesn't flourish. Pushing the responsibility for all of this on the end user, and making it their mistake if they use SIP normally, doesn't seem attractive to me. This also begs questions about the distinction you raised two paragraphs ago - the distinction between the Registrant and the End User. Is the user who provisions a record in ENUM that points to a given SIP URI also -necessarily- going to be the same user who controls any and all devices that might register under that SIP URI? There are numerous cases I can imagine in which that might not be the case. Some SIP AoRs represent groups instead of particular users, for example. Anyway, it's all well and good to say that he who provisions ENUM shouldn't take incompatible actions in SIP, but they needn't necessarily be the same bloke. > If the Registrant labels an entry, then they SHOULD ensure that devices > capable of supporting that teleservice are available "behind" that AoR, > so that the standard negotiation mechanisms will resolve to the > indicated service. > Well I agree, if the "vovi" enumservices are used they better ensure it - and that goes for devices that register under the URI, registrars that accept these registrations, and devices that offer requests to the URI. In the absence of the teleservice label (using the "E2U+sip" enumservice) these sorts of questions just don't arise. > That is what was meant in section 3.2 and 4.2 (albeit stated that > offering other services SHOULD not happen). The SHOULD NOT was intended > to occur purely because the Registrant had arranged for the labelled > teleservice to be supported. The onus is on them to register devices > that support the labelled teleservice. If they don't, then the ENUM user > MAY be offered another type of communication, as it says there. > Obviously, in the context of your proposal I think this is good advice, the question is whether or not it's enough. > Given that there is no impact on "ENUM protocol" operation, you know > which way I would move, were I voting in this County today. > > all the best, > Lawrence > -- > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is" > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 12 14:41:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17939 for ; Wed, 12 Mar 2003 14:41:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJu3i08100 for enum-archive@odin.ietf.org; Wed, 12 Mar 2003 14:56:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJtuO08092; Wed, 12 Mar 2003 14:55:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJs6O08019 for ; Wed, 12 Mar 2003 14:54:06 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17870 for ; Wed, 12 Mar 2003 14:39:29 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 14:40:04 -0500 Message-ID: From: Orit Levin To: enum@ietf.org Date: Wed, 12 Mar 2003 14:40:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Enum] VOVI and H.323 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi guys! My answer is that I don't see major conceptual differences between SIP and H.323 in respect to this long thread. For those who would like to read the details, they are provided at the bottom of the mail. My opinion is that both protocols should be addressed by ENUM in the same way. I also think that a clarification about the main ENUM motivation(s) and consequently the prevalent ENUM usage cases would contribute to a more focused discussion than the technical details of the call signaling protocols. What is the ENUM's objective? 1. Being an enabler for smooth user experience in communications involving GWs? [i.e involving non-IP users who are identified by a phone number only (for incoming calls) and are restricted to dialing phone numbers only (for outgoing calls).] 2. Being an enabler for using phone numbers (instead of URIs) for pure IP phones/services? 3. Both? At what ratio? --------------------------------------------------------- I would like to clarify two H.323 specifics that have been referred to during the VOVI thread and are different from SIP: 1. H.323 as a standard doesn't distinguish between a user and its device(s). An H.323 entity can represent either and can be identified by an array of "identifiers" - among them ASCII string, phone number, ...., URI. Gatekeepers (i.e. statefull signaling proxies) are allowed for any ID interpretation, substitution, association, routing, forking, line-hunting, load balancing, etc. (Gatekeeper can also assign a new identifier to an H.323 entity and the "entity" MUST use it.) That said, in practice, it works very much like SIP. H.323 device REGISTERs with its ID (name). The Gatekeeper makes an association between the devices under its responsibility (and registration) and the users/services (using any sort of DB and containing local policies). When an H.323 call is placed from the outside of the Gatekeeper authority (i.e. zone), the call would usually be destined either to a user (not a device) or to a service (such as "conferenecing"). At this point the GK performs the mapping between the user/service and its current available/suitable device. 2. In H.323, you can NOT express media (voice/video/data) capabilities or preferences using the REGISTRATION procedure or retrieve them afterwards (using LOCATION requests). You do it only during a call establishment (where the expression granularity is very high)... That said the Gatekeeper usually knows the preferences and the capabilities of its users since it is an important part of the (preconfigured) local policy. Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 13 15:20:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17475 for ; Thu, 13 Mar 2003 15:20:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DKZCq28252 for enum-archive@odin.ietf.org; Thu, 13 Mar 2003 15:35:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKYtO28229; Thu, 13 Mar 2003 15:34:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKXTO28164 for ; Thu, 13 Mar 2003 15:33:29 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17404 for ; Thu, 13 Mar 2003 15:18:23 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2DKKGQ27216 for ; Thu, 13 Mar 2003 12:20:16 -0800 Message-Id: <5.2.0.9.2.20030313151951.02c457e8@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 15:20:44 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I'm still looking for a scribe for WG Meeting in SF Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Would anyone like to volunteer now .. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 14 05:09:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20803 for ; Fri, 14 Mar 2003 05:09:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EAOTe30832 for enum-archive@odin.ietf.org; Fri, 14 Mar 2003 05:24:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EAO8O30817; Fri, 14 Mar 2003 05:24:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EAMEO30747 for ; Fri, 14 Mar 2003 05:22:14 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20762 for ; Fri, 14 Mar 2003 05:06:50 -0500 (EST) From: Ville.Warsta@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EACVF11938 for ; Fri, 14 Mar 2003 12:12:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Mar 2003 12:09:02 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Mar 2003 12:09:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 14 Mar 2003 12:09:00 +0200 Message-ID: Thread-Topic: Comments about draft-brandner-enumservice-msg-00.txt Thread-Index: AcLppPIOLzGtOrCmSsmGG69FLw70bAAbG9bg To: X-OriginalArrivalTime: 14 Mar 2003 10:09:00.0713 (UTC) FILETIME=[BBDF9190:01C2EA11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EAMFO30748 Subject: [Enum] Comments about draft-brandner-enumservice-msg-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I have some comments regarding the I-D draft-brandner-enumservice-msg-00.txt. In sections 5.2 and 5.3 the services "SMS" and "EMS" are proposed to be registered. EMS uses the same infrastructure and bearer as SMS -- In fact EMS in practise just means that some additional content has been standardised to be carried over the SMS bearer besides plain text or unspecified binary data. However, the problem is that EMS was extended with new functionality over a period of time with several releases of the specification released by 3GPP. A terminal supporting the 3GPP REL-99 version of TS23.040 (Technical Specification that defines both SMS and the additional EMS content) is not able to show or render new types of content defined in 3GPP REL-5 version of TS23.040. Also, the EMS additions have been defined in such a way that one can do cherry picking -- only choose to implement certain features. Based on this I don't see much use to have the separate service "ems" defined. Your only safe bet is that the recipient supports SMS. For a "fascinating" reading exercise, the latest version of TS23.040 can be found from http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-551.zip I went through last year's mail archives and couldn't find any discussion about adding EMS as a service type, but I apologize if this opens up an old, buried thread. Another comment I have is about the sentence Note that an indication of MMS can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. in 5.4. I don't think this statement is necessarily true. What should be said here is that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if for example the SMS bearer is not supported. While in practise all terminals supporting MMS today support SMS as well, it might not necessarily be the case in the future. [from TS23.140, MMS Stage 2, version 5.5.0: 5.1.2.1 Interoperability with SMS In order to guarantee SMS interoperability, SMS 3GPP TS 24.011 [11] RP-DATA RPDU encapsulation defined in clause 7.3.1 shall be supported. MIME type "application/vnd.3gpp.sms" shall be used for this purpose. In order to maintain backward compatibility, MIME type "application/x-sms" shall be supported by the MMS UA for mobile-terminated messages only. The spec can be found from http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23140-550.zip ] As last thing, a short comment about abbreviations: The E in EMS is Enhanced, not Extended, "Enhanced Messaging Service", and MMS is "Multimedia Messaging Service". Best regards, Ville Warsta _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 14 06:59:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23168 for ; Fri, 14 Mar 2003 06:59:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ECEZK05511 for enum-archive@odin.ietf.org; Fri, 14 Mar 2003 07:14:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECEUO05506; Fri, 14 Mar 2003 07:14:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ECDpO05464 for ; Fri, 14 Mar 2003 07:13:51 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23159 for ; Fri, 14 Mar 2003 06:58:25 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 12:00:34 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6W73XM5; Fri, 14 Mar 2003 12:00:22 -0000 From: "Conroy, Lawrence (SMTP)" To: Ville.Warsta@nokia.com, Rudi on the road Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 14 Mar 2003 12:00:09 +0000 Subject: Re: [Enum] Comments about draft-brandner-enumservice-msg-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Ville, Folks, many thanks for working through the msg draft, and for the clarifications - particularly finding the mangled EMS and MMS definitions and pointing out the References. Great! I wholeheartedly agree that EMS was not as "standard" as either SMS or MMS. To be honest, it's not something that I expect to be important in the future. IMHO, it does have some major inter-operability problems due to the "cherry picking of features" that you mention. The current discussions (in GERAN, for example) make me wonder if R5/R6+ will ever complete and be rolled out, but that's another story. We included SMS to indicate a "pure" SMS compliant service only must be expected at this end point (i.e. DON'T try to use EMS), and added EMS as an option for people whose system claims to support it and want to try it. The EMS service tag is only because EMS exists "out there" now. I must say that some features of EMS are quite commonly implemented, and it is these where we expected it to be used - extended texts, for example. As you hint, some companies make a bigger "push" on EMS than others. I would leave it in through politeness; their customers are more likely to specify this as Registrants than any others (and it is their customers who are more likely to be interested in trying this as end users :). As for MMS not being guaranteed to support EMS or SMS in the future... well, yes, that's strictly true, but do you really believe that the MMS systems and 3G R5 and beyond phones will not support SMS in the short term or even the medium term; there is a demand for this and I'd be amazed if a phone didn't - certainly yours does, as does ours ;). In the longer term the only reason for lack of SMS or EMS support is that it is no longer used, and everyone has swapped over to using an MMS capable 'phone. I hope this happens sooner rather than later, if only for the IMS support. We will be happy to add your text in the next version; you have spelled out exactly what is going on in better terms than I could have done, for which many thanks. all the best, Lawrence At 12:09 pm +0200 14/3/03, Ville.Warsta@nokia.com wrote: >Hi, > >I have some comments regarding the I-D >draft-brandner-enumservice-msg-00.txt. > >In sections 5.2 and 5.3 the services "SMS" and "EMS" are proposed to >be registered. > >EMS uses the same infrastructure and bearer as SMS -- In fact EMS in >practise just means that some additional content has been standardised >to be carried over the SMS bearer besides plain text or unspecified >binary data. > >However, the problem is that EMS was extended with new functionality >over a period of time with several releases of the specification >released by 3GPP. A terminal supporting the 3GPP REL-99 version of >TS23.040 (Technical Specification that defines both SMS and the >additional EMS content) is not able to show or render new types of >content defined in 3GPP REL-5 version of TS23.040. Also, the EMS >additions have been defined in such a way that one can do cherry >picking -- only choose to implement certain features. > >Based on this I don't see much use to have the separate service "ems" >defined. Your only safe bet is that the recipient supports SMS. > >For a "fascinating" reading exercise, the latest version of TS23.040 >can be found from >http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-551.zip > >I went through last year's mail archives and couldn't find any >discussion about adding EMS as a service type, but I apologize if this >opens up an old, buried thread. > >Another comment I have is about the sentence > > Note that an indication of MMS can be taken as implying that the > recipient is capable of receiving EMS or SMS messages at this > address. > >in 5.4. I don't think this statement is necessarily true. What should >be said here is that MMS can be used as an alternative to deliver an >SMS RP-DATA RPDU if for example the SMS bearer is not supported. >While in practise all terminals supporting MMS today support SMS as well, >it might not necessarily be the case in the future. > >[from TS23.140, MMS Stage 2, version 5.5.0: > >5.1.2.1 Interoperability with SMS > > In order to guarantee SMS interoperability, SMS 3GPP TS 24.011 >[11] RP-DATA RPDU encapsulation defined in clause 7.3.1 shall be >supported. MIME type "application/vnd.3gpp.sms" shall be used for this >purpose. In order to maintain backward compatibility, MIME type >"application/x-sms" shall be supported by the MMS UA for >mobile-terminated messages only. > >The spec can be found from >http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23140-550.zip >] > >As last thing, a short comment about abbreviations: The E in EMS is >Enhanced, not Extended, "Enhanced Messaging Service", and MMS is >"Multimedia Messaging Service". > > >Best regards, >Ville Warsta >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 14 12:48:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03811 for ; Fri, 14 Mar 2003 12:48:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EI3b528649 for enum-archive@odin.ietf.org; Fri, 14 Mar 2003 13:03:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EI3VO28642; Fri, 14 Mar 2003 13:03:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLNFO32308 for ; Thu, 13 Mar 2003 16:23:15 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19250 for ; Thu, 13 Mar 2003 16:08:07 -0500 (EST) From: Ville.Warsta@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DLDlF22717 for ; Thu, 13 Mar 2003 23:13:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 13 Mar 2003 23:10:17 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Mar 2003 23:10:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 23:10:16 +0200 Message-ID: Thread-Topic: Comments about draft-brandner-enumservice-msg-00.txt Thread-Index: AcLppPIOLzGtOrCmSsmGG69FLw70bA== To: X-OriginalArrivalTime: 13 Mar 2003 21:10:17.0186 (UTC) FILETIME=[F27B2420:01C2E9A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DLNFO32309 Subject: [Enum] Comments about draft-brandner-enumservice-msg-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I have some comments regarding the I-D draft-brandner-enumservice-msg-00.txt. In sections 5.2 and 5.3 the services "SMS" and "EMS" are proposed to be registered. EMS uses the same infrastructure and bearer as SMS -- In fact EMS in practise just means that some additional content has been standardised to be carried over the SMS bearer besides plain text or unspecified binary data. However, the problem is that EMS was extended with new functionality over a period of time with several releases of the specification released by 3GPP. A terminal supporting the 3GPP REL-99 version of TS23.040 (Technical Specification that defines both SMS and the additional EMS content) is not able to show or render new types of content defined in 3GPP REL-5 version of TS23.040. Also, the EMS additions have been defined in such a way that one can do cherry picking -- only choose to implement certain features. Based on this I don't see much use to have the separate service "ems" defined. Your only safe bet is that the recipient supports SMS. For a "fascinating" reading exercise, the latest version of TS23.040 can be found from http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-551.zip I went through last year's mail archives and couldn't find any discussion about adding EMS as a service type, but I apologize if this opens up an old, buried thread. Another comment I have is about the sentence Note that an indication of MMS can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. in 5.4. I don't think this statement is necessarily true. What should be said here is that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if for example the SMS bearer is not supported. While in practise all terminals supporting MMS today support SMS as well, it might not necessarily be the case in the future. [from TS23.140, MMS Stage 2, version 5.5.0: 5.1.2.1 Interoperability with SMS In order to guarantee SMS interoperability, SMS 3GPP TS 24.011 [11] RP-DATA RPDU encapsulation defined in clause 7.3.1 shall be supported. MIME type "application/vnd.3gpp.sms" shall be used for this purpose. In order to maintain backward compatibility, MIME type "application/x-sms" shall be supported by the MMS UA for mobile-terminated messages only. The spec can be found from http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23140-550.zip ] As last thing, a short comment about abbreviations: The E in EMS is Enhanced, not Extended, and MMS is "Multimedia Messaging Service". Best regards, Ville Warsta _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 17 04:15:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07765 for ; Mon, 17 Mar 2003 04:15:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H9Vah16591 for enum-archive@odin.ietf.org; Mon, 17 Mar 2003 04:31:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9VIO16581; Mon, 17 Mar 2003 04:31:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9T2O16460 for ; Mon, 17 Mar 2003 04:29:02 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07729 for ; Mon, 17 Mar 2003 04:12:12 -0500 (EST) Received: from Ripplecl1248 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HBV0058RYVWHO@mta0.huawei.com> for enum@ietf.org; Mon, 17 Mar 2003 17:11:59 +0800 (CST) Date: Mon, 17 Mar 2003 14:48:08 +0530 From: Ripple To: enum@ietf.org Reply-to: Ripple Message-id: <001a01c2ec66$22db9370$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_MBqQzGgR/utXKMT+qj+FTA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Enum] NAPTR Query Issue Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_MBqQzGgR/utXKMT+qj+FTA) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, I have a question about the ENUM Query. When resolver sent a query for NAPTR records to a server. Maybe there isn't the corresponding record in the server zone files. In this conditon, Is it possible that the Answer section is empty, but the Authority Section is a NS record and the Additional Section is the IP address of the NS, then resolver will use the NS information to resend query again? Thanks, Ripple --Boundary_(ID_MBqQzGgR/utXKMT+qj+FTA) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
       I have a question about the ENUM Query. When resolver sent a query for NAPTR records to a server. Maybe there isn't the corresponding record in the server zone files. In this conditon, Is it possible that the Answer section is empty, but the Authority Section is a NS record and the Additional Section is the IP address of the NS, then resolver will use the NS information to resend query again? 
 
Thanks,
Ripple
 
--Boundary_(ID_MBqQzGgR/utXKMT+qj+FTA)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 17 22:32:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15209 for ; Mon, 17 Mar 2003 22:32:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I3n8n32052 for enum-archive@odin.ietf.org; Mon, 17 Mar 2003 22:49:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3mpO32037; Mon, 17 Mar 2003 22:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3lJO31989 for ; Mon, 17 Mar 2003 22:47:19 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15167 for ; Mon, 17 Mar 2003 22:30:04 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 03:32:18 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G8VDX75W; Tue, 18 Mar 2003 03:32:03 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 18 Mar 2003 03:31:02 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] New draft-brandner-enumservice-vovi-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, I'm sending this for Rudi Brandner, who has mail problems sending to the list. Enjoy ----------------------------------------------------------------------- Hi all, considering the discussion on the ENUM mailing list I would like to give you a heads up on a new draft-brandner-enumservice-vovi-01.txt we submitted. Due to the black out time, it will not be published after this IETF. I have attached the text with change bars on the left hand side for your convenience. We removed the 'voice:sip' and 'video:sip' registration (which is indicated by a change bar following appr. 20 '-' signs indicating where the removal took place). Other changed paragraphs are marked with change bars. We believe that the text is now not contentious any more. I am sorry for the late notice, but we really want to proceed with those registrations. Many thanks, Rudi ________________________________________________________________________ ENUM Working Group R. Brandner Internet Draft Siemens L. Conroy Siemens R. Stastny OeFEG Expires: September 2003 March 2003 Registration for enumservices voice and video Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the "enumservices" registered with this document are | 'voice' and 'video' using the URI schemes 'h323:' and 'tel:' Table of Contents TBD 1. Introduction ENUM (E.164 Number Mapping, RFC2916bis [2]) is a system that transforms E.164 numbers [3] into domain names and then uses DNS (Domain Name Service, RFC1034 [4]) services like delegation through NS records and NAPTR records to look up what services are available for a specific domain name. This document registers 'enumservices' according to the guidelines given in RFC2916bis to be used for provisioning in the services field of a NAPTR[6] resource record to indicate what class of functionality a given end point offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [5][6][7][8][9]) hierarchy, for use with the "E2U" DDDS Application defined in RFC2916bis The following 'enumservices' are registered with this document: 'voice' and 'video'. These share a common feature in that they each indicate that the functionality of the given end points and the associated resources are capable of exchanging interactive media streams. According to RFC2619bis, the 'enumservice' registered must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI scheme which is the outcome of the use of it. Therefore an 'enumservice' acts as a hint, indicating the kind of service with which the URI constructed using the regexp field is associated. There can be more than one 'enumservice' included within a single NAPTR; this indicates that there is more than one service that can be achieved using the associated URI scheme. The common thread with this set of definitions is that they reflect the kind of service that the end user will hope to achieve with the communication using the associated URI. The services specified here are intended NOT to specify the protocol or even method of connection that MUST be used to achieve each service. Instead they define the kind of interactive behavior that an end user will expect, leaving the end system to decide (based on policies outside the remit of this specification) how to execute the service. Since the same URI scheme may be used for different services (e.g. 'tel:'), and the same kind of service may use different URI schemes (e.g. for VoIP 'h323:' and 'tel:' may be used), it is necessary in some cases to specify the service and the URI scheme used. The service parameters defined in RFC2916bis allow therefore a 'type' and a 'subtype' to be specified. Within this set of specifications the convention is assumed that the 'type' (being the more generic term) is defining the service and the 'subtype' is defining the URI scheme. 2. Abbreviations TBD 3. Voice Service 3.1 Introduction The enumservices registered in this section indicate that the resource identified by the associated URI is capable of being contacted to provide a communication session during which interactive media streams carrying voice data can be exchanged. 3.2 Voice Service Registration with 'tel:' Enumservice Name: "voice" Type: "voice" Subtype: "tel" URI Scheme: 'tel:' Functional Specification: This enumservice indicates that the resource identified by the associated URI scheme is capable of being called using a PSTN by dialing the number of the URI in order to set up the voice communication. | If a dialing device is not present, a SIP [12] or H.323 [14] Client, | if available, can be invoked and, by using the tel: URI, set up a | session for voice communication. The querying user is expecting a | voice communication. Security Considerations: There are no specific security issues with this 'enumservice'. However, the general considerations of section 6 apply. Intended Usage: COMMON Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see section 8) Any other information the author deems interesting: None |-------------------- 3.3 Voice Service Registration with 'h323:' Enumservice Name: "voice" Type: "voice" Subtype: "h323" URI Scheme: 'h323:' Functional Specification: This enumservice indicates that the resource identified by the associated URI scheme is capable of engaging in a voice communication using H.323 [14]. Note that H.323 has its own negotiation method within the protocol set, so that the client MAY be offered another kind of communication session after negotiation. However, this combination gives more information to the querying user than would be the case for the "h323" enumservice [15]. The implication of this combination is that, if selected, the querying user can engage in an interactive voice communication; thus the registrant SHOULD include such an entry only for those cases where this is possible. Security Considerations: There are no specific security issues with this 'enumservice'. However, the general considerations of section 6 apply. Intended Usage: COMMON Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see section 8) Any other information the author deems interesting: None 4. Video Service 4.1 Introduction The enumservices registered in this section indicate that the resource identified by the associated URI is capable of being contacted to provide a communication session during which interactive media streams carrying audio and video data can be exchanged. 4.2 Video Service Registration with 'tel:' Enumservice Name: "video" Type: "video" Subtype: "tel" URI Scheme: 'tel:' Functional Specification: This enumservice indicates that the resource identified by the associated URI scheme is capable of being called using the PSTN by dialing the number of the URI in order to set up a audio/video communication. | If a dialing device is not present, a SIP [12] or H.323 [14] Client, | if available, can be invoked and, by using the tel: URI, set up a | session for voice communication. The querying user is expecting a | voice communication. Security Considerations: There are no specific security issues with this 'enumservice'. However, the general considerations of section 6 apply. Intended Usage: COMMON Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see section 8) Any other information the author deems interesting: None |-------------------- 4.3 Video Service Registration with 'h323:' Enumservice Name: "video" Type: "video" Subtype: "h323" URI Scheme: 'h323:' Functional Specification: This enumservice indicates that the resource identified by the associated URI scheme is capable of engaging in an audio/video communication using H.323 [14]. Note that H.323 has its own negotiation method within the protocol set, so that the client MAY be offered another kind of communication session after negotiation. However, this combination gives more information to the querying user than would be the case for the "h323" enumservice [15]. The implication of this combination is that, if selected, the querying user can engage in an interactive call that can include video communication; thus the registrant SHOULD include such an entry only for those cases where this is possible. Security Considerations: There are no specific security issues with this 'enumservice'. However, the general considerations of section 6 apply. Intended Usage: COMMON Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see section 8) Any other information the author deems interesting: None 5. Additional Information Editor note: Is there any necessary additional information? TBD 6. Security Considerations DNS, as used by ENUM, is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a Telephone Directory, it does open the data subject to having "their" information collected automatically without any indication that this has been done or by whom. Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they are sent increases when they post to the mailing list; publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS" for example. Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus providing a "sacrificial" phone number in any publication is not possible. Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give their explicit informed consent to data being published in ENUM. In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent. However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that their consent for its publication is explicitly confirmed at regular intervals. When placing a voice or video call via the PSTN or sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that the end user be asked to confirm sending the message, and that the destination number be presented to them. It is the originating user's choice on whether or not to place a call to this destination number, but they SHOULD be shown the destination number so that they can make this decision Where voice or video terminals are configured to accept incoming calls, there SHOULD be an indication presented to the user that an incoming call is being offered. Particularly with some video systems, the terminal may be configured to "auto-accept" the call. In this case there MUST be an obvious indication presented to the calling user that this has been done. Systems configured to auto-accept audio/video calls that are sent to a number published in a global public directory may be used by unexpected individuals to check for the presence or otherwise of | people with a view to stealing property or other unwelcome acts. Whilst "security through obscurity" may have seemed acceptable when the access address was known to only a few, publication within ENUM removes the obscurity, so leaving (for example) a "WebCam" switched on after such publication is even less wise than in other situations. In addition to the specific security considerations given above, all security considerations given in RFC2916bis apply. 7. References 1 Scott Bradner, RFC2026, "The Internet Standards Process - Revision 3", October 1996. 2 P. Faltstrom, M. Mealling, "The E.164 to URI DDDS Application (ENUM)", draft-ietf-enum-rfc2916bis-03.txt, Work in progress, January 2003 3 ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997 4 P. Mockapetris, RFC1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES", November 1987 5 M. Mealling, RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002 6 M. Mealling, RFC 3402, "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", October 2002 7 M. Mealling, RFC 3403, "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", October 2002 8 M. Mealling, RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002 9 M. Mealling, RFC 3405, "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", October 2002 10 H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls", draft-antti-RFC2806bis-08.txt, Work in progress, February 2003 11 ETSI TS 102 172, "Minimum Requirements for Interoperability of European ENUM Trials", February 2003 12 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261, "SIP: Session Initiation Protocol", June 2002 13 J. Peterson, "enumservice registration for SIP Addresses-of-Record", draft-peterson-enum-sip-00.txt, Work in progress, September 2002 14 ITU-T Recommendation H.323, "Packet-based multimedia communications systems", Nov 2000 15 O. Levin, "ENUM Service Registration for H.323 URL", draft-ietf-enum-h323-00.txt, Work in progress, February 2003 8. Author's Addresses Rudolf Brandner Siemens ICN Hofmannstrasse 51 Munich Germany email: voice: web: Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey U.K. email: voice: Richard Stastny OeFEG Postbox 147 1103 Vienna Austria email: voice: 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 18 04:42:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05373 for ; Tue, 18 Mar 2003 04:42:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I9wrc01110 for enum-archive@odin.ietf.org; Tue, 18 Mar 2003 04:58:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I9wRO01092; Tue, 18 Mar 2003 04:58:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I9uAO01002 for ; Tue, 18 Mar 2003 04:56:10 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05218 for ; Tue, 18 Mar 2003 04:38:45 -0500 (EST) Received: from Ripplecl1248 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HBX00FJLUPHG2@mta1.huawei.com> for enum@ietf.org; Tue, 18 Mar 2003 17:37:01 +0800 (CST) Date: Tue, 18 Mar 2003 15:11:53 +0530 From: Ripple Subject: Re: [Enum] NAPTR Query Issue To: enum@ietf.org Reply-to: Ripple Message-id: <000b01c2ed32$a2d08f00$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_GqdAVSpAL7ayyXml4DGrVg)" X-Priority: 3 X-MSMail-priority: Normal References: <001a01c2ec66$22db9370$6302120a@in.huawei.com> Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_GqdAVSpAL7ayyXml4DGrVg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi,all Who can help me? I think if the ENUM Server is same server, maybe it is possible. But I don't know it is correct or not. English is not my native language, maybe I have not described it clear? if it is, please tell me. Thanks for your help. Thanks, Ripple ----- Original Message ----- From: Ripple To: enum@ietf.org Sent: Monday, March 17, 2003 2:48 PM Subject: [Enum] NAPTR Query Issue Hi, I have a question about the ENUM Query. When resolver sent a query for NAPTR records to a server. Maybe there isn't the corresponding record in the server zone files. In this conditon, Is it possible that the Answer section is empty, but the Authority Section is a NS record and the Additional Section is the IP address of the NS, then resolver will use the NS information to resend query again? Thanks, Ripple --Boundary_(ID_GqdAVSpAL7ayyXml4DGrVg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,all
     Who can help me? I think if the ENUM Server is same server, maybe it is possible. But I don't know it is correct or not. English is not my native language, maybe I have not described it clear? if it is, please tell me. Thanks for your help.
 
Thanks,
Ripple
 
----- Original Message -----
From: Ripple
Sent: Monday, March 17, 2003 2:48 PM
Subject: [Enum] NAPTR Query Issue

Hi,
       I have a question about the ENUM Query. When resolver sent a query for NAPTR records to a server. Maybe there isn't the corresponding record in the server zone files. In this conditon, Is it possible that the Answer section is empty, but the Authority Section is a NS record and the Additional Section is the IP address of the NS, then resolver will use the NS information to resend query again? 
 
Thanks,
Ripple
 
--Boundary_(ID_GqdAVSpAL7ayyXml4DGrVg)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 18 06:14:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07432 for ; Tue, 18 Mar 2003 06:14:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IBV4j06315 for enum-archive@odin.ietf.org; Tue, 18 Mar 2003 06:31:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IBV0O06307; Tue, 18 Mar 2003 06:31:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IBTKO06231 for ; Tue, 18 Mar 2003 06:29:20 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07374 for ; Tue, 18 Mar 2003 06:11:56 -0500 (EST) Received: from Ripplecl1248 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HBX00FH4Z0SG2@mta1.huawei.com> for enum@ietf.org; Tue, 18 Mar 2003 19:10:08 +0800 (CST) Date: Tue, 18 Mar 2003 16:45:05 +0530 From: Ripple Subject: Re: [Enum] NAPTR Query Issue To: Peter Koch Cc: enum@ietf.org Reply-to: Ripple Message-id: <001d01c2ed3f$a53b6190$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200303181005.h2IA5mn16301@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Transfer-Encoding: 7BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Peter Koch" To: "Ripple" Sent: Tuesday, March 18, 2003 3:35 PM Subject: Re: [Enum] NAPTR Query Issue > > Hello, > > > Who can help me? I think if the ENUM Server is same server, maybe it is > > first, it might help to have a real name in the From: line. In IETF working > groups we usually don't use pseudonyms. Ripple is my english name and all my foreign friends will call me with it. Although it is not like a name. > >possible. But I don't know it is correct or not. English is not my native lang > >uage, maybe I have not described it clear? if it is, please tell me. Thanks fo > >r your help. > > Then, your question is not really related to ENUM, but touches the very > basic concept of a DNS referral or an "empty answer". > Finally, it is unclear (at least to me), what your problem really is. > > -Peter Thanks for your help. I am not sure if the ENUM Server is same with DNS Server. If the ENUM Server is separated Server, and there aren't NAPTR records in the local ENUM Server, how to process it? just give a empty response or using the NS record to provided the other ENUM Server information? Maybe both are right. But I want to known the latter is possible or not. Thanks, Ripple _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 18 06:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07453 for ; Tue, 18 Mar 2003 06:15:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IBW3406360 for enum-archive@odin.ietf.org; Tue, 18 Mar 2003 06:32:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IBW3O06355; Tue, 18 Mar 2003 06:32:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IBUjO06276 for ; Tue, 18 Mar 2003 06:30:45 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07391 for ; Tue, 18 Mar 2003 06:13:21 -0500 (EST) Received: from Ripplecl1248 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HBX00GVNZ74JR@mta0.huawei.com> for enum@ietf.org; Tue, 18 Mar 2003 19:13:53 +0800 (CST) Date: Tue, 18 Mar 2003 16:46:37 +0530 From: Ripple Subject: Re: [Enum] NAPTR Query Issue To: Juan Rodriguez Hervella Cc: enum@ietf.org Reply-to: Ripple Message-id: <002301c2ed3f$d868e1f0$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001a01c2ec66$22db9370$6302120a@in.huawei.com> <000b01c2ed32$a2d08f00$6302120a@in.huawei.com> <200303181110.47656.jrh@it.uc3m.es> Content-Transfer-Encoding: 7BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Thanks for your help, I have known your opnions. Best Regards, Ripple ----- Original Message ----- From: "Juan Rodriguez Hervella" To: "Ripple" Sent: Tuesday, March 18, 2003 3:40 PM Subject: Re: [Enum] NAPTR Query Issue > On Tuesday 18 March 2003 10:41, Ripple wrote: > > Hi,all > > Who can help me? I think if the ENUM Server is same server, maybe it > > is possible. But I don't know it is correct or not. English is not my > > native language, maybe I have not described it clear? if it is, please tell > > me. Thanks for your help. > > > > Thanks, > > Ripple > > > > ----- Original Message ----- > > From: Ripple > > To: enum@ietf.org > > Sent: Monday, March 17, 2003 2:48 PM > > Subject: [Enum] NAPTR Query Issue > > > > > > Hi, > > I have a question about the ENUM Query. When resolver sent a query > > for NAPTR records to a server. Maybe there isn't the corresponding record > > in the server zone files. In this conditon, Is it possible that the Answer > > section is empty, but the Authority Section is a NS record and the > > Additional Section is the IP address of the NS, then resolver will use the > > NS information to resend query again? > > > > Thanks, > > Ripple > > Hello: > > I don't know a lot about DNS internal format, but I think > that ENUM queries works exactly the same as any other query against > the DNS. What happen if you ask for an RR of type A and it doesn't > exist on the server zone file ? the same behaviour should appear > whatever RR are you looking for...NAPTR resource records aren't different. > > However, the client should implement the algorithm to search for a service > through a chain of NAPTR records, which is explained in > http://www.ietf.org/rfc/rfc3401.txt. > > Hope this help. > > -- > JFRH _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 18 13:44:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23226 for ; Tue, 18 Mar 2003 13:44:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJ1jw07006 for enum-archive@odin.ietf.org; Tue, 18 Mar 2003 14:01:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJ1YO06990; Tue, 18 Mar 2003 14:01:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I3TFO30494 for ; Mon, 17 Mar 2003 22:29:15 -0500 Received: from mailgate5.cinetic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14722 for ; Mon, 17 Mar 2003 22:11:59 -0500 (EST) Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.6/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h2I3ED322123; Tue, 18 Mar 2003 04:14:13 +0100 Date: Tue, 18 Mar 2003 04:14:13 +0100 Message-Id: <200303180314.h2I3ED322123@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: "Rudolf Brandner" To: enum@ietf.org Cc: lwc@roke.co.uk, paf@cisco.com, rich.shockey@NeuStar.com, richard.stastny@oefeg.at, richard@stastny.com, rudis@brandner-web.de, rudolf.brandner@siemens.com Precedence: fm-user Content-Type: multipart/mixed; boundary="STEFAN3e768f05126f" Subject: [Enum] New draft-brandner-enumservice-vovi-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , This is a MIME encoded message. --STEFAN3e768f05126f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, considering the discussion on the ENUM mailing list I would like to give you a heads up on a new draft-brandner-enumservice-vovi-01.txt we submitted. Due to the black out time, it will not be published after this IETF. I have attached the text with change bars on the left hand side for your convenience. We removed the 'voice:sip' and 'video:sip' registration (which is indicated by a change bar following appr. 20 '-' signs indicating where the removal took place). Other changed paragraphs are marked with change bars. We believe that the text is now not contentious any more. I am sorry for the late notice, but we really want to proceed with those registrations. Many thanks, Rudi ______________________________________________________________________________ Keine Zeit fur Firlefanz? Blitz-SMS von WEB.DE FreeMail! Die SMS, die direkt auf's Display kommt! http://freemail.web.de/features/?mc=021166 --STEFAN3e768f05126f Content-Type: text/plain; name="draft-brandner-enumservice-vovi-01-cb.txt" Content-Disposition: inline; filename="draft-brandner-enumservice-vovi-01-cb.txt" Content-Transfer-Encoding: base64 RU5VTSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUi4gQnJhbmRuZXINCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaWVtZW5zDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEwuIENvbnJv eQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFNpZW1lbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBTdGFzdG55DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBP ZUZFRw0KRXhwaXJlczogU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICAgICBSZWdpc3RyYXRpb24g Zm9yIGVudW1zZXJ2aWNlcyB2b2ljZSBhbmQgdmlkZW8NCiAgICAgICAgICAgICAgPGRyYWZ0 LWJyYW5kbmVyLWVudW1zZXJ2aWNlLXZvdmktMDEudHh0Pg0KDQpTdGF0dXMgb2YgdGhpcyBN ZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCANCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24g MTAgb2YgUkZDMjAyNiBbMV0uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0KICAgVGFzayBGb3JjZSAo SUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAN CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRz IGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgIG1vbnRocyBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIA0KICAgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KDQoNCkFic3Ry YWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIGEgZ3JvdXAgb2YgJ2VudW1zZXJ2 aWNlcycgWzJdIHRvIGJlIHVzZWQgdG8gDQogICBpbmRpY2F0ZSB0aGF0IHRoZSBhc3NvY2lh dGVkIHJlc291cmNlcyBhcmUgY2FwYWJsZSBvZiBpbnRlcmFjdGl2ZSANCiAgIG1lZGlhIHN0 cmVhbSBleGNoYW5nZS4NCg0KICAgU3BlY2lmaWNhbGx5LCB0aGUgImVudW1zZXJ2aWNlcyIg cmVnaXN0ZXJlZCB3aXRoIHRoaXMgZG9jdW1lbnQgYXJlIA0KfCAgJ3ZvaWNlJyBhbmQgJ3Zp ZGVvJyB1c2luZyB0aGUgVVJJIHNjaGVtZXMgJ2gzMjM6JyBhbmQgJ3RlbDonDQoNCg0KDQoN Cg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICBUQkQNCg0KDQoxLiAgSW50cm9kdWN0aW9u DQoNCiAgIEVOVU0gKEUuMTY0IE51bWJlciBNYXBwaW5nLCBSRkMyOTE2YmlzIFsyXSkgaXMg YSBzeXN0ZW0gdGhhdCANCiAgIHRyYW5zZm9ybXMgRS4xNjQgbnVtYmVycyBbM10gaW50byBk b21haW4gbmFtZXMgYW5kIHRoZW4gdXNlcyBETlMgDQogICAoRG9tYWluIE5hbWUgU2Vydmlj ZSwgUkZDMTAzNCBbNF0pIHNlcnZpY2VzIGxpa2UgZGVsZWdhdGlvbiB0aHJvdWdoIA0KICAg TlMgcmVjb3JkcyBhbmQgTkFQVFIgcmVjb3JkcyB0byBsb29rIHVwIHdoYXQgc2VydmljZXMg YXJlIGF2YWlsYWJsZSANCiAgIGZvciBhIHNwZWNpZmljIGRvbWFpbiBuYW1lLg0KDQogICBU aGlzIGRvY3VtZW50IHJlZ2lzdGVycyAnZW51bXNlcnZpY2VzJyBhY2NvcmRpbmcgdG8gdGhl IGd1aWRlbGluZXMgDQogICBnaXZlbiBpbiBSRkMyOTE2YmlzIHRvIGJlIHVzZWQgZm9yIHBy b3Zpc2lvbmluZyBpbiB0aGUgc2VydmljZXMgDQogICBmaWVsZCBvZiBhIE5BUFRSWzZdIHJl c291cmNlIHJlY29yZCB0byBpbmRpY2F0ZSB3aGF0IGNsYXNzIG9mIA0KICAgZnVuY3Rpb25h bGl0eSBhIGdpdmVuIGVuZCBwb2ludCBvZmZlcnMuIFRoZSByZWdpc3RyYXRpb24gaXMgZGVm aW5lZCANCiAgIHdpdGhpbiB0aGUgREREUyAoRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVy eSBTeXN0ZW0gDQogICBbNV1bNl1bN11bOF1bOV0pIGhpZXJhcmNoeSwgZm9yIHVzZSB3aXRo IHRoZSAiRTJVIiBERERTIEFwcGxpY2F0aW9uIA0KICAgZGVmaW5lZCBpbiBSRkMyOTE2Ymlz DQoNCiAgIFRoZSBmb2xsb3dpbmcgJ2VudW1zZXJ2aWNlcycgYXJlIHJlZ2lzdGVyZWQgd2l0 aCB0aGlzIGRvY3VtZW50OiANCiAgICd2b2ljZScgYW5kICd2aWRlbycuIFRoZXNlIHNoYXJl IGEgY29tbW9uIGZlYXR1cmUgaW4gdGhhdCB0aGV5IGVhY2ggDQogICBpbmRpY2F0ZSB0aGF0 IHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBnaXZlbiBlbmQgcG9pbnRzIGFuZCB0aGUgDQog ICBhc3NvY2lhdGVkIHJlc291cmNlcyBhcmUgY2FwYWJsZSBvZiBleGNoYW5naW5nIGludGVy YWN0aXZlIG1lZGlhIA0KICAgc3RyZWFtcy4NCg0KICAgQWNjb3JkaW5nIHRvIFJGQzI2MTli aXMsIHRoZSAnZW51bXNlcnZpY2UnIHJlZ2lzdGVyZWQgbXVzdCBiZSBhYmxlIA0KICAgdG8g ZnVuY3Rpb24gYXMgYSBzZWxlY3Rpb24gbWVjaGFuaXNtIHdoZW4gY2hvb3Npbmcgb25lIE5B UFRSIA0KICAgcmVzb3VyY2UgcmVjb3JkIGZyb20gYW5vdGhlci4gVGhhdCBtZWFucyB0aGF0 IHRoZSByZWdpc3RyYXRpb24gTVVTVCANCiAgIHNwZWNpZnkgd2hhdCBpcyBleHBlY3RlZCB3 aGVuIHVzaW5nIHRoYXQgdmVyeSBOQVBUUiByZWNvcmQsIGFuZCB0aGUgDQogICBVUkkgc2No ZW1lIHdoaWNoIGlzIHRoZSBvdXRjb21lIG9mIHRoZSB1c2Ugb2YgaXQuDQoNCiAgIFRoZXJl Zm9yZSBhbiAnZW51bXNlcnZpY2UnIGFjdHMgYXMgYSBoaW50LCBpbmRpY2F0aW5nIHRoZSBr aW5kIG9mIA0KICAgc2VydmljZSB3aXRoIHdoaWNoIHRoZSBVUkkgY29uc3RydWN0ZWQgdXNp bmcgdGhlIHJlZ2V4cCBmaWVsZCBpcyANCiAgIGFzc29jaWF0ZWQuIFRoZXJlIGNhbiBiZSBt b3JlIHRoYW4gb25lICdlbnVtc2VydmljZScgaW5jbHVkZWQgd2l0aGluIA0KICAgYSBzaW5n bGUgTkFQVFI7IHRoaXMgaW5kaWNhdGVzIHRoYXQgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBz ZXJ2aWNlIA0KICAgdGhhdCBjYW4gYmUgYWNoaWV2ZWQgdXNpbmcgdGhlIGFzc29jaWF0ZWQg VVJJIHNjaGVtZS4NCg0KICAgVGhlIGNvbW1vbiB0aHJlYWQgd2l0aCB0aGlzIHNldCBvZiBk ZWZpbml0aW9ucyBpcyB0aGF0IHRoZXkgcmVmbGVjdCANCiAgIHRoZSBraW5kIG9mIHNlcnZp Y2UgdGhhdCB0aGUgZW5kIHVzZXIgd2lsbCBob3BlIHRvIGFjaGlldmUgd2l0aCB0aGUgDQog ICBjb21tdW5pY2F0aW9uIHVzaW5nIHRoZSBhc3NvY2lhdGVkIFVSSS4gDQoNCiAgIFRoZSBz ZXJ2aWNlcyBzcGVjaWZpZWQgaGVyZSBhcmUgaW50ZW5kZWQgTk9UIHRvIHNwZWNpZnkgdGhl IHByb3RvY29sIA0KICAgb3IgZXZlbiBtZXRob2Qgb2YgY29ubmVjdGlvbiB0aGF0IE1VU1Qg YmUgdXNlZCB0byBhY2hpZXZlIGVhY2ggDQogICBzZXJ2aWNlLiBJbnN0ZWFkIHRoZXkgZGVm aW5lIHRoZSBraW5kIG9mIGludGVyYWN0aXZlIGJlaGF2aW9yIHRoYXQgDQogICBhbiBlbmQg dXNlciB3aWxsIGV4cGVjdCwgbGVhdmluZyB0aGUgZW5kIHN5c3RlbSB0byBkZWNpZGUgKGJh c2VkIG9uIA0KICAgcG9saWNpZXMgb3V0c2lkZSB0aGUgcmVtaXQgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uKSBob3cgdG8gZXhlY3V0ZSB0aGUgDQogICBzZXJ2aWNlLg0KDQogICBTaW5jZSB0 aGUgc2FtZSBVUkkgc2NoZW1lIG1heSBiZSB1c2VkIGZvciBkaWZmZXJlbnQgc2VydmljZXMg KGUuZy4gDQogICAndGVsOicpLCBhbmQgdGhlIHNhbWUga2luZCBvZiBzZXJ2aWNlIG1heSB1 c2UgZGlmZmVyZW50IFVSSSBzY2hlbWVzIA0KICAgKGUuZy4gZm9yIFZvSVAgJ2gzMjM6JyBh bmQgJ3RlbDonIG1heSBiZSB1c2VkKSwgaXQgaXMgbmVjZXNzYXJ5IGluIA0KICAgc29tZSBj YXNlcyB0byBzcGVjaWZ5IHRoZSBzZXJ2aWNlIGFuZCB0aGUgVVJJIHNjaGVtZSB1c2VkLg0K DQogICBUaGUgc2VydmljZSBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gUkZDMjkxNmJpcyBhbGxv dyB0aGVyZWZvcmUgYSANCiAgICd0eXBlJyBhbmQgYSAnc3VidHlwZScgdG8gYmUgc3BlY2lm aWVkLiBXaXRoaW4gdGhpcyBzZXQgb2YgDQogICBzcGVjaWZpY2F0aW9ucyB0aGUgY29udmVu dGlvbiBpcyBhc3N1bWVkIHRoYXQgdGhlICd0eXBlJyAoYmVpbmcgdGhlIA0KICAgbW9yZSBn ZW5lcmljIHRlcm0pIGlzIGRlZmluaW5nIHRoZSBzZXJ2aWNlIGFuZCB0aGUgJ3N1YnR5cGUn IGlzIA0KICAgZGVmaW5pbmcgdGhlIFVSSSBzY2hlbWUuDQoNCg0KMi4gIEFiYnJldmlhdGlv bnMNCg0KICAgVEJEDQoNCg0KMy4gIFZvaWNlIFNlcnZpY2UNCg0KMy4xICBJbnRyb2R1Y3Rp b24NCg0KICAgVGhlIGVudW1zZXJ2aWNlcyByZWdpc3RlcmVkIGluIHRoaXMgc2VjdGlvbiBp bmRpY2F0ZSB0aGF0IHRoZSANCiAgIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhlIGFzc29j aWF0ZWQgVVJJIGlzIGNhcGFibGUgb2YgYmVpbmcgDQogICBjb250YWN0ZWQgdG8gcHJvdmlk ZSBhIGNvbW11bmljYXRpb24gc2Vzc2lvbiBkdXJpbmcgd2hpY2ggDQogICBpbnRlcmFjdGl2 ZSBtZWRpYSBzdHJlYW1zIGNhcnJ5aW5nIHZvaWNlIGRhdGEgY2FuIGJlIGV4Y2hhbmdlZC4N Cg0KDQozLjIgIFZvaWNlIFNlcnZpY2UgUmVnaXN0cmF0aW9uIHdpdGggJ3RlbDonDQoNCiAg IEVudW1zZXJ2aWNlIE5hbWU6ICJ2b2ljZSINCg0KICAgVHlwZTogInZvaWNlIg0KDQogICBT dWJ0eXBlOiAidGVsIg0KDQogICBVUkkgU2NoZW1lOiAndGVsOicNCg0KICAgRnVuY3Rpb25h bCBTcGVjaWZpY2F0aW9uOiANCg0KICAgVGhpcyBlbnVtc2VydmljZSBpbmRpY2F0ZXMgdGhh dCB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgDQogICBhc3NvY2lhdGVkIFVSSSBz Y2hlbWUgaXMgY2FwYWJsZSBvZiBiZWluZyBjYWxsZWQgdXNpbmcgYSBQU1ROIGJ5IA0KICAg ZGlhbGluZyB0aGUgbnVtYmVyIG9mIHRoZSBVUkkgaW4gb3JkZXIgdG8gc2V0IHVwIHRoZSB2 b2ljZSANCiAgIGNvbW11bmljYXRpb24uDQoNCnwgIElmIGEgZGlhbGluZyBkZXZpY2UgaXMg bm90IHByZXNlbnQsIGEgU0lQIFsxMl0gb3IgSC4zMjMgWzE0XSBDbGllbnQsIA0KfCAgaWYg YXZhaWxhYmxlLCBjYW4gYmUgaW52b2tlZCBhbmQsIGJ5IHVzaW5nIHRoZSB0ZWw6IFVSSSwg c2V0IHVwIGEgDQp8ICBzZXNzaW9uIGZvciB2b2ljZSBjb21tdW5pY2F0aW9uLiBUaGUgcXVl cnlpbmcgdXNlciBpcyBleHBlY3RpbmcgYSANCnwgIHZvaWNlIGNvbW11bmljYXRpb24uDQoN CiAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOiANCg0KICAgVGhlcmUgYXJlIG5vIHNwZWNp ZmljIHNlY3VyaXR5IGlzc3VlcyB3aXRoIHRoaXMgJ2VudW1zZXJ2aWNlJy4gDQogICBIb3dl dmVyLCB0aGUgZ2VuZXJhbCBjb25zaWRlcmF0aW9ucyBvZiBzZWN0aW9uIDYgYXBwbHkuDQoN CiAgIEludGVuZGVkIFVzYWdlOiBDT01NT04NCg0KICAgQXV0aG9yOiBSdWRvbGYgQnJhbmRu ZXIsIExhd3JlbmNlIENvbnJveSwgUmljaGFyZCBTdGFzdG55DQogICAgICAgICAgIChmb3Ig YXV0aG9yIGNvbnRhY3QgZGV0YWlsIHNlZSBzZWN0aW9uIDgpDQoNCiAgIEFueSBvdGhlciBp bmZvcm1hdGlvbiB0aGUgYXV0aG9yIGRlZW1zIGludGVyZXN0aW5nOg0KDQogICBOb25lDQoN CnwtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMy4zICBWb2ljZSBTZXJ2aWNlIFJlZ2lzdHJhdGlv biB3aXRoICdoMzIzOicNCg0KICAgRW51bXNlcnZpY2UgTmFtZTogInZvaWNlIg0KDQogICBU eXBlOiAidm9pY2UiDQoNCiAgIFN1YnR5cGU6ICJoMzIzIg0KDQogICBVUkkgU2NoZW1lOiAn aDMyMzonDQoNCiAgIEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvbjogDQoNCiAgIFRoaXMgZW51 bXNlcnZpY2UgaW5kaWNhdGVzIHRoYXQgdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhl IA0KICAgYXNzb2NpYXRlZCBVUkkgc2NoZW1lIGlzIGNhcGFibGUgb2YgZW5nYWdpbmcgaW4g YSB2b2ljZSANCiAgIGNvbW11bmljYXRpb24gdXNpbmcgSC4zMjMgWzE0XS4gTm90ZSB0aGF0 IEguMzIzIGhhcyBpdHMgb3duIA0KICAgbmVnb3RpYXRpb24gbWV0aG9kIHdpdGhpbiB0aGUg cHJvdG9jb2wgc2V0LCBzbyB0aGF0IHRoZSBjbGllbnQgTUFZIA0KICAgYmUgb2ZmZXJlZCBh bm90aGVyIGtpbmQgb2YgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGFmdGVyIG5lZ290aWF0aW9u Lg0KDQogICBIb3dldmVyLCB0aGlzIGNvbWJpbmF0aW9uIGdpdmVzIG1vcmUgaW5mb3JtYXRp b24gdG8gdGhlIHF1ZXJ5aW5nIA0KICAgdXNlciB0aGFuIHdvdWxkIGJlIHRoZSBjYXNlIGZv ciB0aGUgImgzMjMiIGVudW1zZXJ2aWNlIFsxNV0uIFRoZSANCiAgIGltcGxpY2F0aW9uIG9m IHRoaXMgY29tYmluYXRpb24gaXMgdGhhdCwgaWYgc2VsZWN0ZWQsIHRoZSBxdWVyeWluZyAN CiAgIHVzZXIgY2FuIGVuZ2FnZSBpbiBhbiBpbnRlcmFjdGl2ZSB2b2ljZSBjb21tdW5pY2F0 aW9uOyB0aHVzIHRoZSANCiAgIHJlZ2lzdHJhbnQgU0hPVUxEIGluY2x1ZGUgc3VjaCBhbiBl bnRyeSBvbmx5IGZvciB0aG9zZSBjYXNlcyB3aGVyZSANCiAgIHRoaXMgaXMgcG9zc2libGUu DQoNCiAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOg0KDQogICBUaGVyZSBhcmUgbm8gc3Bl Y2lmaWMgc2VjdXJpdHkgaXNzdWVzIHdpdGggdGhpcyAnZW51bXNlcnZpY2UnLiANCiAgIEhv d2V2ZXIsIHRoZSBnZW5lcmFsIGNvbnNpZGVyYXRpb25zIG9mIHNlY3Rpb24gNiBhcHBseS4N Cg0KICAgSW50ZW5kZWQgVXNhZ2U6IENPTU1PTg0KDQogICBBdXRob3I6IFJ1ZG9sZiBCcmFu ZG5lciwgTGF3cmVuY2UgQ29ucm95LCBSaWNoYXJkIFN0YXN0bnkNCiAgICAgICAgICAgKGZv ciBhdXRob3IgY29udGFjdCBkZXRhaWwgc2VlIHNlY3Rpb24gOCkNCg0KICAgQW55IG90aGVy IGluZm9ybWF0aW9uIHRoZSBhdXRob3IgZGVlbXMgaW50ZXJlc3Rpbmc6DQoNCiAgIE5vbmUN Cg0KDQo0LiAgVmlkZW8gU2VydmljZQ0KDQo0LjEgIEludHJvZHVjdGlvbg0KDQogICBUaGUg ZW51bXNlcnZpY2VzIHJlZ2lzdGVyZWQgaW4gdGhpcyBzZWN0aW9uIGluZGljYXRlIHRoYXQg dGhlIA0KICAgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgYXNzb2NpYXRlZCBVUkkgaXMg Y2FwYWJsZSBvZiBiZWluZyANCiAgIGNvbnRhY3RlZCB0byBwcm92aWRlIGEgY29tbXVuaWNh dGlvbiBzZXNzaW9uIGR1cmluZyB3aGljaCANCiAgIGludGVyYWN0aXZlIG1lZGlhIHN0cmVh bXMgY2FycnlpbmcgYXVkaW8gYW5kIHZpZGVvIGRhdGEgY2FuIGJlIA0KICAgZXhjaGFuZ2Vk Lg0KDQoNCjQuMiAgVmlkZW8gU2VydmljZSBSZWdpc3RyYXRpb24gd2l0aCAndGVsOicNCg0K ICAgRW51bXNlcnZpY2UgTmFtZTogInZpZGVvIg0KDQogICBUeXBlOiAidmlkZW8iDQoNCiAg IFN1YnR5cGU6ICJ0ZWwiDQoNCiAgIFVSSSBTY2hlbWU6ICd0ZWw6Jw0KDQogICBGdW5jdGlv bmFsIFNwZWNpZmljYXRpb246IA0KDQogICBUaGlzIGVudW1zZXJ2aWNlIGluZGljYXRlcyB0 aGF0IHRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSANCiAgIGFzc29jaWF0ZWQgVVJJ IHNjaGVtZSBpcyBjYXBhYmxlIG9mIGJlaW5nIGNhbGxlZCB1c2luZyB0aGUgUFNUTiBieSAN CiAgIGRpYWxpbmcgdGhlIG51bWJlciBvZiB0aGUgVVJJIGluIG9yZGVyIHRvIHNldCB1cCBh IGF1ZGlvL3ZpZGVvIA0KICAgY29tbXVuaWNhdGlvbi4NCg0KfCAgSWYgYSBkaWFsaW5nIGRl dmljZSBpcyBub3QgcHJlc2VudCwgYSBTSVAgWzEyXSBvciBILjMyMyBbMTRdIENsaWVudCwg DQp8ICBpZiBhdmFpbGFibGUsIGNhbiBiZSBpbnZva2VkIGFuZCwgYnkgdXNpbmcgdGhlIHRl bDogVVJJLCBzZXQgdXAgYSANCnwgIHNlc3Npb24gZm9yIHZvaWNlIGNvbW11bmljYXRpb24u IFRoZSBxdWVyeWluZyB1c2VyIGlzIGV4cGVjdGluZyBhIA0KfCAgdm9pY2UgY29tbXVuaWNh dGlvbi4NCg0KICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6IA0KDQogICBUaGVyZSBhcmUg bm8gc3BlY2lmaWMgc2VjdXJpdHkgaXNzdWVzIHdpdGggdGhpcyAnZW51bXNlcnZpY2UnLiAN CiAgIEhvd2V2ZXIsIHRoZSBnZW5lcmFsIGNvbnNpZGVyYXRpb25zIG9mIHNlY3Rpb24gNiBh cHBseS4NCg0KICAgSW50ZW5kZWQgVXNhZ2U6IENPTU1PTg0KDQogICBBdXRob3I6IFJ1ZG9s ZiBCcmFuZG5lciwgTGF3cmVuY2UgQ29ucm95LCBSaWNoYXJkIFN0YXN0bnkNCiAgICAgICAg ICAgKGZvciBhdXRob3IgY29udGFjdCBkZXRhaWwgc2VlIHNlY3Rpb24gOCkNCg0KICAgQW55 IG90aGVyIGluZm9ybWF0aW9uIHRoZSBhdXRob3IgZGVlbXMgaW50ZXJlc3Rpbmc6DQoNCiAg IE5vbmUNCg0KfC0tLS0tLS0tLS0tLS0tLS0tLS0tDQo0LjMgIFZpZGVvIFNlcnZpY2UgUmVn aXN0cmF0aW9uIHdpdGggJ2gzMjM6Jw0KDQogICBFbnVtc2VydmljZSBOYW1lOiAidmlkZW8i DQoNCiAgIFR5cGU6ICJ2aWRlbyINCg0KICAgU3VidHlwZTogImgzMjMiDQoNCiAgIFVSSSBT Y2hlbWU6ICdoMzIzOicNCg0KICAgRnVuY3Rpb25hbCBTcGVjaWZpY2F0aW9uOiANCg0KICAg VGhpcyBlbnVtc2VydmljZSBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVzb3VyY2UgaWRlbnRpZmll ZCBieSB0aGUgDQogICBhc3NvY2lhdGVkIFVSSSBzY2hlbWUgaXMgY2FwYWJsZSBvZiBlbmdh Z2luZyBpbiBhbiBhdWRpby92aWRlbyANCiAgIGNvbW11bmljYXRpb24gdXNpbmcgSC4zMjMg WzE0XS4gTm90ZSB0aGF0IEguMzIzIGhhcyBpdHMgb3duIA0KICAgbmVnb3RpYXRpb24gbWV0 aG9kIHdpdGhpbiB0aGUgcHJvdG9jb2wgc2V0LCBzbyB0aGF0IHRoZSBjbGllbnQgTUFZIA0K ICAgYmUgb2ZmZXJlZCBhbm90aGVyIGtpbmQgb2YgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGFm dGVyIG5lZ290aWF0aW9uLg0KDQogICBIb3dldmVyLCB0aGlzIGNvbWJpbmF0aW9uIGdpdmVz IG1vcmUgaW5mb3JtYXRpb24gdG8gdGhlIHF1ZXJ5aW5nIA0KICAgdXNlciB0aGFuIHdvdWxk IGJlIHRoZSBjYXNlIGZvciB0aGUgImgzMjMiIGVudW1zZXJ2aWNlIFsxNV0uIFRoZSANCiAg IGltcGxpY2F0aW9uIG9mIHRoaXMgY29tYmluYXRpb24gaXMgdGhhdCwgaWYgc2VsZWN0ZWQs IHRoZSBxdWVyeWluZyANCiAgIHVzZXIgY2FuIGVuZ2FnZSBpbiBhbiBpbnRlcmFjdGl2ZSBj YWxsIHRoYXQgY2FuIGluY2x1ZGUgdmlkZW8gDQogICBjb21tdW5pY2F0aW9uOyB0aHVzIHRo ZSByZWdpc3RyYW50IFNIT1VMRCBpbmNsdWRlIHN1Y2ggYW4gZW50cnkgb25seSANCiAgIGZv ciB0aG9zZSBjYXNlcyB3aGVyZSB0aGlzIGlzIHBvc3NpYmxlLg0KDQogICBTZWN1cml0eSBD b25zaWRlcmF0aW9uczoNCg0KICAgVGhlcmUgYXJlIG5vIHNwZWNpZmljIHNlY3VyaXR5IGlz c3VlcyB3aXRoIHRoaXMgJ2VudW1zZXJ2aWNlJy4gDQogICBIb3dldmVyLCB0aGUgZ2VuZXJh bCBjb25zaWRlcmF0aW9ucyBvZiBzZWN0aW9uIDYgYXBwbHkuDQoNCiAgIEludGVuZGVkIFVz YWdlOiBDT01NT04NCg0KICAgQXV0aG9yOiBSdWRvbGYgQnJhbmRuZXIsIExhd3JlbmNlIENv bnJveSwgUmljaGFyZCBTdGFzdG55DQogICAgICAgICAgIChmb3IgYXV0aG9yIGNvbnRhY3Qg ZGV0YWlsIHNlZSBzZWN0aW9uIDgpDQoNCiAgIEFueSBvdGhlciBpbmZvcm1hdGlvbiB0aGUg YXV0aG9yIGRlZW1zIGludGVyZXN0aW5nOg0KDQogICBOb25lDQoNCg0KNS4gIEFkZGl0aW9u YWwgSW5mb3JtYXRpb24NCg0KICAgRWRpdG9yIG5vdGU6IElzIHRoZXJlIGFueSBuZWNlc3Nh cnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbj8gVEJEDQoNCg0KNi4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIA0KDQogICBETlMsIGFzIHVzZWQgYnkgRU5VTSwgaXMgYSBnbG9iYWwsIGRp c3RyaWJ1dGVkIGRhdGFiYXNlLiBUaHVzIGFueSANCiAgIGluZm9ybWF0aW9uIHN0b3JlZCB0 aGVyZSBpcyB2aXNpYmxlIHRvIGFueW9uZSBhbm9ueW1vdXNseS4gV2hpbHN0IA0KICAgdGhp cyBpcyBub3QgcXVhbGl0YXRpdmVseSBkaWZmZXJlbnQgZnJvbSBwdWJsaWNhdGlvbiBpbiBh IFRlbGVwaG9uZSANCiAgIERpcmVjdG9yeSwgaXQgZG9lcyBvcGVuIHRoZSBkYXRhIHN1Ympl Y3QgdG8gaGF2aW5nICJ0aGVpciIgDQogICBpbmZvcm1hdGlvbiBjb2xsZWN0ZWQgYXV0b21h dGljYWxseSB3aXRob3V0IGFueSBpbmRpY2F0aW9uIHRoYXQgdGhpcyANCiAgIGhhcyBiZWVu IGRvbmUgb3IgYnkgd2hvbS4NCg0KICAgU3VjaCBkYXRhIGhhcnZlc3RpbmcgYnkgdGhpcmQg cGFydGllcyBpcyBvZnRlbiB1c2VkIHRvIGdlbmVyYXRlIA0KICAgbGlzdHMgb2YgdGFyZ2V0 cyBmb3IgdW5yZXF1ZXN0ZWQgaW5mb3JtYXRpb247IGluIHNob3J0LCB0aGV5IGFyZSANCiAg IHVzZWQgdG8gYWRkcmVzcyAic3BhbSIuIEFueW9uZSB3aG8gdXNlcyBhIFdlYi1hcmNoaXZl ZCBtYWlsaW5nIGxpc3QgDQogICBpcyBhd2FyZSB0aGF0IHRoZSB2b2x1bWUgb2YgInNwYW0i IGVtYWlsIHRoZXkgYXJlIHNlbnQgaW5jcmVhc2VzIA0KICAgd2hlbiB0aGV5IHBvc3QgdG8g dGhlIG1haWxpbmcgbGlzdDsgcHVibGljYXRpb24gb2YgYSB0ZWxlcGhvbmUgDQogICBudW1i ZXIgaW4gRU5VTSBpcyBubyBkaWZmZXJlbnQsIGFuZCBtYXkgYmUgdXNlZCB0byBzZW5kICJq dW5rIGZheGVzIiANCiAgIG9yICJqdW5rIFNNUyIgZm9yIGV4YW1wbGUuDQoNCiAgIE1hbnkg bWFpbGluZyBsaXN0IHVzZXJzIGhhdmUgbW9yZSB0aGFuIG9uZSBlbWFpbCBhZGRyZXNzIGFu ZCB1c2UgDQogICAic2FjcmlmaWNpYWwiIGVtYWlsIGFjY291bnRzIHdoZW4gcG9zdGluZyB0 byBzdWNoIGxpc3RzIHRvIGhlbHAgDQogICBmaWx0ZXIgb3V0IHVucmVxdWVzdGVkIGVtYWls cyBzZW50IHRvIHRoZW0uIFRoaXMgaXMgbm90IHNvIGVhc3kgd2l0aCANCiAgIHB1Ymxpc2hl ZCB0ZWxlcGhvbmUgbnVtYmVyczsgdGhlIFBTVE4gRS4xNjQgbnVtYmVyIGFzc2lnbm1lbnQg DQogICBwcm9jZXNzIGlzIG11Y2ggbW9yZSBpbnZvbHZlZCBhbmQgdXN1YWxseSBhIHNpbmds ZSBFLjE2NCBudW1iZXIgKG9yIA0KICAgYSBmaXhlZCByYW5nZSBvZiBudW1iZXJzKSBpcyBh c3NvY2lhdGVkIHdpdGggZWFjaCBQU1ROIGFjY2Vzcy4gVGh1cyANCiAgIHByb3ZpZGluZyBh ICJzYWNyaWZpY2lhbCIgcGhvbmUgbnVtYmVyIGluIGFueSBwdWJsaWNhdGlvbiBpcyBub3Qg DQogICBwb3NzaWJsZS4NCg0KICAgRHVlIHRvIHRoZSBpbXBsaWNhdGlvbnMgb2YgcHVibGlz aGluZyBkYXRhIG9uIGEgZ2xvYmFsbHkgYWNjZXNzaWJsZSANCiAgIGRhdGFiYXNlLCBhcyBh IHByaW5jaXBsZSB0aGUgZGF0YSBzdWJqZWN0IE1VU1QgZ2l2ZSB0aGVpciBleHBsaWNpdCAN CiAgIGluZm9ybWVkIGNvbnNlbnQgdG8gZGF0YSBiZWluZyBwdWJsaXNoZWQgaW4gRU5VTS4N Cg0KICAgSW4gYWRkaXRpb24sIHRoZXkgc2hvdWxkIGJlIG1hZGUgYXdhcmUgdGhhdCwgZHVl IHRvIHN0b3JhZ2Ugb2Ygc3VjaCANCiAgIGRhdGEgZHVyaW5nIGhhcnZlc3RpbmcgYnkgdGhp cmQgcGFydGllcywgcmVtb3ZhbCBvZiB0aGUgZGF0YSBmcm9tIA0KICAgcHVibGljYXRpb24g d2lsbCBub3QgcmVtb3ZlIGFueSBjb3BpZXMgdGhhdCBoYXZlIGJlZW4gdGFrZW47IGluIA0K ICAgZWZmZWN0LCBhbnkgcHVibGljYXRpb24gbWF5IGJlIHBlcm1hbmVudC4NCg0KICAgSG93 ZXZlciwgcmVndWxhdGlvbnMgaW4gbWFueSByZWdpb25zIHdpbGwgcmVxdWlyZSB0aGF0IHRo ZSBkYXRhIA0KICAgc3ViamVjdCBjYW4gYXQgYW55IHRpbWUgcmVxdWVzdCB0aGF0IHRoZSBk YXRhIGlzIHJlbW92ZWQgZnJvbSANCiAgIHB1YmxpY2F0aW9uLCBhbmQgdGhhdCB0aGVpciBj b25zZW50IGZvciBpdHMgcHVibGljYXRpb24gaXMgDQogICBleHBsaWNpdGx5IGNvbmZpcm1l ZCBhdCByZWd1bGFyIGludGVydmFscy4NCg0KICAgV2hlbiBwbGFjaW5nIGEgdm9pY2Ugb3Ig dmlkZW8gY2FsbCB2aWEgdGhlIFBTVE4gb3Igc2VuZGluZyBhIG1lc3NhZ2UgDQogICB2aWEg dGhlIFB1YmxpYyBMYW5kIE1vYmlsZSBOZXR3b3JrLCB0aGUgc2VuZGVyIG1heSBiZSBjaGFy Z2VkIGZvciANCiAgIHRoaXMgYWN0aW9uLiBJbiBib3RoIGtpbmRzIG9mIG5ldHdvcmssIGNh bGxpbmcgb3IgbWVzc2FnaW5nIHRvIHNvbWUgDQogICBudW1iZXJzIGlzIG1vcmUgZXhwZW5z aXZlIHRoYW4gc2VuZGluZyB0byBvdGhlcnM7IGJvdGggbmV0d29ya3MgaGF2ZSANCiAgICJw cmVtaXVtIHJhdGUiIHNlcnZpY2VzIHRoYXQgY2FuIGNoYXJnZSBjb25zaWRlcmFibHkgbW9y ZSB0aGFuIGEgDQogICAibm9ybWFsIiBjYWxsIG9yIG1lc3NhZ2UgZGVzdGluYXRpb24uIEFz IHN1Y2gsIGl0IGlzIGltcG9ydGFudCB0aGF0IA0KICAgdGhlIGVuZCB1c2VyIGJlIGFza2Vk IHRvIGNvbmZpcm0gc2VuZGluZyB0aGUgbWVzc2FnZSwgYW5kIHRoYXQgdGhlIA0KICAgZGVz dGluYXRpb24gbnVtYmVyIGJlIHByZXNlbnRlZCB0byB0aGVtLiBJdCBpcyB0aGUgb3JpZ2lu YXRpbmcgDQogICB1c2VyJ3MgY2hvaWNlIG9uIHdoZXRoZXIgb3Igbm90IHRvIHBsYWNlIGEg Y2FsbCB0byB0aGlzIGRlc3RpbmF0aW9uIA0KICAgbnVtYmVyLCBidXQgdGhleSBTSE9VTEQg YmUgc2hvd24gdGhlIGRlc3RpbmF0aW9uIG51bWJlciBzbyB0aGF0IHRoZXkgDQogICBjYW4g bWFrZSB0aGlzIGRlY2lzaW9uDQoNCiAgIFdoZXJlIHZvaWNlIG9yIHZpZGVvIHRlcm1pbmFs cyBhcmUgY29uZmlndXJlZCB0byBhY2NlcHQgaW5jb21pbmcgDQogICBjYWxscywgdGhlcmUg U0hPVUxEIGJlIGFuIGluZGljYXRpb24gcHJlc2VudGVkIHRvIHRoZSB1c2VyIHRoYXQgYW4g DQogICBpbmNvbWluZyBjYWxsIGlzIGJlaW5nIG9mZmVyZWQuIFBhcnRpY3VsYXJseSB3aXRo IHNvbWUgdmlkZW8gDQogICBzeXN0ZW1zLCB0aGUgdGVybWluYWwgbWF5IGJlIGNvbmZpZ3Vy ZWQgdG8gImF1dG8tYWNjZXB0IiB0aGUgY2FsbC4gDQogICBJbiB0aGlzIGNhc2UgdGhlcmUg TVVTVCBiZSBhbiBvYnZpb3VzIGluZGljYXRpb24gcHJlc2VudGVkIHRvIHRoZSANCiAgIGNh bGxpbmcgdXNlciB0aGF0IHRoaXMgaGFzIGJlZW4gZG9uZS4NCg0KICAgU3lzdGVtcyBjb25m aWd1cmVkIHRvIGF1dG8tYWNjZXB0IGF1ZGlvL3ZpZGVvIGNhbGxzIHRoYXQgYXJlIHNlbnQg dG8gDQogICBhIG51bWJlciBwdWJsaXNoZWQgaW4gYSBnbG9iYWwgcHVibGljIGRpcmVjdG9y eSBtYXkgYmUgdXNlZCBieSANCiAgIHVuZXhwZWN0ZWQgaW5kaXZpZHVhbHMgdG8gY2hlY2sg Zm9yIHRoZSBwcmVzZW5jZSBvciBvdGhlcndpc2Ugb2YgDQp8ICBwZW9wbGUgd2l0aCBhIHZp ZXcgdG8gc3RlYWxpbmcgcHJvcGVydHkgb3Igb3RoZXIgdW53ZWxjb21lIGFjdHMuIA0KICAg V2hpbHN0ICJzZWN1cml0eSB0aHJvdWdoIG9ic2N1cml0eSIgbWF5IGhhdmUgc2VlbWVkIGFj Y2VwdGFibGUgd2hlbiANCiAgIHRoZSBhY2Nlc3MgYWRkcmVzcyB3YXMga25vd24gdG8gb25s eSBhIGZldywgcHVibGljYXRpb24gd2l0aGluIEVOVU0gDQogICByZW1vdmVzIHRoZSBvYnNj dXJpdHksIHNvIGxlYXZpbmcgKGZvciBleGFtcGxlKSBhICJXZWJDYW0iIHN3aXRjaGVkIA0K ICAgb24gYWZ0ZXIgc3VjaCBwdWJsaWNhdGlvbiBpcyBldmVuIGxlc3Mgd2lzZSB0aGFuIGlu IG90aGVyIA0KICAgc2l0dWF0aW9ucy4NCg0KICAgSW4gYWRkaXRpb24gdG8gdGhlIHNwZWNp ZmljIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGdpdmVuIGFib3ZlLCBhbGwgDQogICBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBnaXZlbiBpbiBSRkMyOTE2YmlzIGFwcGx5Lg0KDQoNCjcu ICBSZWZlcmVuY2VzDQoNCjEgIFNjb3R0IEJyYWRuZXIsIFJGQzIwMjYsDQogICAgICAiVGhl IEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0gUmV2aXNpb24gMyIsDQogICAgICBPY3Rv YmVyIDE5OTYuDQoNCjIgIFAuIEZhbHRzdHJvbSwgTS4gTWVhbGxpbmcsDQogICAgICAiVGhl IEUuMTY0IHRvIFVSSSBERERTIEFwcGxpY2F0aW9uIChFTlVNKSIsDQogICAgICBkcmFmdC1p ZXRmLWVudW0tcmZjMjkxNmJpcy0wMy50eHQsDQogICAgICBXb3JrIGluIHByb2dyZXNzLCBK YW51YXJ5IDIwMDMNCg0KMyAgSVRVLVQsDQogICAgICAiVGhlIEludGVybmF0aW9uYWwgUHVi bGljIFRlbGVjb21tdW5pY2F0aW9uIE51bWJlciBQbGFuIiwNCiAgICAgIFJlY29tbWVuZGF0 aW9uIEUuMTY0LA0KICAgICAgTWF5IDE5OTcNCg0KNCAgUC4gTW9ja2FwZXRyaXMsIFJGQzEw MzQsDQogICAgICAiRE9NQUlOIE5BTUVTIC0gQ09OQ0VQVFMgQU5EIEZBQ0lMSVRJRVMiLA0K ICAgICAgTm92ZW1iZXIgMTk4Nw0KDQo1ICBNLiBNZWFsbGluZywgUkZDIDM0MDEsDQogICAg ICAiRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgT25l Og0KICAgICAgVGhlIENvbXByZWhlbnNpdmUgREREUyIsDQogICAgICBPY3RvYmVyIDIwMDIN Cg0KNiAgTS4gTWVhbGxpbmcsIFJGQyAzNDAyLA0KICAgICAgIkR5bmFtaWMgRGVsZWdhdGlv biBEaXNjb3ZlcnkgU3lzdGVtIChERERTKSBQYXJ0IFR3bzoNCiAgICAgIFRoZSBBbGdvcml0 aG0iLA0KICAgICAgT2N0b2JlciAyMDAyDQoNCjcgIE0uIE1lYWxsaW5nLCBSRkMgMzQwMywN CiAgICAgICJEeW5hbWljIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbSAoREREUykgUGFy dCBUaHJlZToNCiAgICAgIFRoZSBEb21haW4gTmFtZSBTeXN0ZW0gKEROUykgRGF0YWJhc2Ui LA0KICAgICAgT2N0b2JlciAyMDAyDQoNCjggIE0uIE1lYWxsaW5nLCBSRkMgMzQwNCwNCiAg ICAgICJEeW5hbWljIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbSAoREREUykgUGFydCBG b3VyOg0KICAgICAgVGhlIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllcnMgKFVSSSkiLA0K ICAgICAgT2N0b2JlciAyMDAyDQoNCjkgIE0uIE1lYWxsaW5nLCBSRkMgMzQwNSwNCiAgICAg ICJEeW5hbWljIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbSAoREREUykgUGFydCBGaXZl Og0KICAgICAgVVJJLkFSUEEgQXNzaWdubWVudCBQcm9jZWR1cmVzIiwNCiAgICAgIE9jdG9i ZXIgMjAwMg0KDQoxMCAgSC4gU2NodWx6cmlubmUsIEEuIFZhaGEtU2lwaWxhLCANCiAgICAg ICJVUklzIGZvciBUZWxlcGhvbmUgQ2FsbHMiLA0KICAgICAgZHJhZnQtYW50dGktUkZDMjgw NmJpcy0wOC50eHQsDQogICAgICBXb3JrIGluIHByb2dyZXNzLCBGZWJydWFyeSAyMDAzDQoN CjExICBFVFNJIFRTIDEwMiAxNzIsDQogICAgICAiTWluaW11bSBSZXF1aXJlbWVudHMgZm9y IEludGVyb3BlcmFiaWxpdHkgb2YgDQogICAgICBFdXJvcGVhbiBFTlVNIFRyaWFscyIsDQog ICAgICBGZWJydWFyeSAyMDAzDQoNCjEyICBKLiBSb3NlbmJlcmcsIEguIFNjaHVsenJpbm5l LCBHLiBDYW1hcmlsbG8sIEEuIEpvaG5zdG9uLA0KICAgICAgSi4gUGV0ZXJzb24sIFIuIFNw YXJrcywgTS4gSGFuZGxleSwgRS4gU2Nob29sZXIsDQogICAgICBSRkMgMzI2MSwNCiAgICAg ICJTSVA6IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCIsDQogICAgICBKdW5lIDIwMDIN Cg0KMTMgIEouIFBldGVyc29uLA0KICAgICAgImVudW1zZXJ2aWNlIHJlZ2lzdHJhdGlvbiBm b3IgU0lQIEFkZHJlc3Nlcy1vZi1SZWNvcmQiLA0KICAgICAgZHJhZnQtcGV0ZXJzb24tZW51 bS1zaXAtMDAudHh0LA0KICAgICAgV29yayBpbiBwcm9ncmVzcywgU2VwdGVtYmVyIDIwMDIN Cg0KMTQgIElUVS1UIFJlY29tbWVuZGF0aW9uIEguMzIzLA0KICAgICAgIlBhY2tldC1iYXNl ZCBtdWx0aW1lZGlhIGNvbW11bmljYXRpb25zIHN5c3RlbXMiLA0KICAgICAgTm92IDIwMDAN Cg0KMTUgIE8uIExldmluLA0KICAgICAgIkVOVU0gU2VydmljZSBSZWdpc3RyYXRpb24gZm9y IEguMzIzIFVSTCIsDQogICAgICBkcmFmdC1pZXRmLWVudW0taDMyMy0wMC50eHQsDQogICAg ICBXb3JrIGluIHByb2dyZXNzLCBGZWJydWFyeSAyMDAzDQoNCg0KOC4gIEF1dGhvcidzIEFk ZHJlc3Nlcw0KDQogICBSdWRvbGYgQnJhbmRuZXINCiAgICAgIFNpZW1lbnMgSUNODQogICAg ICBIb2ZtYW5uc3RyYXNzZSA1MQ0KICAgICAgTXVuaWNoDQogICAgICBHZXJtYW55DQogICAg ICBlbWFpbDogPG1haWx0bzpydWRvbGYuYnJhbmRuZXJAc2llbWVucy5jb20+DQogICAgICB2 b2ljZTogPHRlbDorNDktODktNzIyNTEwMDM+DQogICAgICB3ZWI6ICAgPGh0dHA6Ly93d3cu c2llbWVucy5jb20+DQoNCiAgIExhd3JlbmNlIENvbnJveQ0KICAgICAgU2llbWVucyBSb2tl IE1hbm9yIFJlc2VhcmNoDQogICAgICBSb2tlIE1hbm9yDQogICAgICBSb21zZXkNCiAgICAg IFUuSy4NCiAgICAgIGVtYWlsOiA8bWFpbHRvOmx3Y0Byb2tlLmNvLnVrPg0KICAgICAgdm9p Y2U6IDx0ZWw6KzQ0LTE3OTQtODMzNjY2Pg0KDQogICBSaWNoYXJkIFN0YXN0bnkNCiAgICAg IE9lRkVHDQogICAgICBQb3N0Ym94IDE0Nw0KICAgICAgMTEwMyBWaWVubmENCiAgICAgIEF1 c3RyaWENCiAgICAgIGVtYWlsOiA8bWFpbHRvOnJpY2hhcmQuc3Rhc3RueUBvZWZlZy5hdD4N CiAgICAgIHZvaWNlOiA8dGVsOis0My02NjQtNDIwLTQxMDA+DQoNCg0KDQo5LiAgRnVsbCBD b3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDApLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0 byANCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9y IG90aGVyd2lzZSBleHBsYWluIGl0IA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRh dGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIA0KICAgYW5kIGRpc3Ry aWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFu eSANCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2Ug YW5kIHRoaXMgcGFyYWdyYXBoIA0KICAgYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGll cyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIEhvd2V2ZXIsIHRoaXMgDQogICBkb2N1bWVudCBp dHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92 aW5nIA0KICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50 ZXJuZXQgU29jaWV0eSBvciBvdGhlciANCiAgIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4 Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mIA0KICAgZGV2ZWxvcGluZyBJbnRl cm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgDQogICBj b3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11 c3QgYmUgDQogICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGlu dG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRl ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90 IGJlIA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vz c29ycyBvciBhc3NpZ25zLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbiANCiAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJ TkcgDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP UiBJTVBMSUVELCBJTkNMVURJTkcgDQogICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJB TlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gDQogICBIRVJFSU4gV0lMTCBO T1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIA0K ICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF Lg0KDQo= --STEFAN3e768f05126f-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 18 19:29:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08166 for ; Tue, 18 Mar 2003 19:29:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J0kkP01950 for enum-archive@odin.ietf.org; Tue, 18 Mar 2003 19:46:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0khO01944; Tue, 18 Mar 2003 19:46:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0S8O32722 for ; Tue, 18 Mar 2003 19:28:08 -0500 Received: from whale.cnnic.net.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07396 for ; Tue, 18 Mar 2003 19:10:30 -0500 (EST) Received: from enum1 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id HBYZ9700.M5K; Wed, 19 Mar 2003 08:12:43 +0800 Message-ID: <004701c2edac$3f8bf590$6207e29f@enum1> From: "bill" To: Cc: Subject: re: [Enum] NAPTR Query Issue Date: Wed, 19 Mar 2003 08:12:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2J0S8O32723 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Ripple: I don't know the following may answer your question. I tried this query to different ENUM servers for e164.arpa, 6.8.e164.arpa, and 861036861001 resolution. Here are what i got. There is no additional section in the answer. By the way, your question is related to the DNS implementation, you may refer to the DNS protocols. In addition, there is some place which discussed DNS implementation and operational issues, like www.isc.org, IETF DNSEXT WG AND DNSOP WG. [root@de1650-2 root]# dig @193.0.0.193 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ; <<>> DiG 9.1.3 <<>> @193.0.0.193 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53442 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. IN NAPTR ;; AUTHORITY SECTION: 6.8.e164.arpa. 14400 IN NS arpa-ns1.enum.net.cn. 6.8.e164.arpa. 14400 IN NS arpa-ns0.enum.net.cn. ;; Query time: 306 msec ;; SERVER: 193.0.0.193#53(193.0.0.193) ;; WHEN: Wed Mar 19 07:50:25 2003 ;; MSG SIZE rcvd: 108 [root@de1650-2 root]# dig @159.226.7.156 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ; <<>> DiG 9.1.3 <<>> @159.226.7.156 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40754 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. IN NAPTR ;; AUTHORITY SECTION: 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. 60 IN NS naptr-rs0.enum.net.cn. 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. 60 IN NS naptr-rs1.enum.net.cn. ;; Query time: 1 msec ;; SERVER: 159.226.7.156#53(159.226.7.156) ;; WHEN: Wed Mar 19 07:51:03 2003 ;; MSG SIZE rcvd: 110 [root@de1650-2 root]# dig @159.226.7.154 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ; <<>> DiG 9.1.3 <<>> @159.226.7.154 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa naptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46230 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. IN NAPTR ;; ANSWER SECTION: 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. 60 IN NAPTR 20 20 "u" "SIP+E2U" "!^.*$!SIP:1001@apple.6.8.e164.cn!" . ;; AUTHORITY SECTION: 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. 60 IN NS naptr-rs1.enum.net.cn. 1.0.0.1.6.8.6.3.0.1.6.8.e164.arpa. 60 IN NS naptr-rs0.enum.net.cn. ;; Query time: 2 msec ;; SERVER: 159.226.7.154#53(159.226.7.154) ;; WHEN: Wed Mar 19 07:51:18 2003 ;; MSG SIZE rcvd: 171 -bill _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 19 00:32:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16882 for ; Wed, 19 Mar 2003 00:32:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J5o5W21827 for enum-archive@odin.ietf.org; Wed, 19 Mar 2003 00:50:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J5niO21806; Wed, 19 Mar 2003 00:49:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J5jdO21641 for ; Wed, 19 Mar 2003 00:45:39 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16733 for ; Wed, 19 Mar 2003 00:27:52 -0500 (EST) Received: from Ripplecl1248 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HBZ005BFDV7ZN@mta0.huawei.com> for enum@ietf.org; Wed, 19 Mar 2003 13:28:22 +0800 (CST) Date: Wed, 19 Mar 2003 11:04:32 +0530 From: Ripple Subject: Re: [Enum] NAPTR Query Issue To: bill Cc: enum@ietf.org Reply-to: Ripple Message-id: <004c01c2edd9$3988fbc0$6302120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <004701c2edac$3f8bf590$6207e29f@enum1> Content-Transfer-Encoding: 8BIT Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT Bill£º Thank you very much! That is exactly my need. Best Regards, Ripple _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 19 14:39:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02831 for ; Wed, 19 Mar 2003 14:39:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJv0E27515 for enum-archive@odin.ietf.org; Wed, 19 Mar 2003 14:57:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJukO27491; Wed, 19 Mar 2003 14:56:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJtZO27392 for ; Wed, 19 Mar 2003 14:55:35 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02746 for ; Wed, 19 Mar 2003 14:37:34 -0500 (EST) Received: from wl-132-179.wireless.ietf56.ietf.org (wl-132-179.wireless.ietf56.ietf.org [::ffff:130.129.132.179]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 19 Mar 2003 01:15:37 -0500 From: Michael Mealling To: enum@ietf.org Organization: ExoAerospace, Inc Message-Id: <1045421516.7171.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 16 Feb 2003 13:51:57 -0500 Content-Transfer-Encoding: 7bit Subject: [Enum] partial numbers proposed text changes Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The two issues that were discussed in the meeting were DNSSEC wording and partial E.164 numbers. I'm addressing them seperately for thread management. This message concerns the partial numbers issue only. The proposed changes are to delete Section 2.6 entirely. The following text is added as a second paragraph to the beginning of Section 2: -- ENUM is only applicable for E.164 numbers. ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. This implies applications MAY send DNS queries when, for example, a user mistypes a number in a user interface. Because of this risk for collissions, the flag E2U in the service field MUST NOT be used for non-E.164 numbers. -- There was a good deal of concensus over this text. There was some attempt to explain further the meaning of the word 'believes' and how that interacted with the actual E.164 standard. The gist was that the application should make an effort to ensure that the number is valid according to the E.164 specification. Since it is impossible for an application to have perfect knowledge of all numbering plans, the word 'believe' means that the application has done its best effort to sanitize the numbers it queries for. The document authors are looking for text from those that correctly expresses this concept in a way that preserves the overall concept expressed in the above text. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 19 15:03:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04173 for ; Wed, 19 Mar 2003 15:03:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JKLDM31425 for enum-archive@odin.ietf.org; Wed, 19 Mar 2003 15:21:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKLBO31416; Wed, 19 Mar 2003 15:21:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKKWO31341 for ; Wed, 19 Mar 2003 15:20:32 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04052 for ; Wed, 19 Mar 2003 15:02:30 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.36 #1 (Debian)) id 18vjnk-0001C9-00; Wed, 19 Mar 2003 22:04:40 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15992.52568.611976.334179@lohi.eng.song.fi> Date: Wed, 19 Mar 2003 22:04:40 +0200 To: Michael Mealling Cc: enum@ietf.org Subject: [Enum] partial numbers proposed text changes In-Reply-To: <1045421516.7171.15.camel@localhost.localdomain> References: <1045421516.7171.15.camel@localhost.localdomain> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Mealling writes: > ENUM is only applicable for E.164 numbers. ENUM compliant applications > MUST only query DNS for what it believes is an E.164 number. ... for a syntaxtically correct E.164 number. > The gist was that the > application should make an effort to ensure that the number is valid > according to the E.164 specification. Since it is impossible for an > application to have perfect knowledge of all numbering plans, the word > 'believe' means that the application has done its best effort to > sanitize the numbers it queries for. it is a very bad idea for an application to try to analyze if the number is valid according to a certain numbering plan, since once the numbering plans change, the application must be changed. in finland, for example, the numbering plan is changing almost yearly. thus the above proposal for the text. -- juha _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 19 16:23:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08896 for ; Wed, 19 Mar 2003 16:23:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLf1q06970 for enum-archive@odin.ietf.org; Wed, 19 Mar 2003 16:41:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLexO06958; Wed, 19 Mar 2003 16:40:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLUqO05434 for ; Wed, 19 Mar 2003 16:30:52 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08453 for ; Wed, 19 Mar 2003 16:12:48 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 19 Mar 2003 22:18:54 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF06B@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] partial numbers proposed text changes Thread-Index: AcLuUZRC/lHoP9F1SA6xT6rNtEPzPAACozMp From: "Stastny Richard" To: "Michael Mealling" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2JLUqO05435 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I propose the last sentence of the text to be deleted, because this is not possible anyway: "Because of this risk for collissions, the flag E2U in the service field MUST NOT be used for non-E.164 numbers." Reason: According to the delegation policy within e164.arpa only domains mapping to valid E164 numbers may be created within the e164.arpa tree anyway. It is therefore not possible to create a domain with non-E164 within e164.arpa in the first place. Therefore there is no way to enter a NAPTR with E2U in such a non existing domain. regards Richard -----Ursprüngliche Nachricht----- Von: Michael Mealling [mailto:michael@neonym.net] Gesendet: So 16.02.2003 19:51 An: enum@ietf.org Cc: Betreff: [Enum] partial numbers proposed text changes The two issues that were discussed in the meeting were DNSSEC wording and partial E.164 numbers. I'm addressing them seperately for thread management. This message concerns the partial numbers issue only. The proposed changes are to delete Section 2.6 entirely. The following text is added as a second paragraph to the beginning of Section 2: -- ENUM is only applicable for E.164 numbers. ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. This implies applications MAY send DNS queries when, for example, a user mistypes a number in a user interface. Because of this risk for collissions, the flag E2U in the service field MUST NOT be used for non-E.164 numbers. -- There was a good deal of concensus over this text. There was some attempt to explain further the meaning of the word 'believes' and how that interacted with the actual E.164 standard. The gist was that the application should make an effort to ensure that the number is valid according to the E.164 specification. Since it is impossible for an application to have perfect knowledge of all numbering plans, the word 'believe' means that the application has done its best effort to sanitize the numbers it queries for. The document authors are looking for text from those that correctly expresses this concept in a way that preserves the overall concept expressed in the above text. _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 19 16:46:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10741 for ; Wed, 19 Mar 2003 16:46:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JM4Sv10303 for enum-archive@odin.ietf.org; Wed, 19 Mar 2003 17:04:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM4RO10298; Wed, 19 Mar 2003 17:04:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JM3ZO10206 for ; Wed, 19 Mar 2003 17:03:35 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10673 for ; Wed, 19 Mar 2003 16:45:30 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h2JLlEC32361; Wed, 19 Mar 2003 21:47:14 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 16:47:40 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Stastny Richard'" , Michael Mealling , enum@ietf.org Subject: RE: [Enum] partial numbers proposed text changes Date: Wed, 19 Mar 2003 16:47:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JM3ZO10207 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit While I agree that this normative statement is very much in the spirit of ENUM as defined in 1.2, there was enough confusion about this (simple) matter that I think this last sentence is very much worth keeping. It is not directly entailed by 1.2, and I think future readers of RFC2916bis might be confused about whether or not this is possible. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 19, 2003 1:19 PM > To: Michael Mealling; enum@ietf.org > Subject: AW: [Enum] partial numbers proposed text changes > > > I propose the last sentence of the text to be deleted, > because this is not possible anyway: > > "Because of this risk for > collissions, the flag E2U in the service field MUST NOT be used for > non-E.164 numbers." > > Reason: > > According to the delegation policy within e164.arpa only > domains mapping to valid E164 numbers may be created within > the e164.arpa tree anyway. It is therefore not possible to > create a domain with non-E164 within e164.arpa in the first > place. Therefore there is no way to enter a NAPTR with E2U in > such a non existing domain. > > regards > > Richard > > > -----Ursprüngliche Nachricht----- > Von: Michael Mealling [mailto:michael@neonym.net] > Gesendet: So 16.02.2003 19:51 > An: enum@ietf.org > Cc: > Betreff: [Enum] partial numbers proposed text changes > > > > The two issues that were discussed in the meeting were > DNSSEC wording > and partial E.164 numbers. I'm addressing them > seperately for thread > management. This message concerns the partial numbers > issue only. The > proposed changes are to delete Section 2.6 entirely. > The following text > is added as a second paragraph to the beginning of Section 2: > > -- > ENUM is only applicable for E.164 numbers. ENUM > compliant applications > MUST only query DNS for what it believes is an E.164 > number. This > implies applications MAY send DNS queries when, for > example, a user > mistypes a number in a user interface. Because of this risk for > collissions, the flag E2U in the service field MUST NOT > be used for > non-E.164 numbers. > -- > > There was a good deal of concensus over this text. > There was some > attempt to explain further the meaning of the word > 'believes' and how > that interacted with the actual E.164 standard. The > gist was that the > application should make an effort to ensure that the > number is valid > according to the E.164 specification. Since it is > impossible for an > application to have perfect knowledge of all numbering > plans, the word > 'believe' means that the application has done its best effort to > sanitize the numbers it queries for. The document > authors are looking > for text from those that correctly expresses this > concept in a way that > preserves the overall concept expressed in the above text. > > _______________________________________________ > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Sun Mar 23 05:35:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29433 for ; Sun, 23 Mar 2003 05:35:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NAsgV29237 for enum-archive@odin.ietf.org; Sun, 23 Mar 2003 05:54:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NAsRO29215; Sun, 23 Mar 2003 05:54:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NAqHO29160 for ; Sun, 23 Mar 2003 05:52:17 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29279 for ; Sun, 23 Mar 2003 05:32:28 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Mar 2003 10:34:44 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HM2WDY93; Sun, 23 Mar 2003 10:34:40 -0000 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Stastny Richard'" , Michael Mealling , enum@ietf.org Cc: Rudi on the road Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> Date: Sun, 23 Mar 2003 10:34:36 +0000 Subject: RE: [Enum] partial numbers proposed text changes Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2NAqIO29165 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit At 4:47 pm -0500 19/3/03, Peterson, Jon wrote: >While I agree that this normative statement is very much in the spirit of >ENUM as defined in 1.2, there was enough confusion about this (simple) >matter that I think this last sentence is very much worth keeping. It is not >directly entailed by 1.2, and I think future readers of RFC2916bis might be >confused about whether or not this is possible. In reply to comment from Richard Stastny: > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > I propose the last sentence of the text to be deleted, >> because this is not possible anyway: >>  >> "Because of this risk for >> collissions, the flag E2U in the service field MUST NOT be used for >> non-E.164 numbers." >> >> Reason: >> >> According to the delegation policy within e164.arpa only >> domains mapping to valid E164 numbers may be created within >> the e164.arpa tree anyway. It is therefore not possible to >> create a domain with non-E164 within e164.arpa in the first >> place. Therefore there is no way to enter a NAPTR with E2U in > > such a non existing domain. To which I add: Hi Jetsetters, folks, Whilst I understand Jon's concerns, Richard does make a good point. Given the agreements for e164.arpa., no end user will be allowed to register a domain associated with an incomplete number. It won't happen. Thus, putting in this comment may confuse, in that some folk might think that such a Registration *is* possible, given the proposed prohibition. My point at the meeting was that regulatory authorities or their agents might envisage using a NAPTR in an intermediate node, **** if such a node exists as a separate entity****. Any prohibition would be based on our current assumptions on how ENUM will be used, and that any domain within e164.arpa. would be under the control of a potential "end user" Registrant rather than being within the control of a National Numbering Authority or its agents. From the proposals for ENUM Administration I've seen, there IS no intermediate node, with a T1 pointing to (T2) servers authoritative for domains that are associated ONLY with "fully qualified" (i.e. E.164) numbers. However, IF an administration wants to insert domains that would logically be associated with "incomplete" (i.e. NOT E.164) numbers, then (i) it's a national admin issue and so their choice - we can't stop them, and (ii) these would not be under the control of an ENUM "End User//Registrant". We might as well put prohibitions on what can go into the "co.uk." domain - this will certainly NOT be a domain that will be free for folk to Register either. We may need some document(s) advising what is sensible (or not) for a National Administration to do, and what the technical implications are by their actions, but 2916 is NOT that document, IMHO. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 24 07:27:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12353 for ; Mon, 24 Mar 2003 07:27:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OClY829457 for enum-archive@odin.ietf.org; Mon, 24 Mar 2003 07:47:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCl2O29411; Mon, 24 Mar 2003 07:47:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCinO29300 for ; Mon, 24 Mar 2003 07:44:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11921; Mon, 24 Mar 2003 07:24:31 -0500 (EST) Message-Id: <200303241224.HAA11921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Mar 2003 07:24:31 -0500 Subject: [Enum] I-D ACTION:draft-brandner-enumservice-vovi-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration for enumservices voice and video Author(s) : R. Brandner et al. Filename : draft-brandner-enumservice-vovi-01.txt Pages : 0 Date : 2003-3-21 This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange. Specifically, the 'enumservices' registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enumservice-vovi-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-brandner-enumservice-vovi-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-brandner-enumservice-vovi-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. --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: <2003-3-21154913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enumservice-vovi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enumservice-vovi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21154913.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Mon Mar 24 07:54:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14517 for ; Mon, 24 Mar 2003 07:54:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ODE8t31817 for enum-archive@odin.ietf.org; Mon, 24 Mar 2003 08:14:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODE7O31812; Mon, 24 Mar 2003 08:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ODDXO31711 for ; Mon, 24 Mar 2003 08:13:33 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14333 for ; Mon, 24 Mar 2003 07:53:14 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 12:55:32 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HSB1WW75; Mon, 24 Mar 2003 12:55:31 -0000 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 24 Mar 2003 12:55:28 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] VOVI-01 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Hi Folks, before anyone complains, the abstract for VOVI-01 shown on the announce-ietf list is for the old version, not the one we submitted. Strange but true. The current one has no untoward references to SIP. If anyone has comments on this new version, please could they raise them on this list now; we'd like to get this one put to bed. all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 14:39:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27666 for ; Tue, 25 Mar 2003 14:39:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PK05407200 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 15:00:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJxpO07172; Tue, 25 Mar 2003 14:59:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJwIO07044 for ; Tue, 25 Mar 2003 14:58:18 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27589 for ; Tue, 25 Mar 2003 14:37:22 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 01:14:46 -0500 Subject: RE: [Enum] partial numbers proposed text changes From: Michael Mealling To: "Conroy, Lawrence (SMTP)" Cc: "Peterson, Jon" , "'Stastny Richard'" , enum@ietf.org, Rudi on the road In-Reply-To: References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048621019.32425.65.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 14:36:59 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sun, 2003-03-23 at 05:34, Conroy, Lawrence (SMTP) wrote: > Given the agreements for e164.arpa., no end user will be allowed to > register a domain associated with an incomplete number. It won't happen. > Thus, putting in this comment may confuse, in that some folk might > think that such a Registration *is* possible, given the proposed > prohibition. The agreements for e164.arpa may be ignored at lower tiers within the infrastructure either knowingly or unknowingly. Saying people will think you can do something when the document specifically says you can't suggests we shouldn't write a specification at all.... > My point at the meeting was that regulatory authorities or their agents > might envisage using a NAPTR in an intermediate node, **** if such a > node exists as a separate entity****. It does exist. By virtue of the fact that you insert '.' in between each node, it does exist with respect to DNS. And if it exists people can and will insert records into those domains. What we're trying to do is maintain someway for a client to be able to tell the difference. > Any prohibition would be based on our current assumptions on how ENUM > will be used, and that any domain within e164.arpa. would be under > the control of a potential "end user" Registrant rather than being > within the control of a National Numbering Authority or its agents. > > From the proposals for ENUM Administration I've seen, there IS no > intermediate node, with a T1 pointing to (T2) servers authoritative > for domains that are associated ONLY with "fully qualified" (i.e. > E.164) numbers. But as others have said before, we have to write these documents so that they're at least somewhat prescient. If we can see where some may assume that something can be done and we realize it can be a problem, it is our responsibility to make sure it doesn't happen. > However, IF an administration wants to insert domains that would > logically be associated with "incomplete" (i.e. NOT E.164) numbers, > then (i) it's a national admin issue and so their choice - we can't > stop them, and (ii) these would not be under the control of an ENUM > "End User//Registrant". We might as well put prohibitions on what > can go into the "co.uk." domain - this will certainly NOT be a domain > that will be free for folk to Register either. Correct. What we are trying to define is what a client can expect. If we can't say that E2U NAPTR records are verbotten for intermediate nodes then a client has no way of knowing when it makes a mistake. > We may need some document(s) advising what is sensible (or not) for > a National Administration to do, and what the technical implications > are by their actions, but 2916 is NOT that document, IMHO. The extreme minimalist approach you're suggesting is very dangerous. I tried that with the original DDDS specs and was a disaster. Over the years we've learned one truism: implementors will be willing to read one document, maybe two, thus, you really need to put the most important client side caveats into the main document or they'll be hopelessly screwed up. IMHO, this is a very important one to get right. I think the statement as suggested is fine, excpet for some possible explanation of what the word 'believes' means.... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 14:48:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28097 for ; Tue, 25 Mar 2003 14:48:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PK98408576 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 15:09:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK97O08571; Tue, 25 Mar 2003 15:09:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK6TO07628 for ; Tue, 25 Mar 2003 15:06:29 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27921 for ; Tue, 25 Mar 2003 14:45:33 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 01:23:00 -0500 Subject: Re: AW: [Enum] partial numbers proposed text changes From: Michael Mealling To: Stastny Richard Cc: enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF06B@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF06B@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048621590.32350.74.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 14:46:30 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-19 at 16:18, Stastny Richard wrote: > I propose the last sentence of the text to be deleted, because this is not possible anyway: > > "Because of this risk for > collissions, the flag E2U in the service field MUST NOT be used for > non-E.164 numbers." It is very possible... > Reason: > > According to the delegation policy within e164.arpa only domains mapping to valid E164 numbers may be created within the e164.arpa tree anyway. It is therefore not possible to create a domain with non-E164 within e164.arpa in the first place. Therefore there is no way to enter a NAPTR with E2U in such a non existing domain. > The fact that you insert '.' in between each number by the definition of how the DNS works, you have created an intermediate node at each and every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of intermediate DNS nodes. They're not valid according to ENUM but they are valid DNS labels and as such there is a non-zero chance that a client, not knowing anything about the US numbering plan, would query for a NAPTR record for some portion of that hierarchy. You may come to the conclusion that such a thing might be illegal but that's because you've been thinking about this for a while and you approach if from the standpoint of "that which is not explicitly allowed is illegal". Typical Internet developers use the "conservative in what you send, liberal in what you receive" method. That means many will read it just the opposite: "that which is not explicitly disallowed will be found 'in the wild' and thus is mandatory". If it is illegal then what's the harm of saying it explicitly? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 15:12:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00316 for ; Tue, 25 Mar 2003 15:12:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKXCt10361 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 15:33:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKXBO10356; Tue, 25 Mar 2003 15:33:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKRvO09877 for ; Tue, 25 Mar 2003 15:27:57 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29323 for ; Tue, 25 Mar 2003 15:06:59 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Tue, 25 Mar 2003 21:13:12 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF097@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzB/jw10xY/INjT/Cj4iX/NNTtZAAAS8FS From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2PKRvO09878 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi MM, we are talking two different things here, because of a terminology problem. A non-E.164 number is a number not in the E.164 numbering plan, e.g 911. What you mean is a "full E.164 number" as defined in E.164 containing CC N(S)N SN. What this is is defiend nationally. And some countries like Austria and Germany allow (unlimited) direct-dial-in behind the SN to extension numbers So your formulation would either disallow to enter the extensions in ENUM or disallow to enter the pilot number in ENUM. Both may be dialled on the PSTN So your proposal excludes some valid E.164 numbers to be entered in ENUM, which I strongly oppose for two reasons: 1. All E.164 numbers shall be possible in principle in ENUM 2. Which valid E.164 numbers are not to be entered in ENUM is an ITU-T and/or national matter. best regards Richard -----Ursprüngliche Nachricht----- Von: Michael Mealling [mailto:michael@neonym.net] Gesendet: Di 25.03.2003 20:46 An: Stastny Richard Cc: enum@ietf.org Betreff: Re: AW: [Enum] partial numbers proposed text changes On Wed, 2003-03-19 at 16:18, Stastny Richard wrote: > I propose the last sentence of the text to be deleted, because this is not possible anyway: > > "Because of this risk for > collissions, the flag E2U in the service field MUST NOT be used for > non-E.164 numbers." It is very possible... > Reason: > > According to the delegation policy within e164.arpa only domains mapping to valid E164 numbers may be created within the e164.arpa tree anyway. It is therefore not possible to create a domain with non-E164 within e164.arpa in the first place. Therefore there is no way to enter a NAPTR with E2U in such a non existing domain. > The fact that you insert '.' in between each number by the definition of how the DNS works, you have created an intermediate node at each and every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of intermediate DNS nodes. They're not valid according to ENUM but they are valid DNS labels and as such there is a non-zero chance that a client, not knowing anything about the US numbering plan, would query for a NAPTR record for some portion of that hierarchy. You may come to the conclusion that such a thing might be illegal but that's because you've been thinking about this for a while and you approach if from the standpoint of "that which is not explicitly allowed is illegal". Typical Internet developers use the "conservative in what you send, liberal in what you receive" method. That means many will read it just the opposite: "that which is not explicitly disallowed will be found 'in the wild' and thus is mandatory". If it is illegal then what's the harm of saying it explicitly? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 15:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00337 for ; Tue, 25 Mar 2003 15:12:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKXE610410 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 15:33:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKXEO10405; Tue, 25 Mar 2003 15:33:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKSuO09924 for ; Tue, 25 Mar 2003 15:28:56 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29506 for ; Tue, 25 Mar 2003 15:07:59 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 01:45:25 -0500 From: Michael Mealling To: enum@ietf.org Organization: Harriman Heavy Industries, Inc. Message-Id: <1048622935.32349.84.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 15:08:55 -0500 Content-Transfer-Encoding: 7bit Subject: [Enum] New Security Considerations section (including DNSSEC statements) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wanted to get this out earlier but my laptop died the afternoon after the ENUM meeting. The major change is the addition of several threat models taken from a DNSSEC security threats document. Its gotten a little lengthy but I think much more useful: 6. Security Considerations 6.1 DNS Security As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kind of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself. There are multiple types of attacks that can happen against DNS that ENUM implementations should be aware of. The following threats are taken from Threat Analysis Of The Domain Name System [9]: Packet Interception Some of the simplest threats against DNS are various forms of packet interception: monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so forth. In any of these scenarios, the attacker can simply tell either party (usually the resolver) whatever it wants that party to believe. While packet interception attacks are far from unique to DNS, DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network. ID Guessing and Query Prediction Since the ID field in the DNS header is only a 16-bit field and the server UDP port associated with DNS is a well-known value, there are only 2**32 possible combinations of ID and client UDP port for a given client and server. Thus it is possible for a reasonable brut force attack to allow an attacker to masquerade as a trusted server. In most respects, this attack is similar to a packet interception attack except that it does not require the attacker to be on a transit or shared network. Name-based Attacks Name-based attacks use the actual DNS caching behavior as a tool to insert bad data into a victim's cache, thus potentially subverting subsequent decisions based on DNS names. Most examples occur with CNAME, NS and DNAME RRS as they redirect a victim's query to another location. The common thread in all of these attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker's choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks. Betrayal By A Trusted Server Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent. Many client machines are only configured with stub resolvers, and use trusted servers to perform all of their DNS queries on their behalf. In many cases the trusted server is furnished by the user's ISP and advertised to the client via DHCP or PPP options. Besides accidental betrayal of this trust relationship (via server bugs, successful server break-ins, etc), the server itself may be configured to give back answers that are not what the user would expect (whether in an honest attempt to help the user or to further some other goal such as furthering a business partnership between the ISP and some third party). Denial of Service As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks. DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets. Authenticated Denial of Domain Names The existence of RR types whose absence causes an action other than immediate failure (such as missing MX and SRV RRs, which fail over to A RRs) constitutes a real threat. In the specific case of ENUM, even the immediate failure of a missing RR can be considered a problem as a method for changing call routing policy. Because of these threats, a deployed ENUM service SHOULD include mechanisms which ameliorate these threats. Most of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC (Section 6.1) once it is deployed. Others, such and Denial Of Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV and A records). Even if DNSSEC is deployed, a service which uses ENUM for address translation should not blindly trust that the peer is the intended party as all kind of attacks against DNS can not be protected against with DNSSEC. A service should always authenticate the peers as part of the setup process for the service itself and never blindly trust any kind of addressing mechanism. Finally, as an ENUM services will be implementing some type of security mechanism, software which implements ENUM MUST be prepared to recieve DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, unknown RRs, etc. 6.2 Caching Security The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [8]) must therefore be done very carefully. 6.3 Call Routing Security There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. 6.4 URI Resolution Security A large amount of Security Issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the ENUM Enumservice used, as specified in Section 3.1.3. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 15:17:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00892 for ; Tue, 25 Mar 2003 15:17:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKbim11534 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 15:37:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKbiO11529; Tue, 25 Mar 2003 15:37:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKWvO10304 for ; Tue, 25 Mar 2003 15:32:57 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00193 for ; Tue, 25 Mar 2003 15:12:00 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Tue, 25 Mar 2003 21:18:13 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF098@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Enum] partial numbers proposed text changes Thread-Index: AcLzBtUJ8eOqn35SQwGFRHfJ9YHyFAABFV95 From: "Stastny Richard" To: "Michael Mealling" , "Conroy, Lawrence (SMTP)" Cc: "Peterson, Jon" , , "Rudi on the road" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2PKWvO10305 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit He Michael, I think you now are getting a bit ahead of yourself ;-) >Over the >years we've learned one truism: implementors will be willing to read one >document, maybe two, thus, you really need to put the most important client side caveats into the main document or they'll be hopelessly screwed up. IMHO, this is a very important one to get right. Now I finally understand why you put the DDDS in five documents;-) Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Mar 25 18:09:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09574 for ; Tue, 25 Mar 2003 18:09:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PNTYc26162 for enum-archive@odin.ietf.org; Tue, 25 Mar 2003 18:29:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNTSO26146; Tue, 25 Mar 2003 18:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNSoO26096 for ; Tue, 25 Mar 2003 18:28:50 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09345 for ; Tue, 25 Mar 2003 18:07:48 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 23:10:08 -0000 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HSB1WZYS; Tue, 25 Mar 2003 23:10:04 -0000 From: "Conroy, Lawrence (SMTP)" To: Michael Mealling , Stastny Richard Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1048621590.32350.74.camel@blackdell.neonym.net> References: <06CF906FE3998C4E944213062009F1620DF06B@oefeg-s02.oefeg.loc> <1048621590.32350.74.camel@blackdell.neonym.net> Date: Tue, 25 Mar 2003 23:09:57 +0000 Subject: Re: AW: [Enum] partial numbers proposed text changes Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PNSoO26097 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Michael, Richard St, Folks, First, glad to hear that the Portable came back to life, Michael. Hmm.... What I meant (and I suspect Richard means, although he may just have heatstroke from Copacabana :), was that if the T1 holds NS entries only for the domains associated with "full" E.164 numbers, then there won't be any domains pointed to that are not associated with a "full" E.164 number. This seems to be the plan I've seen in the existing Admin documents. The only time there could be an issue is if the T1 had an NS record for a domain logically associated with an "incomplete" number, and the zone file for that domain included E2U NAPTRs. (see end **). An "end user" Registrant will not be allowed to register such a domain, so it's all the fault of the evil Administration that has handed out this domain to one of their agents who has put a NAPTR into it. I can guess that the collective ITU/ETSI/ comment is going to be "none of your business", because it's a domain that they have allocated for their own use, not an "end user" Registrant. So...by doing this we are telling ITU/ what they cannot put into "their" domains. Interesting... I reiterate that we can and should ADVISE Administrations what they SHOULD and SHOULD NOT put into their domains, but that's another doc. I'm all for being liberal with what we accept, and don't like this prohibition. Thus, can we reduce this from its current MUST NOT? The only folk who will be in the position to install a E2U NAPTR into domains associated with these apparently "incomplete" E.164 numbers are Administrations or their agents, where the benighted Administration has chosen to have NS'd out these "intermediate" domains, so it isn't a problem for us mere mortal Registrants. ** BTW, Richard St, did the esteemed French delegation propose such a split out for +33 at some point? I couldn't quite understand their proposal, and am unaware of any other proposal to have such a separate NS at the "number block" level rather than the full/leaf number level. all the best, Lawrence In response to this that, at 2:46 pm -0500 25/3/03, Michael Mealling wrote: >On Wed, 2003-03-19 at 16:18, Stastny Richard wrote: >> I propose the last sentence of the text to be deleted, because >>this is not possible anyway: >>  >> "Because of this risk for >> collissions, the flag E2U in the service field MUST NOT be used for >> non-E.164 numbers." > >It is very possible... > >> Reason: >> >> According to the delegation policy within e164.arpa only domains >>mapping to valid E164 numbers may be created within the e164.arpa >>tree anyway. It is therefore not possible to create a domain with >>non-E164 within e164.arpa in the first place. Therefore there is no >>way to enter a NAPTR with E2U in such a non existing domain. >> > >The fact that you insert '.' in between each number by the definition of >how the DNS works, you have created an intermediate node at each and >every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of >intermediate DNS nodes. They're not valid according to ENUM but they are >valid DNS labels and as such there is a non-zero chance that a client, >not knowing anything about the US numbering plan, would query >for a NAPTR record for some portion of that hierarchy. > >You may come to the conclusion that such a thing might be illegal but >that's because you've been thinking about this for a while and you >approach if from the standpoint of "that which is not explicitly allowed >is illegal". Typical Internet developers use the "conservative in what >you send, liberal in what you receive" method. That means many will read >it just the opposite: "that which is not explicitly disallowed will be >found 'in the wild' and thus is mandatory". If it is illegal then what's >the harm of saying it explicitly? > >-MM -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 07:03:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22375 for ; Wed, 26 Mar 2003 07:03:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QCNoM22826 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 07:23:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCNiO22820; Wed, 26 Mar 2003 07:23:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCMxO22794 for ; Wed, 26 Mar 2003 07:22:59 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22365 for ; Wed, 26 Mar 2003 07:01:41 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 13:07:56 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF099@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzJEBDhUg3GcDSSvmK2OR3sdwahAAakrBr From: "Stastny Richard" To: "Conroy, Lawrence (SMTP)" , "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QCMxO22795 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Lawrence, ** BTW, Richard St, did the esteemed French delegation propose such a split out for +33 at some point? I couldn't quite understand their proposal, and am unaware of any other proposal to have such a separate NS at the "number block" level rather than the full/leaf number level. The French proposal and one of the possible models in the ETSI TS on Admin allow for splitting up the Tier 1 (e.g. 1a and 1b). Also in the US one of the possible models is to delegate CC 1 from T0 to a NANPA tier and the delegate to the area codes to the T1s (currently in the US the direct delegation from T0 to T1 in US is preferred). In France it is the other way round: CC 33 is delegated to the French T1a the T1a delegates to the T1b operated by the TSP holding the numbering range, which in turn delegated to the Tier 2. The special thing in France is IMHO that this T2 is also operated by the TSP and the ENUM subsciber is going thru the ASP, which is changing the NAPTR on his behalf. regards Richard PS: The weather here is not soo hot, only approx 26-28 C ;-) _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 07:37:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23795 for ; Wed, 26 Mar 2003 07:37:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QCwFD25038 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 07:58:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCwFO25032; Wed, 26 Mar 2003 07:58:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCvHO24972 for ; Wed, 26 Mar 2003 07:57:17 -0500 Received: from mag05.bb.admin.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23750 for ; Wed, 26 Mar 2003 07:35:58 -0500 (EST) From: Olivier.Girard@bakom.admin.ch Received: from mar01.bb.admin.ch (mar01.bb.admin.ch [193.5.222.71]) by mag05.bb.admin.ch (8.12.8/8.12.8) with ESMTP id h2QCcHDL020438; Wed, 26 Mar 2003 13:38:18 +0100 (MET) Received: from mas21.bb.admin.ch (mas21.bb.admin.ch [193.5.222.82]) by mar01.bb.admin.ch (8.12.8/8.12.8) with SMTP id h2QCcHck005497; Wed, 26 Mar 2003 13:38:17 +0100 (MET) Received: by ad01008exc.ad.admin.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 13:38:17 +0100 Message-ID: To: Richard.Stastny@oefeg.at, lwc@roke.co.uk, michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 12:38:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Dear All, Just a little question: Assuming that Tier-1 is responsible for the management of the zone corresponding to the E.164 country code, would splitting further delegations (e.g. to map the allocated number blocks) not be at the Tier-2 level rather than at Tier-1 level ? I mean, in the French case Tier-1 is managing the zone 3.3.e164.arpa and then Tier-2a is managing the zone corresponding to its number blocks and Tier-2b the NAPTRs)... It's a detail, I know, but as the agreement IAB/ITU-T is dealing with the relation between Tier-0 and Tier-1 we should have clear definitions... Am I wrong ? Regards, olivier > -----Original Message----- > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 1:08 PM > To: Conroy, Lawrence (SMTP); Michael Mealling > Cc: enum@ietf.org > Subject: AW: AW: [Enum] partial numbers proposed text changes > > Hi Lawrence, > > ** BTW, Richard St, did the esteemed French delegation propose such > a split out for +33 at some point? I couldn't quite understand their > proposal, and am unaware of any other proposal to have such a > separate > NS at the "number block" level rather than the full/leaf number > level. > > > The French proposal and one of the possible models in the ETSI TS on Admin > allow for splitting up the Tier 1 (e.g. 1a and 1b). Also in the US one of > the possible > models is to delegate CC 1 from T0 to a NANPA tier and the delegate to the > area codes to the T1s (currently in the US the direct delegation from T0 > to T1 in US > is preferred). In France it is the other way round: CC 33 is delegated to > the French T1a > the T1a delegates to the T1b operated by the TSP holding the numbering > range, which in turn delegated to the Tier 2. The special thing in France > is IMHO that > this T2 is also operated by the TSP and the ENUM subsciber is going thru > the ASP, > which is changing the NAPTR on his behalf. > > regards > Richard > PS: The weather here is not soo hot, only approx 26-28 C ;-) > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Mar 26 08:07:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24594 for ; Wed, 26 Mar 2003 08:07:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDSbD27515 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 08:28:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDSXO27507; Wed, 26 Mar 2003 08:28:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDOkO27276 for ; Wed, 26 Mar 2003 08:24:46 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24482 for ; Wed, 26 Mar 2003 08:03:26 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 14:09:42 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF09C@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzlSR9SJqQOKKsSg2YZkpmgLfKwwAAaSRk From: "Stastny Richard" To: , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QDOkO27277 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Oliver, you should know better;-) Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with Tier 1 Registry Part A and Tier 1 Registry Part B. The ENUM Tier 2 is defined there as the level corresponding to the E.164 Number CC N(S)N, which is the national (significant) number. So all levels above must belong to Tier 1. best regards Richard -----Ursprüngliche Nachricht----- Von: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Gesendet: Mi 26.03.2003 12:38 An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Betreff: RE: AW: [Enum] partial numbers proposed text changes Dear All, Just a little question: Assuming that Tier-1 is responsible for the management of the zone corresponding to the E.164 country code, would splitting further delegations (e.g. to map the allocated number blocks) not be at the Tier-2 level rather than at Tier-1 level ? I mean, in the French case Tier-1 is managing the zone 3.3.e164.arpa and then Tier-2a is managing the zone corresponding to its number blocks and Tier-2b the NAPTRs)... It's a detail, I know, but as the agreement IAB/ITU-T is dealing with the relation between Tier-0 and Tier-1 we should have clear definitions... Am I wrong ? Regards, olivier > -----Original Message----- > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 1:08 PM > To: Conroy, Lawrence (SMTP); Michael Mealling > Cc: enum@ietf.org > Subject: AW: AW: [Enum] partial numbers proposed text changes > > Hi Lawrence, > > ** BTW, Richard St, did the esteemed French delegation propose such > a split out for +33 at some point? I couldn't quite understand their > proposal, and am unaware of any other proposal to have such a > separate > NS at the "number block" level rather than the full/leaf number > level. > > > The French proposal and one of the possible models in the ETSI TS on Admin > allow for splitting up the Tier 1 (e.g. 1a and 1b). Also in the US one of > the possible > models is to delegate CC 1 from T0 to a NANPA tier and the delegate to the > area codes to the T1s (currently in the US the direct delegation from T0 > to T1 in US > is preferred). In France it is the other way round: CC 33 is delegated to > the French T1a > the T1a delegates to the T1b operated by the TSP holding the numbering > range, which in turn delegated to the Tier 2. The special thing in France > is IMHO that > this T2 is also operated by the TSP and the ENUM subsciber is going thru > the ASP, > which is changing the NAPTR on his behalf. > > regards > Richard > PS: The weather here is not soo hot, only approx 26-28 C ;-) > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Mar 26 08:10:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24652 for ; Wed, 26 Mar 2003 08:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDVLV27713 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 08:31:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDVLO27708; Wed, 26 Mar 2003 08:31:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDSxO27576 for ; Wed, 26 Mar 2003 08:28:59 -0500 Received: from p-mail1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24580 for ; Wed, 26 Mar 2003 08:07:39 -0500 (EST) Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Wed, 26 Mar 2003 14:10:23 +0100 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 14:09:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Re: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 14:09:59 +0100 Message-ID: Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzJEBDhUg3GcDSSvmK2OR3sdwahAAakrBrAACLI3A= From: "FOUQUART Philippe FTRD/DAC/ISS" To: "Stastny Richard" Cc: X-OriginalArrivalTime: 26 Mar 2003 13:09:59.0727 (UTC) FILETIME=[014E9BF0:01C2F399] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QDSxO27577 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Richard, all, Although I'm certainly not entitled to speak on behalf of the, ahem, no-less esteemed French Administration, I should point out that the French model does indeed make it possible but isn't more specific than its US/UK counterparts in that respect. At this point, there is no decision made as to whether the French numbering plan should be split out, be it for trial or long-term implementation. Having said that, I think potential intermediate Tier 1 levels are only a matter of administration/responsibility that should not impact the Enum architecture. I thought (?) the consensus last week was that Enum was E.164, and the debate would now focus on 1) what is E.164 2) whether the word "believe" in the proposed text was appropriate. So my take on the "partial number" debate now: the term "partial" is misleading IMO, there are two types of numbers, E.164 and non-E.164. Although the French numbering plan is closed, I don't see how a valid E.164 number of open numbering plans could be a subpart of another valid E.164 number. Maybe, some clarification can be found in Appendix A of the E.164 Rec (which I believe is normative - sorry, I always get the 'Appendix/Annex thing' wrong). In Section "Unique identification of international number for geographic areas", clause A.4.3 reads: "The subscriber number provides unique identification of one subscriber irrespective of where the call is generated from within a local area identified by NDC, where applicable. _The subscriber number is a complete number and can therefore not be separated_." (same thing applies to global services or numbers for Networks.) So my understanding is that no valid E.164 number can be a subpart of another valid E.164 number, whether the plan's open, closed or anywhere in between, that'd break the "completeness property". I doesn't preclude anyone from using ISDN subaddresses and/or possibly relieve the constraint in dialling plans, but Enum only deals with E.164 numbering plans AFAIK. Hope this helps, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 1:08 PM > To: Conroy, Lawrence (SMTP); Michael Mealling > Cc: enum@ietf.org > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > Hi Lawrence, > > ** BTW, Richard St, did the esteemed French delegation > propose such > a split out for +33 at some point? I couldn't quite > understand their > proposal, and am unaware of any other proposal to have > such a separate > NS at the "number block" level rather than the > full/leaf number level. > > > The French proposal and one of the possible models in the > ETSI TS on Admin > allow for splitting up the Tier 1 (e.g. 1a and 1b). Also in > the US one of the possible > models is to delegate CC 1 from T0 to a NANPA tier and the > delegate to the > area codes to the T1s (currently in the US the direct > delegation from T0 to T1 in US > is preferred). In France it is the other way round: CC 33 is > delegated to the French T1a > the T1a delegates to the T1b operated by the TSP holding the numbering > range, which in turn delegated to the Tier 2. The special > thing in France is IMHO that > this T2 is also operated by the TSP and the ENUM subsciber is > going thru the ASP, > which is changing the NAPTR on his behalf. > > regards > Richard > PS: The weather here is not soo hot, only approx 26-28 C ;-) > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Mar 26 08:29:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25255 for ; Wed, 26 Mar 2003 08:29:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QDo8h29380 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 08:50:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDo7O29375; Wed, 26 Mar 2003 08:50:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QDnXO29332 for ; Wed, 26 Mar 2003 08:49:33 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25210 for ; Wed, 26 Mar 2003 08:28:12 -0500 (EST) Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h2QDOnGM017519 for ; Wed, 26 Mar 2003 07:30:32 -0600 (CST) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.019) id 3E6239C600F1DDA6; Wed, 26 Mar 2003 08:30:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AW: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 08:30:20 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A034D141F@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzlX/NZwKrb1SBSRKRlKEHNwAZ/wABIAPw From: "Pfautz, Penn L, ALABS" To: , , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QDnXO29333 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Olivier: The concept of the Tier 1 has been that it directs you to where the NAPTRs are for an individual number (Tier 2). It's part of the common cooperative infrastructure for ENUM unlike Tier 2 which can in principle (and probably will in the US implementation) be selected or maintained by the number assignee. Accordingly, if you want to map by number blocks I see that as being between Tier 0 and Tier 1 or as a mutli-level Tier 1. My advice is, build multi-level structures if they make sense but try to keep Tier 1/ Tier 2 distinction clean. I suppose in the French model as described in the email where there is no choice with respect to Tier 2 this is a little fuzzier but in the general model as discussed in the working group (and at the ITU) I prefer the usage suggested above. Penn Pfautz AT&T -----Original Message----- From: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Sent: Wednesday, March 26, 2003 6:38 AM To: Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Dear All, Just a little question: Assuming that Tier-1 is responsible for the management of the zone corresponding to the E.164 country code, would splitting further delegations (e.g. to map the allocated number blocks) not be at the Tier-2 level rather than at Tier-1 level ? I mean, in the French case Tier-1 is managing the zone 3.3.e164.arpa and then Tier-2a is managing the zone corresponding to its number blocks and Tier-2b the NAPTRs)... It's a detail, I know, but as the agreement IAB/ITU-T is dealing with the relation between Tier-0 and Tier-1 we should have clear definitions... Am I wrong ? Regards, olivier > -----Original Message----- > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 1:08 PM > To: Conroy, Lawrence (SMTP); Michael Mealling > Cc: enum@ietf.org > Subject: AW: AW: [Enum] partial numbers proposed text changes > > Hi Lawrence, > > ** BTW, Richard St, did the esteemed French delegation propose such > a split out for +33 at some point? I couldn't quite understand their > proposal, and am unaware of any other proposal to have such a > separate > NS at the "number block" level rather than the full/leaf number > level. > > > The French proposal and one of the possible models in the ETSI TS on Admin > allow for splitting up the Tier 1 (e.g. 1a and 1b). Also in the US one of > the possible > models is to delegate CC 1 from T0 to a NANPA tier and the delegate to the > area codes to the T1s (currently in the US the direct delegation from T0 > to T1 in US > is preferred). In France it is the other way round: CC 33 is delegated to > the French T1a > the T1a delegates to the T1b operated by the TSP holding the numbering > range, which in turn delegated to the Tier 2. The special thing in France > is IMHO that > this T2 is also operated by the TSP and the ENUM subsciber is going thru > the ASP, > which is changing the NAPTR on his behalf. > > regards > Richard > PS: The weather here is not soo hot, only approx 26-28 C ;-) > _______________________________________________ > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 08:43:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25820 for ; Wed, 26 Mar 2003 08:43:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QE49l30113 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 09:04:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QE48O30108; Wed, 26 Mar 2003 09:04:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QE32O30062 for ; Wed, 26 Mar 2003 09:03:02 -0500 Received: from p-mail2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25782 for ; Wed, 26 Mar 2003 08:41:41 -0500 (EST) Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail2 with InterScan Messaging Security Suite; Wed, 26 Mar 2003 14:49:20 +0100 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 14:44:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: AW: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 14:43:58 +0100 Message-ID: Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzlSR9SJqQOKKsSg2YZkpmgLfKwwAAaSRkAAFdDmA= From: "FOUQUART Philippe FTRD/DAC/ISS" To: "Stastny Richard" , Cc: X-OriginalArrivalTime: 26 Mar 2003 13:44:01.0992 (UTC) FILETIME=[C2978480:01C2F39D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QE32O30063 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > Tier 1 Registry Part A and Tier 1 Registry Part B. Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my understanding, this doesn't seem possible given the current ITU-T/IAB agreement (requests only applies to Country Codes, nothing below that). Maybe something different is meant/implied there, but I personally find it confusing too. Clarification would be welcome, maybe off-line. Sorry List, this is slightly off-topic. All the best, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 2:10 PM > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > Cc: enum@ietf.org > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > Hi Oliver, > > you should know better;-) > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > Tier 1 Registry Part A and Tier 1 Registry Part B. > > The ENUM Tier 2 is defined there as the level corresponding > to the E.164 Number CC N(S)N, which is the national > (significant) number. > > So all levels above must belong to Tier 1. > > best regards > Richard > > -----Ursprüngliche Nachricht----- > Von: Olivier.Girard@bakom.admin.ch > [mailto:Olivier.Girard@bakom.admin.ch] > Gesendet: Mi 26.03.2003 12:38 > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > Cc: enum@ietf.org > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > Dear All, > > Just a little question: > > Assuming that Tier-1 is responsible for the management > of the zone > corresponding to the E.164 country code, would > splitting further delegations > (e.g. to map the allocated number blocks) not be at the > Tier-2 level rather > than at Tier-1 level ? > > I mean, in the French case Tier-1 is managing the zone > 3.3.e164.arpa and > then Tier-2a is managing the zone corresponding to its > number blocks and > Tier-2b the NAPTRs)... > > It's a detail, I know, but as the agreement IAB/ITU-T > is dealing with the > relation between Tier-0 and Tier-1 we should have clear > definitions... > > Am I wrong ? > > Regards, > > olivier > > > > -----Original Message----- > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 1:08 PM > > To: Conroy, Lawrence (SMTP); Michael Mealling > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed > text changes > > > > Hi Lawrence, > > > > ** BTW, Richard St, did the esteemed French > delegation propose such > > a split out for +33 at some point? I couldn't > quite understand their > > proposal, and am unaware of any other proposal > to have such a > > separate > > NS at the "number block" level rather than the > full/leaf number > > level. > > > > > > The French proposal and one of the possible models in > the ETSI TS on Admin > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > Also in the US one of > > the possible > > models is to delegate CC 1 from T0 to a NANPA tier > and the delegate to the > > area codes to the T1s (currently in the US the direct > delegation from T0 > > to T1 in US > > is preferred). In France it is the other way round: > CC 33 is delegated to > > the French T1a > > the T1a delegates to the T1b operated by the TSP > holding the numbering > > range, which in turn delegated to the Tier 2. The > special thing in France > > is IMHO that > > this T2 is also operated by the TSP and the ENUM > subsciber is going thru > > the ASP, > > which is changing the NAPTR on his behalf. > > > > regards > > Richard > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > _______________________________________________ > > 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 09:00:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26506 for ; Wed, 26 Mar 2003 09:00:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QEL8032028 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 09:21:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEL7O32023; Wed, 26 Mar 2003 09:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEK0O31922 for ; Wed, 26 Mar 2003 09:20:00 -0500 Received: from mag05.bb.admin.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26430 for ; Wed, 26 Mar 2003 08:58:38 -0500 (EST) From: Olivier.Girard@bakom.admin.ch Received: from mar02.bb.admin.ch (mar02.bb.admin.ch [193.5.222.72]) by mag05.bb.admin.ch (8.12.8/8.12.8) with ESMTP id h2QE0wDL001411; Wed, 26 Mar 2003 15:00:58 +0100 (MET) Received: from mas21.bb.admin.ch (mas21.bb.admin.ch [193.5.222.82]) by mar02.bb.admin.ch (8.12.8/8.12.8) with SMTP id h2QE0vfb013119; Wed, 26 Mar 2003 15:00:57 +0100 (MET) Received: by ad01007exc.ad.admin.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 15:00:57 +0100 Message-ID: To: philippe.fouquart@rd.francetelecom.com, Richard.Stastny@oefeg.at, lwc@roke.co.uk, michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 15:00:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QEK0O31923 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Yes, thanks Philippe, that's exactly what I was referring to. In fact, if I have understood correctly Penn's answer, if a splitting is made between CC and CC+N(S)N, it implies always a multi Tier-1 (Tier-1a to Tier-1x...) where Tier-1a (higher in the hierarchy) is managing the zone corresponding to the CC. Or does it mean that a delegation where Tier-0 points to multiple Tier-1s (beyond the CC) is possible/allowed ? Regards, olivier > -----Original Message----- > From: FOUQUART Philippe FTRD/DAC/ISS > [SMTP:philippe.fouquart@rd.francetelecom.com] > Sent: Wednesday, March 26, 2003 2:44 PM > To: Stastny Richard; Olivier.Girard@bakom.admin.ch > Cc: enum@ietf.org > Subject: RE: AW: [Enum] partial numbers proposed text changes > > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where > Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my > understanding, this doesn't seem possible given the current ITU-T/IAB > agreement (requests only applies to Country Codes, nothing below that). > Maybe something different is meant/implied there, but I personally find it > confusing too. Clarification would be welcome, maybe off-line. > > Sorry List, this is slightly off-topic. > All the best, > > Philippe Fouquart > FTR&D/DAC/CAR > +33 (0) 1 45 29 58 13 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 2:10 PM > > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > > > > Hi Oliver, > > > > you should know better;-) > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > > > The ENUM Tier 2 is defined there as the level corresponding > > to the E.164 Number CC N(S)N, which is the national > > (significant) number. > > > > So all levels above must belong to Tier 1. > > > > best regards > > Richard > > > > -----Ursprüngliche Nachricht----- > > Von: Olivier.Girard@bakom.admin.ch > > [mailto:Olivier.Girard@bakom.admin.ch] > > Gesendet: Mi 26.03.2003 12:38 > > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > > > > > Dear All, > > > > Just a little question: > > > > Assuming that Tier-1 is responsible for the management > > of the zone > > corresponding to the E.164 country code, would > > splitting further delegations > > (e.g. to map the allocated number blocks) not be at the > > Tier-2 level rather > > than at Tier-1 level ? > > > > I mean, in the French case Tier-1 is managing the zone > > 3.3.e164.arpa and > > then Tier-2a is managing the zone corresponding to its > > number blocks and > > Tier-2b the NAPTRs)... > > > > It's a detail, I know, but as the agreement IAB/ITU-T > > is dealing with the > > relation between Tier-0 and Tier-1 we should have clear > > definitions... > > > > Am I wrong ? > > > > Regards, > > > > olivier > > > > > > > -----Original Message----- > > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 26, 2003 1:08 PM > > > To: Conroy, Lawrence (SMTP); Michael Mealling > > > Cc: enum@ietf.org > > > Subject: AW: AW: [Enum] partial numbers proposed > > text changes > > > > > > Hi Lawrence, > > > > > > ** BTW, Richard St, did the esteemed French > > delegation propose such > > > a split out for +33 at some point? I couldn't > > quite understand their > > > proposal, and am unaware of any other proposal > > to have such a > > > separate > > > NS at the "number block" level rather than the > > full/leaf number > > > level. > > > > > > > > > The French proposal and one of the possible models in > > the ETSI TS on Admin > > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > > Also in the US one of > > > the possible > > > models is to delegate CC 1 from T0 to a NANPA tier > > and the delegate to the > > > area codes to the T1s (currently in the US the direct > > delegation from T0 > > > to T1 in US > > > is preferred). In France it is the other way round: > > CC 33 is delegated to > > > the French T1a > > > the T1a delegates to the T1b operated by the TSP > > holding the numbering > > > range, which in turn delegated to the Tier 2. The > > special thing in France > > > is IMHO that > > > this T2 is also operated by the TSP and the ENUM > > subsciber is going thru > > > the ASP, > > > which is changing the NAPTR on his behalf. > > > > > > regards > > > Richard > > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > > _______________________________________________ > > > 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 > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 09:20:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27124 for ; Wed, 26 Mar 2003 09:20:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QEfY601385 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 09:41:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEfRO01376; Wed, 26 Mar 2003 09:41:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QEexO01348 for ; Wed, 26 Mar 2003 09:40:59 -0500 Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27106 for ; Wed, 26 Mar 2003 09:19:35 -0500 (EST) Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h2QEKrX2014407 for ; Wed, 26 Mar 2003 09:21:25 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.019) id 3E6239C600F25969; Wed, 26 Mar 2003 09:19:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AW: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 09:19:46 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A034D157A@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzoeW1j0CTbwHUQ8qeFmi3TI1a4gAACiHQ From: "Pfautz, Penn L, ALABS" To: , , , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QEexO01349 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Olivier: I think either a multi-level Tier 1 or a delegation below CC level from Tier 0 is possible. The ITU recommendation explicitly recognizes that in the case of an integrated numbering plan (like North America has) delegation from Tier 0 may take place at a lower level. The US ENUM Forum as noted prefers delegation at the 1+NPA level from Tier 0 as that's the highest level at which it's possible to distinguish US from other NANP numbering resources. Of course it would be simpler if all the NANP countries would agree to a unified Tier 1 but I'm not holding my breath... Penn -----Original Message----- From: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Sent: Wednesday, March 26, 2003 9:01 AM To: philippe.fouquart@rd.francetelecom.com; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Yes, thanks Philippe, that's exactly what I was referring to. In fact, if I have understood correctly Penn's answer, if a splitting is made between CC and CC+N(S)N, it implies always a multi Tier-1 (Tier-1a to Tier-1x...) where Tier-1a (higher in the hierarchy) is managing the zone corresponding to the CC. Or does it mean that a delegation where Tier-0 points to multiple Tier-1s (beyond the CC) is possible/allowed ? Regards, olivier > -----Original Message----- > From: FOUQUART Philippe FTRD/DAC/ISS > [SMTP:philippe.fouquart@rd.francetelecom.com] > Sent: Wednesday, March 26, 2003 2:44 PM > To: Stastny Richard; Olivier.Girard@bakom.admin.ch > Cc: enum@ietf.org > Subject: RE: AW: [Enum] partial numbers proposed text changes > > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where > Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my > understanding, this doesn't seem possible given the current ITU-T/IAB > agreement (requests only applies to Country Codes, nothing below that). > Maybe something different is meant/implied there, but I personally find it > confusing too. Clarification would be welcome, maybe off-line. > > Sorry List, this is slightly off-topic. > All the best, > > Philippe Fouquart > FTR&D/DAC/CAR > +33 (0) 1 45 29 58 13 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 2:10 PM > > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > > > > Hi Oliver, > > > > you should know better;-) > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > > > The ENUM Tier 2 is defined there as the level corresponding > > to the E.164 Number CC N(S)N, which is the national > > (significant) number. > > > > So all levels above must belong to Tier 1. > > > > best regards > > Richard > > > > -----Ursprüngliche Nachricht----- > > Von: Olivier.Girard@bakom.admin.ch > > [mailto:Olivier.Girard@bakom.admin.ch] > > Gesendet: Mi 26.03.2003 12:38 > > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > > > > > Dear All, > > > > Just a little question: > > > > Assuming that Tier-1 is responsible for the management > > of the zone > > corresponding to the E.164 country code, would > > splitting further delegations > > (e.g. to map the allocated number blocks) not be at the > > Tier-2 level rather > > than at Tier-1 level ? > > > > I mean, in the French case Tier-1 is managing the zone > > 3.3.e164.arpa and > > then Tier-2a is managing the zone corresponding to its > > number blocks and > > Tier-2b the NAPTRs)... > > > > It's a detail, I know, but as the agreement IAB/ITU-T > > is dealing with the > > relation between Tier-0 and Tier-1 we should have clear > > definitions... > > > > Am I wrong ? > > > > Regards, > > > > olivier > > > > > > > -----Original Message----- > > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 26, 2003 1:08 PM > > > To: Conroy, Lawrence (SMTP); Michael Mealling > > > Cc: enum@ietf.org > > > Subject: AW: AW: [Enum] partial numbers proposed > > text changes > > > > > > Hi Lawrence, > > > > > > ** BTW, Richard St, did the esteemed French > > delegation propose such > > > a split out for +33 at some point? I couldn't > > quite understand their > > > proposal, and am unaware of any other proposal > > to have such a > > > separate > > > NS at the "number block" level rather than the > > full/leaf number > > > level. > > > > > > > > > The French proposal and one of the possible models in > > the ETSI TS on Admin > > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > > Also in the US one of > > > the possible > > > models is to delegate CC 1 from T0 to a NANPA tier > > and the delegate to the > > > area codes to the T1s (currently in the US the direct > > delegation from T0 > > > to T1 in US > > > is preferred). In France it is the other way round: > > CC 33 is delegated to > > > the French T1a > > > the T1a delegates to the T1b operated by the TSP > > holding the numbering > > > range, which in turn delegated to the Tier 2. The > > special thing in France > > > is IMHO that > > > this T2 is also operated by the TSP and the ENUM > > subsciber is going thru > > > the ASP, > > > which is changing the NAPTR on his behalf. > > > > > > regards > > > Richard > > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > > _______________________________________________ > > > 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 > > _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 26 10:50:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01497 for ; Wed, 26 Mar 2003 10:50:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGBmE08335 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:11:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGBdO08329; Wed, 26 Mar 2003 11:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGAdO08293 for ; Wed, 26 Mar 2003 11:10:39 -0500 Received: from p-mail1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01411 for ; Wed, 26 Mar 2003 10:49:16 -0500 (EST) Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Wed, 26 Mar 2003 16:50:20 +0100 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 16:49:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 16:49:55 +0100 Message-ID: Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzoeW1j0CTbwHUQ8qeFmi3TI1a4gAACiHQAACSzqA= From: "FOUQUART Philippe FTRD/DAC/ISS" To: "Pfautz, Penn L, ALABS" Cc: , , , , X-OriginalArrivalTime: 26 Mar 2003 15:49:56.0210 (UTC) FILETIME=[5941B520:01C2F3AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QGAdO08294 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Penn, Thanks for clarifying. I'm not aware of any ITU-T Recommendation on this matter but I guess you're referring to the interim procedures agreed between IAB and ITU-T. I'll try to explain why this direct tier 0 => multi-tiered link for one specific country is somewhat confusing: There are actually two (independent) sets of procedures for insertion in e164.arpa: one applies to country codes identifying a specific country ("geographic country codes", approved in May, amended in December), and another applies to countries in an integrated numbering plan among others ("Interim procedures for the delegation of shared E.164 Country Codes and their associated Identification Codes (ICs) for Networks and Group Identification Codes (GICs) for Groups of Countries", approved in December). There's no overlapping, we can't apply one set of procedures to the resources of the other. I understand your point, we could perfectly apply the principles that pertain to the "integrated numbering plan" case to country codes identifying a specific country, but if we stick to instructions to the letter (which is what they're here for) and because ITU-T is not supposed to bother about national matters, I still can't see how some direct tier 0 => multi-tiered is possible. Now, maybe we're missing something. Thanks, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 -----Original Message----- From: Pfautz, Penn L, ALABS [mailto:ppfautz@att.com] Sent: Wednesday, March 26, 2003 3:20 PM To: Olivier.Girard@bakom.admin.ch; FOUQUART Philippe FTRD/DAC/ISS; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Olivier: I think either a multi-level Tier 1 or a delegation below CC level from Tier 0 is possible. The ITU recommendation explicitly recognizes that in the case of an integrated numbering plan (like North America has) delegation from Tier 0 may take place at a lower level. The US ENUM Forum as noted prefers delegation at the 1+NPA level from Tier 0 as that's the highest level at which it's possible to distinguish US from other NANP numbering resources. Of course it would be simpler if all the NANP countries would agree to a unified Tier 1 but I'm not holding my breath... Penn -----Original Message----- From: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Sent: Wednesday, March 26, 2003 9:01 AM To: philippe.fouquart@rd.francetelecom.com; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Yes, thanks Philippe, that's exactly what I was referring to. In fact, if I have understood correctly Penn's answer, if a splitting is made between CC and CC+N(S)N, it implies always a multi Tier-1 (Tier-1a to Tier-1x...) where Tier-1a (higher in the hierarchy) is managing the zone corresponding to the CC. Or does it mean that a delegation where Tier-0 points to multiple Tier-1s (beyond the CC) is possible/allowed ? Regards, olivier > -----Original Message----- > From: FOUQUART Philippe FTRD/DAC/ISS > [SMTP:philippe.fouquart@rd.francetelecom.com] > Sent: Wednesday, March 26, 2003 2:44 PM > To: Stastny Richard; Olivier.Girard@bakom.admin.ch > Cc: enum@ietf.org > Subject: RE: AW: [Enum] partial numbers proposed text changes > > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where > Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my > understanding, this doesn't seem possible given the current ITU-T/IAB > agreement (requests only applies to Country Codes, nothing below that). > Maybe something different is meant/implied there, but I personally find it > confusing too. Clarification would be welcome, maybe off-line. > > Sorry List, this is slightly off-topic. > All the best, > > Philippe Fouquart > FTR&D/DAC/CAR > +33 (0) 1 45 29 58 13 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 2:10 PM > > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > > > > Hi Oliver, > > > > you should know better;-) > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > > > The ENUM Tier 2 is defined there as the level corresponding > > to the E.164 Number CC N(S)N, which is the national > > (significant) number. > > > > So all levels above must belong to Tier 1. > > > > best regards > > Richard > > > > -----Ursprüngliche Nachricht----- > > Von: Olivier.Girard@bakom.admin.ch > > [mailto:Olivier.Girard@bakom.admin.ch] > > Gesendet: Mi 26.03.2003 12:38 > > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > > > > > Dear All, > > > > Just a little question: > > > > Assuming that Tier-1 is responsible for the management > > of the zone > > corresponding to the E.164 country code, would > > splitting further delegations > > (e.g. to map the allocated number blocks) not be at the > > Tier-2 level rather > > than at Tier-1 level ? > > > > I mean, in the French case Tier-1 is managing the zone > > 3.3.e164.arpa and > > then Tier-2a is managing the zone corresponding to its > > number blocks and > > Tier-2b the NAPTRs)... > > > > It's a detail, I know, but as the agreement IAB/ITU-T > > is dealing with the > > relation between Tier-0 and Tier-1 we should have clear > > definitions... > > > > Am I wrong ? > > > > Regards, > > > > olivier > > > > > > > -----Original Message----- > > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 26, 2003 1:08 PM > > > To: Conroy, Lawrence (SMTP); Michael Mealling > > > Cc: enum@ietf.org > > > Subject: AW: AW: [Enum] partial numbers proposed > > text changes > > > > > > Hi Lawrence, > > > > > > ** BTW, Richard St, did the esteemed French > > delegation propose such > > > a split out for +33 at some point? I couldn't > > quite understand their > > > proposal, and am unaware of any other proposal > > to have such a > > > separate > > > NS at the "number block" level rather than the > > full/leaf number > > > level. > > > > > > > > > The French proposal and one of the possible models in > > the ETSI TS on Admin > > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > > Also in the US one of > > > the possible > > > models is to delegate CC 1 from T0 to a NANPA tier > > and the delegate to the > > > area codes to the T1s (currently in the US the direct > > delegation from T0 > > > to T1 in US > > > is preferred). In France it is the other way round: > > CC 33 is delegated to > > > the French T1a > > > the T1a delegates to the T1b operated by the TSP > > holding the numbering > > > range, which in turn delegated to the Tier 2. The > > special thing in France > > > is IMHO that > > > this T2 is also operated by the TSP and the ENUM > > subsciber is going thru > > > the ASP, > > > which is changing the NAPTR on his behalf. > > > > > > regards > > > Richard > > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > > _______________________________________________ > > > 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 > > _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 26 11:02:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01898 for ; Wed, 26 Mar 2003 11:02:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGNEv09018 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:23:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGNDO09011; Wed, 26 Mar 2003 11:23:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGMRO08978 for ; Wed, 26 Mar 2003 11:22:27 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01858 for ; Wed, 26 Mar 2003 11:01:03 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 17:07:17 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF0A1@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzoeW1j0CTbwHUQ8qeFmi3TI1a4gAACiHQAACSzqAAAxj+Ig== From: "Stastny Richard" To: "FOUQUART Philippe FTRD/DAC/ISS" , "Pfautz, Penn L, ALABS" Cc: , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QGMRO08979 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit IMHO CC 1 is a GIC. These discussions shows that the whole issue is out of scope of this working group, this is ITU-T matter. We should not try to explain ITU Recs. So I fully support Dave. Richard -----Ursprüngliche Nachricht----- Von: FOUQUART Philippe FTRD/DAC/ISS [mailto:philippe.fouquart@rd.francetelecom.com] Gesendet: Mi 26.03.2003 16:49 An: Pfautz, Penn L, ALABS Cc: Olivier.Girard@bakom.admin.ch; Stastny Richard; lwc@roke.co.uk; michael@neonym.net; enum@ietf.org Betreff: Re: [Enum] partial numbers proposed text changes Hi Penn, Thanks for clarifying. I'm not aware of any ITU-T Recommendation on this matter but I guess you're referring to the interim procedures agreed between IAB and ITU-T. I'll try to explain why this direct tier 0 => multi-tiered link for one specific country is somewhat confusing: There are actually two (independent) sets of procedures for insertion in e164.arpa: one applies to country codes identifying a specific country ("geographic country codes", approved in May, amended in December), and another applies to countries in an integrated numbering plan among others ("Interim procedures for the delegation of shared E.164 Country Codes and their associated Identification Codes (ICs) for Networks and Group Identification Codes (GICs) for Groups of Countries", approved in December). There's no overlapping, we can't apply one set of procedures to the resources of the other. I understand your point, we could perfectly apply the principles that pertain to the "integrated numbering plan" case to country codes identifying a specific country, but if we stick to instructions to the letter (which is what they're here for) and because ITU-T is not supposed to bother about national matters, I still can't see how some direct tier 0 => multi-tiered is possible. Now, maybe we're missing something. Thanks, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 -----Original Message----- From: Pfautz, Penn L, ALABS [mailto:ppfautz@att.com] Sent: Wednesday, March 26, 2003 3:20 PM To: Olivier.Girard@bakom.admin.ch; FOUQUART Philippe FTRD/DAC/ISS; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Olivier: I think either a multi-level Tier 1 or a delegation below CC level from Tier 0 is possible. The ITU recommendation explicitly recognizes that in the case of an integrated numbering plan (like North America has) delegation from Tier 0 may take place at a lower level. The US ENUM Forum as noted prefers delegation at the 1+NPA level from Tier 0 as that's the highest level at which it's possible to distinguish US from other NANP numbering resources. Of course it would be simpler if all the NANP countries would agree to a unified Tier 1 but I'm not holding my breath... Penn -----Original Message----- From: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Sent: Wednesday, March 26, 2003 9:01 AM To: philippe.fouquart@rd.francetelecom.com; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Yes, thanks Philippe, that's exactly what I was referring to. In fact, if I have understood correctly Penn's answer, if a splitting is made between CC and CC+N(S)N, it implies always a multi Tier-1 (Tier-1a to Tier-1x...) where Tier-1a (higher in the hierarchy) is managing the zone corresponding to the CC. Or does it mean that a delegation where Tier-0 points to multiple Tier-1s (beyond the CC) is possible/allowed ? Regards, olivier > -----Original Message----- > From: FOUQUART Philippe FTRD/DAC/ISS > [SMTP:philippe.fouquart@rd.francetelecom.com] > Sent: Wednesday, March 26, 2003 2:44 PM > To: Stastny Richard; Olivier.Girard@bakom.admin.ch > Cc: enum@ietf.org > Subject: RE: AW: [Enum] partial numbers proposed text changes > > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where > Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my > understanding, this doesn't seem possible given the current ITU-T/IAB > agreement (requests only applies to Country Codes, nothing below that). > Maybe something different is meant/implied there, but I personally find it > confusing too. Clarification would be welcome, maybe off-line. > > Sorry List, this is slightly off-topic. > All the best, > > Philippe Fouquart > FTR&D/DAC/CAR > +33 (0) 1 45 29 58 13 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 2:10 PM > > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > > > > Hi Oliver, > > > > you should know better;-) > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > > > The ENUM Tier 2 is defined there as the level corresponding > > to the E.164 Number CC N(S)N, which is the national > > (significant) number. > > > > So all levels above must belong to Tier 1. > > > > best regards > > Richard > > > > -----Ursprüngliche Nachricht----- > > Von: Olivier.Girard@bakom.admin.ch > > [mailto:Olivier.Girard@bakom.admin.ch] > > Gesendet: Mi 26.03.2003 12:38 > > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > > > > > Dear All, > > > > Just a little question: > > > > Assuming that Tier-1 is responsible for the management > > of the zone > > corresponding to the E.164 country code, would > > splitting further delegations > > (e.g. to map the allocated number blocks) not be at the > > Tier-2 level rather > > than at Tier-1 level ? > > > > I mean, in the French case Tier-1 is managing the zone > > 3.3.e164.arpa and > > then Tier-2a is managing the zone corresponding to its > > number blocks and > > Tier-2b the NAPTRs)... > > > > It's a detail, I know, but as the agreement IAB/ITU-T > > is dealing with the > > relation between Tier-0 and Tier-1 we should have clear > > definitions... > > > > Am I wrong ? > > > > Regards, > > > > olivier > > > > > > > -----Original Message----- > > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 26, 2003 1:08 PM > > > To: Conroy, Lawrence (SMTP); Michael Mealling > > > Cc: enum@ietf.org > > > Subject: AW: AW: [Enum] partial numbers proposed > > text changes > > > > > > Hi Lawrence, > > > > > > ** BTW, Richard St, did the esteemed French > > delegation propose such > > > a split out for +33 at some point? I couldn't > > quite understand their > > > proposal, and am unaware of any other proposal > > to have such a > > > separate > > > NS at the "number block" level rather than the > > full/leaf number > > > level. > > > > > > > > > The French proposal and one of the possible models in > > the ETSI TS on Admin > > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > > Also in the US one of > > > the possible > > > models is to delegate CC 1 from T0 to a NANPA tier > > and the delegate to the > > > area codes to the T1s (currently in the US the direct > > delegation from T0 > > > to T1 in US > > > is preferred). In France it is the other way round: > > CC 33 is delegated to > > > the French T1a > > > the T1a delegates to the T1b operated by the TSP > > holding the numbering > > > range, which in turn delegated to the Tier 2. The > > special thing in France > > > is IMHO that > > > this T2 is also operated by the TSP and the ENUM > > subsciber is going thru > > > the ASP, > > > which is changing the NAPTR on his behalf. > > > > > > regards > > > Richard > > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > > _______________________________________________ > > > 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 > > _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 26 11:05:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01996 for ; Wed, 26 Mar 2003 11:05:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGQAF09177 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:26:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGQ9O09172; Wed, 26 Mar 2003 11:26:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGPkO09144 for ; Wed, 26 Mar 2003 11:25:46 -0500 Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01973 for ; Wed, 26 Mar 2003 11:04:23 -0500 (EST) Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h2QFv8XH024463 for ; Wed, 26 Mar 2003 11:05:57 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh0i.attrh.att.com (6.5.019) id 3E6239C600F386FF; Wed, 26 Mar 2003 11:04:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 11:04:26 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A034D191F@ACCLUST02EVS1.ugd.att.com> Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzoeW1j0CTbwHUQ8qeFmi3TI1a4gAACiHQAACSzqAAAzoJ4A== From: "Pfautz, Penn L, ALABS" To: "FOUQUART Philippe FTRD/DAC/ISS" Cc: , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QGPkO09145 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Philippe: You're right; the ITU document only mentions below CC in Tier 0 for integrated plans. Penn -----Original Message----- From: FOUQUART Philippe FTRD/DAC/ISS [mailto:philippe.fouquart@rd.francetelecom.com] Sent: Wednesday, March 26, 2003 10:50 AM To: Pfautz, Penn L, ALABS Cc: Olivier.Girard@bakom.admin.ch; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net; enum@ietf.org Subject: Re: [Enum] partial numbers proposed text changes Hi Penn, Thanks for clarifying. I'm not aware of any ITU-T Recommendation on this matter but I guess you're referring to the interim procedures agreed between IAB and ITU-T. I'll try to explain why this direct tier 0 => multi-tiered link for one specific country is somewhat confusing: There are actually two (independent) sets of procedures for insertion in e164.arpa: one applies to country codes identifying a specific country ("geographic country codes", approved in May, amended in December), and another applies to countries in an integrated numbering plan among others ("Interim procedures for the delegation of shared E.164 Country Codes and their associated Identification Codes (ICs) for Networks and Group Identification Codes (GICs) for Groups of Countries", approved in December). There's no overlapping, we can't apply one set of procedures to the resources of the other. I understand your point, we could perfectly apply the principles that pertain to the "integrated numbering plan" case to country codes identifying a specific country, but if we stick to instructions to the letter (which is what they're here for) and because ITU-T is not supposed to bother about national matters, I still can't see how some direct tier 0 => multi-tiered is possible. Now, maybe we're missing something. Thanks, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 -----Original Message----- From: Pfautz, Penn L, ALABS [mailto:ppfautz@att.com] Sent: Wednesday, March 26, 2003 3:20 PM To: Olivier.Girard@bakom.admin.ch; FOUQUART Philippe FTRD/DAC/ISS; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Olivier: I think either a multi-level Tier 1 or a delegation below CC level from Tier 0 is possible. The ITU recommendation explicitly recognizes that in the case of an integrated numbering plan (like North America has) delegation from Tier 0 may take place at a lower level. The US ENUM Forum as noted prefers delegation at the 1+NPA level from Tier 0 as that's the highest level at which it's possible to distinguish US from other NANP numbering resources. Of course it would be simpler if all the NANP countries would agree to a unified Tier 1 but I'm not holding my breath... Penn -----Original Message----- From: Olivier.Girard@bakom.admin.ch [mailto:Olivier.Girard@bakom.admin.ch] Sent: Wednesday, March 26, 2003 9:01 AM To: philippe.fouquart@rd.francetelecom.com; Richard.Stastny@oefeg.at; lwc@roke.co.uk; michael@neonym.net Cc: enum@ietf.org Subject: RE: AW: [Enum] partial numbers proposed text changes Yes, thanks Philippe, that's exactly what I was referring to. In fact, if I have understood correctly Penn's answer, if a splitting is made between CC and CC+N(S)N, it implies always a multi Tier-1 (Tier-1a to Tier-1x...) where Tier-1a (higher in the hierarchy) is managing the zone corresponding to the CC. Or does it mean that a delegation where Tier-0 points to multiple Tier-1s (beyond the CC) is possible/allowed ? Regards, olivier > -----Original Message----- > From: FOUQUART Philippe FTRD/DAC/ISS > [SMTP:philippe.fouquart@rd.francetelecom.com] > Sent: Wednesday, March 26, 2003 2:44 PM > To: Stastny Richard; Olivier.Girard@bakom.admin.ch > Cc: enum@ietf.org > Subject: RE: AW: [Enum] partial numbers proposed text changes > > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > Maybe what Olivier's referring to is actually Example 2 (Fig A.2) where > Tier 0 _directly_ points at multiple Tier 1s, not one CC. In my > understanding, this doesn't seem possible given the current ITU-T/IAB > agreement (requests only applies to Country Codes, nothing below that). > Maybe something different is meant/implied there, but I personally find it > confusing too. Clarification would be welcome, maybe off-line. > > Sorry List, this is slightly off-topic. > All the best, > > Philippe Fouquart > FTR&D/DAC/CAR > +33 (0) 1 45 29 58 13 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 26, 2003 2:10 PM > > To: Olivier.Girard@bakom.admin.ch; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Subject: AW: AW: [Enum] partial numbers proposed text changes > > > > > > Hi Oliver, > > > > you should know better;-) > > Please see ETSI TS 102 051 Example 4 Figure A.4 Two stage Tier 1 with > > Tier 1 Registry Part A and Tier 1 Registry Part B. > > > > The ENUM Tier 2 is defined there as the level corresponding > > to the E.164 Number CC N(S)N, which is the national > > (significant) number. > > > > So all levels above must belong to Tier 1. > > > > best regards > > Richard > > > > -----Ursprüngliche Nachricht----- > > Von: Olivier.Girard@bakom.admin.ch > > [mailto:Olivier.Girard@bakom.admin.ch] > > Gesendet: Mi 26.03.2003 12:38 > > An: Stastny Richard; lwc@roke.co.uk; michael@neonym.net > > Cc: enum@ietf.org > > Betreff: RE: AW: [Enum] partial numbers proposed text changes > > > > > > > > Dear All, > > > > Just a little question: > > > > Assuming that Tier-1 is responsible for the management > > of the zone > > corresponding to the E.164 country code, would > > splitting further delegations > > (e.g. to map the allocated number blocks) not be at the > > Tier-2 level rather > > than at Tier-1 level ? > > > > I mean, in the French case Tier-1 is managing the zone > > 3.3.e164.arpa and > > then Tier-2a is managing the zone corresponding to its > > number blocks and > > Tier-2b the NAPTRs)... > > > > It's a detail, I know, but as the agreement IAB/ITU-T > > is dealing with the > > relation between Tier-0 and Tier-1 we should have clear > > definitions... > > > > Am I wrong ? > > > > Regards, > > > > olivier > > > > > > > -----Original Message----- > > > From: Stastny Richard [SMTP:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, March 26, 2003 1:08 PM > > > To: Conroy, Lawrence (SMTP); Michael Mealling > > > Cc: enum@ietf.org > > > Subject: AW: AW: [Enum] partial numbers proposed > > text changes > > > > > > Hi Lawrence, > > > > > > ** BTW, Richard St, did the esteemed French > > delegation propose such > > > a split out for +33 at some point? I couldn't > > quite understand their > > > proposal, and am unaware of any other proposal > > to have such a > > > separate > > > NS at the "number block" level rather than the > > full/leaf number > > > level. > > > > > > > > > The French proposal and one of the possible models in > > the ETSI TS on Admin > > > allow for splitting up the Tier 1 (e.g. 1a and 1b). > > Also in the US one of > > > the possible > > > models is to delegate CC 1 from T0 to a NANPA tier > > and the delegate to the > > > area codes to the T1s (currently in the US the direct > > delegation from T0 > > > to T1 in US > > > is preferred). In France it is the other way round: > > CC 33 is delegated to > > > the French T1a > > > the T1a delegates to the T1b operated by the TSP > > holding the numbering > > > range, which in turn delegated to the Tier 2. The > > special thing in France > > > is IMHO that > > > this T2 is also operated by the TSP and the ENUM > > subsciber is going thru > > > the ASP, > > > which is changing the NAPTR on his behalf. > > > > > > regards > > > Richard > > > PS: The weather here is not soo hot, only approx 26-28 C ;-) > > > _______________________________________________ > > > 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 > > _______________________________________________ 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 mailnull@www1.ietf.org Wed Mar 26 11:29:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02734 for ; Wed, 26 Mar 2003 11:29:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGoX611328 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:50:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGoSO11322; Wed, 26 Mar 2003 11:50:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGnrO11246 for ; Wed, 26 Mar 2003 11:49:53 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02688 for ; Wed, 26 Mar 2003 11:28:30 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 22:05:53 -0500 Subject: Re: AW: AW: [Enum] partial numbers proposed text changes From: Michael Mealling To: Stastny Richard Cc: enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF097@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF097@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048696165.32350.131.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 11:29:25 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-03-25 at 15:13, Stastny Richard wrote: > Hi MM, > we are talking two different things here, because of a terminology problem. > A non-E.164 number is a number not in the E.164 numbering plan, e.g 911. yep... got that... > What you mean is a "full E.164 number" as defined in E.164 containing > CC N(S)N SN. What this is is defiend nationally. And some countries > like Austria and Germany allow (unlimited) direct-dial-in behind the SN to > extension numbers Correct. And because of that there is no way for a client application to know with 100% certainty that it has a fully qualified E164 number, correct? > So your formulation would either disallow to enter the extensions in ENUM > or disallow to enter the pilot number in ENUM. Both may be dialled on the PSTN > So your proposal excludes some valid E.164 numbers to be entered in ENUM, > which I strongly oppose for two reasons: > > 1. All E.164 numbers shall be possible in principle in ENUM > 2. Which valid E.164 numbers are not to be entered in ENUM is an > ITU-T and/or national matter. How did you come to the conclusion that I'm disallowing any E164 number? What I'm saying is that a number that isn't valid, but is syntactically correct, but which is also a subset of a valid number MUST not have any NAPTRs associated with it that contains 'E2U' in its Service field. Since I don't know if +99-209 is valid or not the only thing I can do is check it for syntax. I'm not 100% up on E164 syntax but from what I heard last week that is syntactically correct. If someone in France were to read this document and it said nothing about putting records at the interim 9.0.2.9.9.e164.arpa they may very well be tempted to do so. Which would cause my client to get an NAPTR record back for something that it shouldn't be able to do so. Hmm.... let me state this differently: E2U NAPTR records MUST not be inserted for numbers that are inconsistent with the numbering plan it appears under. I.e. if a number is invalid according to the numbering plan it must be invalid for ENUM as well. Is that better? -MM > > On Wed, 2003-03-19 at 16:18, Stastny Richard wrote: > > I propose the last sentence of the text to be deleted, because this is not possible anyway: > > > > "Because of this risk for > > collissions, the flag E2U in the service field MUST NOT be used for > > non-E.164 numbers." > > It is very possible... > > > Reason: > > > > According to the delegation policy within e164.arpa only domains mapping to valid E164 numbers may be created within the e164.arpa tree anyway. It is therefore not possible to create a domain with non-E164 within e164.arpa in the first place. Therefore there is no way to enter a NAPTR with E2U in such a non existing domain. > > > > The fact that you insert '.' in between each number by the definition of > how the DNS works, you have created an intermediate node at each and > every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of > intermediate DNS nodes. They're not valid according to ENUM but they are > valid DNS labels and as such there is a non-zero chance that a client, > not knowing anything about the US numbering plan, would query > for a NAPTR record for some portion of that hierarchy. > > You may come to the conclusion that such a thing might be illegal but > that's because you've been thinking about this for a while and you > approach if from the standpoint of "that which is not explicitly allowed > is illegal". Typical Internet developers use the "conservative in what > you send, liberal in what you receive" method. That means many will read > it just the opposite: "that which is not explicitly disallowed will be > found 'in the wild' and thus is mandatory". If it is illegal then what's > the harm of saying it explicitly? > > -MM > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 11:30:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02763 for ; Wed, 26 Mar 2003 11:30:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGpEI11392 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:51:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGpEO11387; Wed, 26 Mar 2003 11:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGorO11362 for ; Wed, 26 Mar 2003 11:50:53 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02732 for ; Wed, 26 Mar 2003 11:29:31 -0500 (EST) content-class: urn:content-classes:message Subject: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 17:35:45 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF0A2@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzJEBDhUg3GcDSSvmK2OR3sdwahAAakrBrAACLI3AACFscCg== From: "Stastny Richard" To: "FOUQUART Philippe FTRD/DAC/ISS" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QGorO11363 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Philippe, So my understanding is that no valid E.164 number can be a subpart of another valid E.164 number, whether the plan's open, closed or anywhere in between, that'd break the "completeness property". I doesn't preclude anyone from using ISDN subaddresses and/or possibly relieve the constraint in dialling plans, but Enum only deals with E.164 numbering plans AFAIK. Hope this helps, No is does not help me. As I already explained at the ENUM meeting last week, the number of my company is: +43 1 79780 This number is a perfect valid E.164 Number, because it defines the network termination of the PSTN. It is at the same time the pilot number of a hunt group with DDI. So my business number is: +43 1 79780 32 Maybe that this is in your definition no E.164 number, but you may reach it in from every country dialling the above number, because its less than 15 digits. So what? Now we come to the real question about "partial numbers" The partial number in this definition is the pilot number, because it is part of my office number. But the pilot is the "real" E.164 number. Where can I put now the NAPTRs? In the pilot or in my office number, or both? IMHO in both. If you dial +43179780 on the PSTN, you get the switchboard (aka secretary) If you dial +4317978032 you get the phone on my desk. So it is perfectly vailid to put a NAPTR pointing to to the SIP-phone on the secretaries desk in 0.8.7.9.7.1.3.4.e164.arpa and another NAPTR in 3.2.0.8.7.9.7.1.3.4.e164.arpa, pointing to the SIP phone on my desk. I do not want to see anything in rfc2916bis casting any confusion on this issue, because in this case the "partial" number is the real E.164 number and the other number is an "extended" number Even more so, because Patriks problem was different, he wanted to prevent automatic queries in the DNS by clients digit by digit, which I agree should not happen. The major reason why we did not implement this up to now where not DNS issues, but administrative issues (e.g the introduction of a "Tier 3" and Validation issues) best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 11:38:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03174 for ; Wed, 26 Mar 2003 11:38:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGwq011852 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 11:58:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGwoO11843; Wed, 26 Mar 2003 11:58:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGvqO11784 for ; Wed, 26 Mar 2003 11:57:52 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03114 for ; Wed, 26 Mar 2003 11:36:29 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2QGcJk02244; Wed, 26 Mar 2003 08:38:19 -0800 Date: Wed, 26 Mar 2003 08:38:21 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Reply-To: Dave Crocker Organization: TribalWise X-Priority: 3 (Normal) Message-ID: <565469920.20030326083821@dcrocker.net> To: Michael Mealling CC: "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "'Stastny Richard'" , , Rudi on the road Subject: Re: [Enum] partial numbers proposed text changes In-Reply-To: <1048621019.32425.65.camel@blackdell.neonym.net> References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> <1048621019.32425.65.camel@blackdell.neonym.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Tuesday, March 25, 2003, 11:36:59 AM, you wrote: MM> But as others have said before, we have to write these documents so that MM> they're at least somewhat prescient. If we can see where some may assume MM> that something can be done and we realize it can be a problem, it is our MM> responsibility to make sure it doesn't happen. My understanding, at the meeting, was that partial numbers were entirely outside the scope of this working group. if you want to anticipate that someone might do partial numbers, then just add a sentence that says that they are outside the scope of the specification. "outside" means outside. as in, nothing to do with. have have thereby acknowledged the possible future action, but done so in a way that leaves no one confused. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 11:51:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03688 for ; Wed, 26 Mar 2003 11:51:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHCVt13723 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 12:12:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHCSO13718; Wed, 26 Mar 2003 12:12:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QH9bO13531 for ; Wed, 26 Mar 2003 12:09:37 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03559 for ; Wed, 26 Mar 2003 11:48:14 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 17:54:29 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF0A3@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLztZ3CzmwI4KDTRYeRfM8ul1B1iAAAN11O From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QH9bO13533 Subject: [Enum] NAPTRs for invalid Numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi -MM, I think we have a point here which needs clarification, thats why I renamed the thread. >Hmm.... let me state this differently: E2U NAPTR records MUST not be >inserted for numbers that are inconsistent with the numbering plan it >appears under. I.e. if a number is invalid according to the numbering >plan it must be invalid for ENUM as well. Is that better? I like your second sentence insofar, that a number invalid according to the numbering plan must also be invalid for -now it comes- for ENUM delegation to ENUM Subscriber. The problem here is that rfc2916bis is talking nowhere about admin issues and ENUM subscribers. Now I come to the issue of NAPTRs for invalid numbers. In the existing phone system you get an indication if you dial an invalid or incomplete number. We have thought about if we can emulate this convinience to the user also in ENUM. One possibility is e.g. to provide wild card NAPTRs in invalid number ranges pointing to e.g. an annoncement. This NAPTRs would never be inserted by ENUM Subscribers, but by the Tier 1 Registry. Therefore I have some problems with your above statement. Any comments? Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 11:56:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03801 for ; Wed, 26 Mar 2003 11:56:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHH4c14010 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 12:17:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHH4O14005; Wed, 26 Mar 2003 12:17:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHGaO13967 for ; Wed, 26 Mar 2003 12:16:36 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03775 for ; Wed, 26 Mar 2003 11:55:13 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 22:31:55 -0500 Subject: Re: AW: [Enum] partial numbers proposed text changes From: Michael Mealling To: Stastny Richard Cc: "FOUQUART Philippe FTRD/DAC/ISS" , enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF0A2@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF0A2@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048697673.32350.142.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 11:54:33 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-26 at 11:35, Stastny Richard wrote: > Hi Philippe, > > So my understanding is that no valid E.164 number can be a subpart > of another valid E.164 number, whether the plan's open, closed or > anywhere in between, that'd break the "completeness property". I > doesn't preclude anyone from using ISDN subaddresses and/or possibly > relieve the constraint in dialling plans, but Enum only deals with > E.164 numbering plans AFAIK. > > Hope this helps, > > > No is does not help me. As I already explained at the ENUM meeting last week, the > number of my company is: > +43 1 79780 > This number is a perfect valid E.164 Number, because it defines the network termination > of the PSTN. > It is at the same time the pilot number of a hunt group with DDI. > > So my business number is: > +43 1 79780 32 > > Maybe that this is in your definition no E.164 number, but you may reach it in > from every country dialling the above number, because its less than 15 digits. > So what? > > Now we come to the real question about "partial numbers" > The partial number in this definition is the pilot number, because it > is part of my office number. But the pilot is the "real" E.164 number. > > Where can I put now the NAPTRs? > In the pilot or in my office number, or both? > > IMHO in both. > If you dial +43179780 on the PSTN, you get the switchboard (aka secretary) > If you dial +4317978032 you get the phone on my desk. Yes. Both. I don't think anyone is suggesting disallowing you from putting NAPTRs for both of those numbers. If you think I did suggest that then please accept my apology for not being clear. > So it is perfectly vailid to put a NAPTR pointing to to the SIP-phone > on the secretaries desk in 0.8.7.9.7.1.3.4.e164.arpa > and another NAPTR in 3.2.0.8.7.9.7.1.3.4.e164.arpa, > pointing to the SIP phone on my desk. > > I do not want to see anything in rfc2916bis casting any confusion > on this issue, because in this case the "partial" number is the real > E.164 number and the other number is an "extended" number > > Even more so, because Patriks problem was different, > he wanted to prevent automatic queries in the DNS by clients digit by digit, > which I agree should not happen. And my issue is that, since I don't know anything about your numbering plan, I could very easily make a request for +431797 (minus the last two digits). What I don't want to happen is for you to be putting NAPTR records with E2U services in them for that number _IF_ you also consider that number to be invalid. So help me make that statement that jives with what you're after so that someone that hasn't personally administered numbering plans can understand it. > The major reason why we did not implement this up to now where not > DNS issues, but administrative issues (e.g the introduction of a "Tier 3" and > Validation issues) This particular issue is a protocol level scoping and error condition case that needs to be addressed in this document because it affects how _all_ clients have to be implemented. It is solved by a server side management solution but the client has to know what it can expect universally. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 11:59:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03866 for ; Wed, 26 Mar 2003 11:59:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHK8O14188 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 12:20:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHK8O14183; Wed, 26 Mar 2003 12:20:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHJnO14122 for ; Wed, 26 Mar 2003 12:19:49 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03849 for ; Wed, 26 Mar 2003 11:58:26 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 22:34:54 -0500 Subject: Re: [Enum] partial numbers proposed text changes From: Michael Mealling To: Dave Crocker Cc: "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "'Stastny Richard'" , enum@ietf.org, Rudi on the road In-Reply-To: <565469920.20030326083821@dcrocker.net> References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> <1048621019.32425.65.camel@blackdell.neonym.net> <565469920.20030326083821@dcrocker.net> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048697857.32425.146.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 11:57:37 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-26 at 11:38, Dave Crocker wrote: > Folks, > > Tuesday, March 25, 2003, 11:36:59 AM, you wrote: > > MM> But as others have said before, we have to write these documents so that > MM> they're at least somewhat prescient. If we can see where some may assume > MM> that something can be done and we realize it can be a problem, it is our > MM> responsibility to make sure it doesn't happen. > > My understanding, at the meeting, was that partial numbers were entirely > outside the scope of this working group. > > if you want to anticipate that someone might do partial numbers, then > just add a sentence that says that they are outside the scope of the > specification. > > "outside" means outside. as in, nothing to do with. > > have have thereby acknowledged the possible future action, but done so > in a way that leaves no one confused. With the exception that you have now created a case where a client cannot know when it is 'in scope' and thus within its rights to expect compliant behavior and when it is 'out of scope'. I'm not attempting to make any statements about 'partial numbers' themselves other than to define them so they can be declared out of scope syntactically. Right now there is no way to tell what the 'scope' actually is from a client implementation... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:10:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04306 for ; Wed, 26 Mar 2003 12:10:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHVYN14884 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 12:31:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHVXO14875; Wed, 26 Mar 2003 12:31:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHUZO14756 for ; Wed, 26 Mar 2003 12:30:35 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04248 for ; Wed, 26 Mar 2003 12:09:11 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 25 Mar 2003 22:46:33 -0500 From: Michael Mealling To: Stastny Richard Cc: enum@ietf.org In-Reply-To: <06CF906FE3998C4E944213062009F1620DF0A3@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F1620DF0A3@oefeg-s02.oefeg.loc> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048698605.32349.155.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 12:10:06 -0500 Content-Transfer-Encoding: 7bit Subject: [Enum] Re: NAPTRs for invalid Numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-26 at 11:54, Stastny Richard wrote: > Hi -MM, > > I think we have a point here which needs clarification, thats why I renamed the thread. > > >Hmm.... let me state this differently: E2U NAPTR records MUST not be > >inserted for numbers that are inconsistent with the numbering plan it > >appears under. I.e. if a number is invalid according to the numbering > >plan it must be invalid for ENUM as well. Is that better? > > I like your second sentence insofar, that a number invalid according > to the numbering plan must also be invalid for -now it comes- for > ENUM delegation to ENUM Subscriber. Just say an E2U specific NAPTR record. That was the consensus I heard. Anything beyond that simple statement was out scope. > The problem here is that rfc2916bis is talking nowhere about admin issues and > ENUM subscribers. > > Now I come to the issue of NAPTRs for invalid numbers. > > In the existing phone system you get an indication if you dial an invalid or incomplete number. > We have thought about if we can emulate this convinience to the user also in ENUM. > > One possibility is e.g. to provide wild card NAPTRs in invalid number ranges pointing > to e.g. an annoncement. This NAPTRs would never be inserted by ENUM Subscribers, > but by the Tier 1 Registry. > > Therefore I have some problems with your above statement. > > Any comments? When Jon and I were talking about this before last week I suggested at one point a new enumservice called 'notavalidnumber' which could designate non-valid but existing nodes so that clients would have a better ability to detect real errors. The reason we rejected it was that it would bring up all sorts of issues associated with what those intermediate nodes meant, how else could you use them, etc. And that would cause this document to never get published. So my suggestion is to make a simple statement of it being out of scope with a statement similar to what I say above. We publish this document and then those that care can go off and figure out what records at intermediate nodes means more concretely.... I'm just not comfortable with holding this document up while we investigate what this approach might mean, both from a protocol stand point and from a regulatory/admin standpoint.... -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05074 for ; Wed, 26 Mar 2003 12:42:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QI3Lr16984 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 13:03:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QI3EO16978; Wed, 26 Mar 2003 13:03:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QI2kO16940 for ; Wed, 26 Mar 2003 13:02:46 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04984 for ; Wed, 26 Mar 2003 12:41:21 -0500 (EST) content-class: urn:content-classes:message Subject: AW: AW: [Enum] partial numbers proposed text changes MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 18:47:35 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF0A4@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzuVjk7zliGL9vT1GPALCSD5U1zAAARdBy From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QI2kO16941 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi MM I think we are coming closer to the issue now: You wrote: >This particular issue is a protocol level scoping and error condition >case that needs to be addressed in this document because it affects how >_all_ clients have to be implemented. It is solved by a server side >management solution but the client has to know what it can expect >universally. I think we should consider two types of clients here: One is a user controlled client where a person is entering a phone number and then hits the return button. You have two choices here: send out the query as is or do some local checking of the validity of the entered digits. This is problematic because this may work for some CC and may not work for others. Furthermore the numbering plan may be changed at any time making your client useless. So we have to live with the first varient anyway. The second case is a client in a gateway or proxy. What you really want here is that the client is not starting querying ENUM before he has received the last digit. This means in bellhead quack _NO overlap outpulsing_. Only problem with this is that you may not know what the last digit is and have to put in a 5 second timeout, which is another hit on call setup time. But we have to live with this in the PSTN anyway. And this is IMHO what you really want to state. NAPTRs may be inserted anywhere, they do not hurt Therefore I propose: ENUM clients shall only query DNS en-block after assuming having received the last digit of the requested E.164 number. Multiple queries of partial number strings shall not be done. regards Richard -----Ursprüngliche Nachricht----- Von: Michael Mealling [mailto:michael@neonym.net] Gesendet: Mi 26.03.2003 17:54 An: Stastny Richard Cc: FOUQUART Philippe FTRD/DAC/ISS; enum@ietf.org Betreff: Re: AW: [Enum] partial numbers proposed text changes On Wed, 2003-03-26 at 11:35, Stastny Richard wrote: > Hi Philippe, > > So my understanding is that no valid E.164 number can be a subpart > of another valid E.164 number, whether the plan's open, closed or > anywhere in between, that'd break the "completeness property". I > doesn't preclude anyone from using ISDN subaddresses and/or possibly > relieve the constraint in dialling plans, but Enum only deals with > E.164 numbering plans AFAIK. > > Hope this helps, > > > No is does not help me. As I already explained at the ENUM meeting last week, the > number of my company is: > +43 1 79780 > This number is a perfect valid E.164 Number, because it defines the network termination > of the PSTN. > It is at the same time the pilot number of a hunt group with DDI. > > So my business number is: > +43 1 79780 32 > > Maybe that this is in your definition no E.164 number, but you may reach it in > from every country dialling the above number, because its less than 15 digits. > So what? > > Now we come to the real question about "partial numbers" > The partial number in this definition is the pilot number, because it > is part of my office number. But the pilot is the "real" E.164 number. > > Where can I put now the NAPTRs? > In the pilot or in my office number, or both? > > IMHO in both. > If you dial +43179780 on the PSTN, you get the switchboard (aka secretary) > If you dial +4317978032 you get the phone on my desk. Yes. Both. I don't think anyone is suggesting disallowing you from putting NAPTRs for both of those numbers. If you think I did suggest that then please accept my apology for not being clear. > So it is perfectly vailid to put a NAPTR pointing to to the SIP-phone > on the secretaries desk in 0.8.7.9.7.1.3.4.e164.arpa > and another NAPTR in 3.2.0.8.7.9.7.1.3.4.e164.arpa, > pointing to the SIP phone on my desk. > > I do not want to see anything in rfc2916bis casting any confusion > on this issue, because in this case the "partial" number is the real > E.164 number and the other number is an "extended" number > > Even more so, because Patriks problem was different, > he wanted to prevent automatic queries in the DNS by clients digit by digit, > which I agree should not happen. And my issue is that, since I don't know anything about your numbering plan, I could very easily make a request for +431797 (minus the last two digits). What I don't want to happen is for you to be putting NAPTR records with E2U services in them for that number _IF_ you also consider that number to be invalid. So help me make that statement that jives with what you're after so that someone that hasn't personally administered numbering plans can understand it. > The major reason why we did not implement this up to now where not > DNS issues, but administrative issues (e.g the introduction of a "Tier 3" and > Validation issues) This particular issue is a protocol level scoping and error condition case that needs to be addressed in this document because it affects how _all_ clients have to be implemented. It is solved by a server side management solution but the client has to know what it can expect universally. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:44:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05134 for ; Wed, 26 Mar 2003 12:44:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QI54Q17061 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 13:05:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QI54O17056; Wed, 26 Mar 2003 13:05:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QI4nO17032 for ; Wed, 26 Mar 2003 13:04:49 -0500 Received: from p-mail1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05108 for ; Wed, 26 Mar 2003 12:43:24 -0500 (EST) Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Wed, 26 Mar 2003 18:46:08 +0100 Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Mar 2003 18:45:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Enum] partial numbers proposed text changes Date: Wed, 26 Mar 2003 18:45:44 +0100 Message-ID: Thread-Topic: AW: [Enum] partial numbers proposed text changes Thread-Index: AcLzJEBDhUg3GcDSSvmK2OR3sdwahAAakrBrAACLI3AACFscCgADFyeg From: "FOUQUART Philippe FTRD/DAC/ISS" To: "Stastny Richard" Cc: X-OriginalArrivalTime: 26 Mar 2003 17:45:44.0803 (UTC) FILETIME=[86F0DB30:01C2F3BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QI4nO17033 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Where can I put now the NAPTRs? > In the pilot or in my office number, or both? > > IMHO in both. > If you dial +43179780 on the PSTN, you get the switchboard > (aka secretary) > If you dial +4317978032 you get the phone on my desk. I think we agree on this, the purpose is certainly not to forbid anyone from using one particular valid type of number in open numbering plans because they may not be possible in someone else's (closed) national numbering plan. I personally have some difficulty aligning this with the E.164 paragraph I quoted but that's off-topic. Best, Philippe Fouquart FTR&D/DAC/CAR +33 (0) 1 45 29 58 13 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 26, 2003 5:36 PM > To: FOUQUART Philippe FTRD/DAC/ISS > Cc: enum@ietf.org > Subject: AW: [Enum] partial numbers proposed text changes > > > Hi Philippe, > > So my understanding is that no valid E.164 number can > be a subpart of another valid E.164 number, whether the > plan's open, closed or anywhere in between, that'd break the > "completeness property". I doesn't preclude anyone from using > ISDN subaddresses and/or possibly relieve the constraint in > dialling plans, but Enum only deals with E.164 numbering plans AFAIK. > > Hope this helps, > > > No is does not help me. As I already explained at the ENUM > meeting last week, the > number of my company is: > +43 1 79780 > This number is a perfect valid E.164 Number, because it > defines the network termination > of the PSTN. > It is at the same time the pilot number of a hunt group with DDI. > > So my business number is: > +43 1 79780 32 > > Maybe that this is in your definition no E.164 number, but > you may reach it in > from every country dialling the above number, because its > less than 15 digits. > So what? > > Now we come to the real question about "partial numbers" > The partial number in this definition is the pilot number, because it > is part of my office number. But the pilot is the "real" E.164 number. > > Where can I put now the NAPTRs? > In the pilot or in my office number, or both? > > IMHO in both. > If you dial +43179780 on the PSTN, you get the switchboard > (aka secretary) > If you dial +4317978032 you get the phone on my desk. > > So it is perfectly vailid to put a NAPTR pointing to to the SIP-phone > on the secretaries desk in 0.8.7.9.7.1.3.4.e164.arpa > and another NAPTR in 3.2.0.8.7.9.7.1.3.4.e164.arpa, > pointing to the SIP phone on my desk. > > I do not want to see anything in rfc2916bis casting any confusion > on this issue, because in this case the "partial" number is the real > E.164 number and the other number is an "extended" number > > Even more so, because Patriks problem was different, > he wanted to prevent automatic queries in the DNS by clients > digit by digit, > which I agree should not happen. > > The major reason why we did not implement this up to now where not > DNS issues, but administrative issues (e.g the introduction > of a "Tier 3" and > Validation issues) > > best regards > > Richard > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:53:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05313 for ; Wed, 26 Mar 2003 12:53:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIENE18208 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 13:14:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIELO18198; Wed, 26 Mar 2003 13:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIDZO18169 for ; Wed, 26 Mar 2003 13:13:35 -0500 Received: from mail.oefeg.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05298 for ; Wed, 26 Mar 2003 12:52:11 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Mar 2003 18:58:26 +0100 Message-ID: <06CF906FE3998C4E944213062009F1620DF0A6@oefeg-s02.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: NAPTRs for invalid Numbers Thread-Index: AcLzu0yD3kmqQUnBRy6tY0UbAnATqwABUHMc From: "Stastny Richard" To: "Michael Mealling" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2QIDZO18170 Subject: [Enum] AW: NAPTRs for invalid Numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi -MM When Jon and I were talking about this before last week I suggested at one point a new enumservice called 'notavalidnumber' which could designate non-valid but existing nodes so that clients would have a better ability to detect real errors. The reason we rejected it was that it would bring up all sorts of issues associated with what those intermediate nodes meant, how else could you use them, etc. And that would cause this document to never get published. So my suggestion is to make a simple statement of it being out of scope with a statement similar to what I say above. We publish this document and then those that care can go off and figure out what records at intermediate nodes means more concretely.... I'm just not comfortable with holding this document up while we investigate what this approach might mean, both from a protocol stand point and from a regulatory/admin standpoint.... I fully agree that our first priority is to get the document out. The issue with the -notavalidnumber- should not be handled now in the document, if ever. I yust wanted to make clear that there are some issues, but this may be more suited in an informational draft for later after some experiences in the trial. I just wanted your comments or ideas. regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:57:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05458 for ; Wed, 26 Mar 2003 12:57:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QII4p18395 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 13:18:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QII3O18390; Wed, 26 Mar 2003 13:18:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIHwO18372 for ; Wed, 26 Mar 2003 13:17:58 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05410 for ; Wed, 26 Mar 2003 12:56:33 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2QHwYk08654; Wed, 26 Mar 2003 09:58:34 -0800 Message-Id: <5.2.0.9.2.20030326125507.02643140@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 12:57:09 -0500 To: Michael Mealling , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) In-Reply-To: <1048622935.32349.84.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 03:08 PM 3/25/2003 -0500, Michael Mealling wrote: >I wanted to get this out earlier but my laptop died the afternoon after >the ENUM meeting. The major change is the addition of several threat >models taken from a DNSSEC security threats document. Its gotten a >little lengthy but I think much more useful: Your chairs have not heard any comments on this text .... do we believe than that silence is consent and that this text can now be incorporated in the document? > 6. Security Considerations > >6.1 DNS Security > > As ENUM uses DNS, which in its current form is an insecure protocol, > there is no mechanism for ensuring that the data one gets back is > authentic. As ENUM is deployed on the global Internet, it is expected > to be a popular target for various kind of attacks, and attacking the > underlying DNS infrastructure is one way of attacking the ENUM > service itself. > > There are multiple types of attacks that can happen against DNS that > ENUM implementations should be aware of. The following threats are > taken from Threat Analysis Of The Domain Name System [9]: > > Packet Interception Some of the simplest threats against DNS are > various forms of packet interception: monkey-in-the-middle > attacks, eavesdropping on requests combined with spoofed responses > that beat the real response back to the resolver, and so forth. > In any of these scenarios, the attacker can simply tell either > party (usually the resolver) whatever it wants that party to > believe. While packet interception attacks are far from unique to > DNS, DNS's usual behavior of sending an entire query or response > in a single unsigned, unencrypted UDP packet makes these attacks > particularly easy for any bad guy with the ability to intercept > packets on a shared or transit network. > > ID Guessing and Query Prediction Since the ID field in the DNS header > is only a 16-bit field and the server UDP port associated with DNS > is a well-known value, there are only 2**32 possible combinations > of ID and client UDP port for a given client and server. Thus it > is possible for a reasonable brut force attack to allow an > attacker to masquerade as a trusted server. In most respects, this > attack is similar to a packet interception attack except that it > does not require the attacker to be on a transit or shared > network. > > Name-based Attacks Name-based attacks use the actual DNS caching > behavior as a tool to insert bad data into a victim's cache, thus > potentially subverting subsequent decisions based on DNS names. > Most examples occur with CNAME, NS and DNAME RRS as they redirect > a victim's query to another location. The common thread in all of > these attacks is that response messages allow the attacker to > introduce arbitrary DNS names of the attacker's choosing and > provide further information that the attacker claims is associated > with those names; unless the victim has better knowledge of the > data associated with those names, the victim is going to have a > hard time defending against this class of attacks. > > Betrayal By A Trusted Server Another variation on the packet > interception attack is the trusted server that turns out not to be > so trustworthy, whether by accident or by intent. Many client > machines are only configured with stub resolvers, and use trusted > servers to perform all of their DNS queries on their behalf. In > many cases the trusted server is furnished by the user's ISP and > advertised to the client via DHCP or PPP options. Besides > accidental betrayal of this trust relationship (via server bugs, > successful server break-ins, etc), the server itself may be > configured to give back answers that are not what the user would > expect (whether in an honest attempt to help the user or to > further some other goal such as furthering a business partnership > between the ISP and some third party). > > Denial of Service As with any network service (or, indeed, almost any > service of any kind in any domain of discourse), DNS is vulnerable > to denial of service attacks. DNS servers are also at risk of > being used as denial of service amplifiers, since DNS response > packets tend to be significantly longer than DNS query packets. > > Authenticated Denial of Domain Names The existence of RR types whose > absence causes an action other than immediate failure (such as > missing MX and SRV RRs, which fail over to A RRs) constitutes a > real threat. In the specific case of ENUM, even the immediate > failure of a missing RR can be considered a problem as a method > for changing call routing policy. > > Because of these threats, a deployed ENUM service SHOULD include > mechanisms which ameliorate these threats. Most of these threats can > be solved by verifying the authenticity of the data via mechanisms > such as DNSSEC (Section 6.1) once it is deployed. Others, such and > Denial Of Service attacks, cannot be solved by data authentication. > It is important to remember that these threats include not only the > NAPTR lookups themselves, but also the various records needed for the > services to be useful (for example NS, MX, SRV and A records). > > Even if DNSSEC is deployed, a service which uses ENUM for address > translation should not blindly trust that the peer is the intended > party as all kind of attacks against DNS can not be protected against > with DNSSEC. A service should always authenticate the peers as part > of the setup process for the service itself and never blindly trust > any kind of addressing mechanism. > > Finally, as an ENUM services will be implementing some type of > security mechanism, software which implements ENUM MUST be prepared > to recieve DNSSEC and other standardized DNS security responses, > including large responses, EDNS0 signaling, unknown RRs, etc. > >6.2 Caching Security > > The caching in DNS can make the propagation time for a change take > the same amount of time as the time to live for the NAPTR records in > the zone that is changed. The use of this in an environment where > IP-addresses are for hire (for example, when using DHCP [8]) must > therefore be done very carefully. > >6.3 Call Routing Security > > There are a number of countries (and other numbering environments) in > which there are multiple providers of call routing and number/name- > translation services. In these areas, any system that permits users, > or putative agents for users, to change routing or supplier > information may provide incentives for changes that are actually > unauthorized (and, in some cases, for denial of legitimate change > requests). Such environments should be designed with adequate > mechanisms for identification and authentication of those requesting > changes and for authorization of those changes. > >6.4 URI Resolution Security > > A large amount of Security Issues have to do with the resolution > process itself, and use of the URIs produced by the DDDS mechanism. > Those have to be specified in the registration of the ENUM > Enumservice used, as specified in Section 3.1.3. > > > > > > > > > > > > > > > > > > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 12:58:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05520 for ; Wed, 26 Mar 2003 12:58:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIJBf18558 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 13:19:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIJBO18553; Wed, 26 Mar 2003 13:19:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIISO18443 for ; Wed, 26 Mar 2003 13:18:28 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05449 for ; Wed, 26 Mar 2003 12:57:03 -0500 (EST) Received: from rshockeybox.neustar.biz (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h2QHwpe13084; Wed, 26 Mar 2003 17:58:51 GMT Message-Id: <5.2.0.9.2.20030326125721.0264c0a0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 12:59:22 -0500 To: Michael Mealling , Stastny Richard From: Richard Shockey Subject: Re: [Enum] Re: NAPTRs for invalid Numbers Cc: enum@ietf.org In-Reply-To: <1048698605.32349.155.camel@blackdell.neonym.net> References: <06CF906FE3998C4E944213062009F1620DF0A3@oefeg-s02.oefeg.loc> <06CF906FE3998C4E944213062009F1620DF0A3@oefeg-s02.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , > > > One possibility is e.g. to provide wild card NAPTRs in invalid number > ranges pointing > > to e.g. an annoncement. This NAPTRs would never be inserted by ENUM > Subscribers, > > but by the Tier 1 Registry. > > > > Therefore I have some problems with your above statement. > > > > Any comments? > >When Jon and I were talking about this before last week I suggested at >one point a new enumservice called 'notavalidnumber' which could >designate non-valid but existing nodes so that clients would have a >better ability to detect real errors. The reason we rejected it was that >it would bring up all sorts of issues associated with what those >intermediate nodes meant, how else could you use them, etc. And that >would cause this document to never get published. > >So my suggestion is to make a simple statement of it being out of scope >with a statement similar to what I say above. We publish this document >and then those that care can go off and figure out what records at >intermediate nodes means more concretely.... I certainly support this conclusion .... >I'm just not comfortable with holding this document up while we >investigate what this approach might mean, both from a protocol stand >point and from a regulatory/admin standpoint.... Precisely ... this document needs to be completed and into last call as soon as practical. >-MM > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 13:40:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06735 for ; Wed, 26 Mar 2003 13:40:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJ1RN21894 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 14:01:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ1LO21868; Wed, 26 Mar 2003 14:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9DaO10053 for ; Wed, 26 Mar 2003 04:13:36 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18269 for ; Wed, 26 Mar 2003 03:52:23 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2Q8s8k17010; Wed, 26 Mar 2003 00:54:08 -0800 Date: Wed, 26 Mar 2003 00:54:11 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <18737620575.20030326005411@brandenburg.com> To: Michael Mealling CC: "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "'Stastny Richard'" , , Rudi on the road Subject: Re: [Enum] partial numbers proposed text changes In-Reply-To: <1048621019.32425.65.camel@blackdell.neonym.net> References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> <1048621019.32425.65.camel@blackdell.neonym.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Tuesday, March 25, 2003, 11:36:59 AM, you wrote: MM> But as others have said before, we have to write these documents so that MM> they're at least somewhat prescient. If we can see where some may assume MM> that something can be done and we realize it can be a problem, it is our MM> responsibility to make sure it doesn't happen. My understanding, at the meeting, was that partial numbers were entirely outside the scope of this working group. if you want to anticipate that someone might do partial numbers, then just add a sentence that says that they are outside the scope of the specification. "outside" means outside. as in, nothing to do with. have have thereby acknowledged the possible future action, but done so in a way that leaves no one confused. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 13:46:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06902 for ; Wed, 26 Mar 2003 13:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJ78I22366 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 14:07:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ76O22328; Wed, 26 Mar 2003 14:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ6cO22169 for ; Wed, 26 Mar 2003 14:06:38 -0500 Received: from bartok.sidn.nl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06860 for ; Wed, 26 Mar 2003 13:45:11 -0500 (EST) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2QIlUT1077815; Wed, 26 Mar 2003 19:47:31 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303261847.h2QIlUT1077815@bartok.sidn.nl> To: Richard Shockey cc: Michael Mealling , enum@ietf.org Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) In-reply-to: Your message of Wed, 26 Mar 2003 12:57:09 -0500. <5.2.0.9.2.20030326125507.02643140@popd.ix.netcom.com> Date: Wed, 26 Mar 2003 19:47:30 +0100 From: Jaap Akkerhuis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Your chairs have not heard any comments on this text .... do we believe than that silence is consent and that this text can now be incorporated in the document? I always thought that the security section list the threats added to the current system. A lot of the things mentioned here actually lists well known threats not specific to enum (DNS threats). For that part it is not necessary to list them but just point to the existing documents, such as the DNS threats drafts (to be published soon) and other relevant RFC's. jaap _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 14:16:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08100 for ; Wed, 26 Mar 2003 14:16:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJbTP25173 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 14:37:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJbQO25128; Wed, 26 Mar 2003 14:37:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJZYO24534 for ; Wed, 26 Mar 2003 14:35:34 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07985 for ; Wed, 26 Mar 2003 14:14:07 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id F03B0137F09; Wed, 26 Mar 2003 11:16:27 -0800 (PST) To: Jaap Akkerhuis Cc: Richard Shockey , Michael Mealling , enum@ietf.org Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) In-Reply-To: Message from Jaap Akkerhuis of "Wed, 26 Mar 2003 19:47:30 +0100." <200303261847.h2QIlUT1077815@bartok.sidn.nl> Date: Wed, 26 Mar 2003 11:16:27 -0800 Message-ID: <43698.1048706187@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , >>>>> "Jaap" == Jaap Akkerhuis writes: Jaap> I always thought that the security section list the threats Jaap> added to the current system. A lot of the things mentioned Jaap> here actually lists well known threats not specific to enum Jaap> (DNS threats). For that part it is not necessary to list Jaap> them but just point to the existing documents, such as the Jaap> DNS threats drafts (to be published soon) and other relevant Jaap> RFC's. Yes, this would be a better approach. The chances are those DNS threats documents would get updated and revised more quickly than 2916bis. And they're independent of the ENUM WG too. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 14:34:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08919 for ; Wed, 26 Mar 2003 14:34:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJt9U26438 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 14:55:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJt9O26433; Wed, 26 Mar 2003 14:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJs7O26374 for ; Wed, 26 Mar 2003 14:54:07 -0500 Received: from neonym.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08883 for ; Wed, 26 Mar 2003 14:32:40 -0500 (EST) Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Wed, 26 Mar 2003 01:10:03 -0500 Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) From: Michael Mealling To: Jim Reid Cc: Jaap Akkerhuis , Richard Shockey , enum@ietf.org In-Reply-To: <43698.1048706187@shell.nominum.com> References: <43698.1048706187@shell.nominum.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1048707216.32350.168.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 14:33:36 -0500 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-03-26 at 14:16, Jim Reid wrote: > >>>>> "Jaap" == Jaap Akkerhuis writes: > > Jaap> I always thought that the security section list the threats > Jaap> added to the current system. A lot of the things mentioned > Jaap> here actually lists well known threats not specific to enum > Jaap> (DNS threats). For that part it is not necessary to list > Jaap> them but just point to the existing documents, such as the > Jaap> DNS threats drafts (to be published soon) and other relevant > Jaap> RFC's. > > Yes, this would be a better approach. The chances are those DNS > threats documents would get updated and revised more quickly than > 2916bis. And they're independent of the ENUM WG too. Oh lordy... ;-) Ok, my recollection of the consensus was that we couldn't make DNSSEC mandatory. So we should explain the threat risks that DNS entails in enough detail so that its obvious that, while DNSSEC in its current form isn't fully baked, to neglect using it would be extremely dangerous. Could someone propose some text for me to take the current form and rework it to balance that consensus and the above statements about tracking the dns-threats document? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 18:45:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22956 for ; Wed, 26 Mar 2003 18:45:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R06Rq14841 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 19:06:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R05rO14831; Wed, 26 Mar 2003 19:05:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R04dO14775 for ; Wed, 26 Mar 2003 19:04:39 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22766 for ; Wed, 26 Mar 2003 18:43:07 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2QNj5701304; Wed, 26 Mar 2003 15:45:06 -0800 Message-Id: <5.2.0.9.2.20030326145008.025197e8@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 14:56:55 -0500 To: Michael Mealling , Jim Reid From: Richard Shockey Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) Cc: Jaap Akkerhuis , enum@ietf.org In-Reply-To: <1048707216.32350.168.camel@blackdell.neonym.net> References: <43698.1048706187@shell.nominum.com> <43698.1048706187@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , At 02:33 PM 3/26/2003 -0500, Michael Mealling wrote: >On Wed, 2003-03-26 at 14:16, Jim Reid wrote: > > >>>>> "Jaap" == Jaap Akkerhuis writes: > > > > Jaap> I always thought that the security section list the threats > > Jaap> added to the current system. A lot of the things mentioned > > Jaap> here actually lists well known threats not specific to enum > > Jaap> (DNS threats). For that part it is not necessary to list > > Jaap> them but just point to the existing documents, such as the > > Jaap> DNS threats drafts (to be published soon) and other relevant > > Jaap> RFC's. > > > > Yes, this would be a better approach. The chances are those DNS > > threats documents would get updated and revised more quickly than > > 2916bis. And they're independent of the ENUM WG too. > >Oh lordy... ;-) Really ... I really dont see the problem with listing known threats here. IMHO this is a bit of hair splitting. If anyone has text you want to see included .then submit it NOW ...because we need to move on get 05 ready and start a last call process. >Ok, my recollection of the consensus was that we couldn't make DNSSEC >mandatory. So we should explain the threat risks that DNS entails in >enough detail so that its obvious that, while DNSSEC in its current form >isn't fully baked, to neglect using it would be extremely dangerous. >Could someone propose some text for me to take the current form and >rework it to balance that consensus and the above statements about >tracking the dns-threats document? > >-MM > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Mar 26 19:04:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23779 for ; Wed, 26 Mar 2003 19:04:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R0PAT16272 for enum-archive@odin.ietf.org; Wed, 26 Mar 2003 19:25:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0P8O16267; Wed, 26 Mar 2003 19:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R0ONO16242 for ; Wed, 26 Mar 2003 19:24:23 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23756 for ; Wed, 26 Mar 2003 19:02:51 -0500 (EST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h2R04T702246; Wed, 26 Mar 2003 16:04:29 -0800 Date: Wed, 26 Mar 2003 16:04:33 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12212917314.20030326160433@brandenburg.com> To: Michael Mealling CC: Dave Crocker , "Conroy, Lawrence (SMTP)" , "Peterson, Jon" , "'Stastny Richard'" , , Rudi on the road Subject: Re: [Enum] partial numbers proposed text changes In-Reply-To: <1048697857.32425.146.camel@blackdell.neonym.net> References: <0449D80A0E9B614A83FA9031B07E8D3B2578F6@stntexch2.va.neustar.com> <1048621019.32425.65.camel@blackdell.neonym.net> <565469920.20030326083821@dcrocker.net> <1048697857.32425.146.camel@blackdell.neonym.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael, Wednesday, March 26, 2003, 8:57:37 AM, you wrote: MM> With the exception that you have now created a case where a client MM> cannot know when it is 'in scope' and thus within its rights to expect MM> compliant behavior and when it is 'out of scope'. I'm not attempting to MM> make any statements about 'partial numbers' themselves other than to MM> define them so they can be declared out of scope syntactically. Right MM> now there is no way to tell what the 'scope' actually is from a client MM> implementation... not sure how to process your note. scope is about specifications, not implementations. client software does not determine whether something is in scope. the DEVELOPER of client software has to know. so, my suggestion reduces to simply having the specification state: some of you out there might be wondering about the use of partial numbers. now that we have mentioned that fact, you know that we know about it. however, partial numbers are outside the scope of this specification. therefore this specification does not discuss them. it does not prohibit them. it does not enable them. it has nothing to do with them. in other words, if you are interested in doing partial numbers, look for some other specification to read, because you won't find anything about them, here. (and if the above started sounding like a Monty Python routine, i must say that it was not intentional.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Thu Mar 27 03:45:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20172 for ; Thu, 27 Mar 2003 03:45:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R96fg30359 for enum-archive@odin.ietf.org; Thu, 27 Mar 2003 04:06:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R96YO30344; Thu, 27 Mar 2003 04:06:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R95wO30269 for ; Thu, 27 Mar 2003 04:05:58 -0500 Received: from whale.cnnic.net.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20157 for ; Thu, 27 Mar 2003 03:44:14 -0500 (EST) Received: from enum1 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id HCEGDJ00.RNC for ; Thu, 27 Mar 2003 16:46:31 +0800 Message-ID: <000701c2f43d$5a415a50$6207e29f@enum1> From: "bill" To: Date: Thu, 27 Mar 2003 16:46:26 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2R95wO30270 Subject: [Enum] any progress Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello,folks: Is there any progress in this SF meeting? Best -bill _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Mar 28 06:10:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23958 for ; Fri, 28 Mar 2003 06:10:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SBWQd27247 for enum-archive@odin.ietf.org; Fri, 28 Mar 2003 06:32:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SBUEO27182; Fri, 28 Mar 2003 06:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SBS5O27093 for ; Fri, 28 Mar 2003 06:28:05 -0500 Received: from internal.mail.demon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23869 for ; Fri, 28 Mar 2003 06:04:49 -0500 (EST) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id h2SB86304691; Fri, 28 Mar 2003 11:08:09 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 18yrgn-000Ir4-00; Fri, 28 Mar 2003 11:06:25 +0000 Date: Fri, 28 Mar 2003 11:06:25 +0000 From: "Clive D.W. Feather" To: Michael Mealling Cc: enum@ietf.org Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) Message-ID: <20030328110624.GO82772@finch-staff-1.thus.net> References: <1048622935.32349.84.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1048622935.32349.84.camel@blackdell.neonym.net> User-Agent: Mutt/1.5.3i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Enum Discussion List List-Post: List-Help: List-Subscribe: , Michael Mealling said: > Packet Interception Some of the simplest threats against DNS are > various forms of packet interception: monkey-in-the-middle > attacks, *man*-in-the-middle, surely? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum