From mailnull@www1.ietf.org Thu Apr 3 11:08: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 LAA27360 for ; Thu, 3 Apr 2003 11:08:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33GAO129704 for enum-archive@odin.ietf.org; Thu, 3 Apr 2003 11:10: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 h33GA5K29666; Thu, 3 Apr 2003 11:10: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 h33G8mK29537 for ; Thu, 3 Apr 2003 11:08:48 -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 LAA27217 for ; Thu, 3 Apr 2003 11:05:56 -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 h33G88819181; Thu, 3 Apr 2003 08:08:08 -0800 Date: Thu, 3 Apr 2003 08:05:40 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12875218979.20030403080540@brandenburg.com> To: Richard Shockey CC: enum@ietf.org Subject: Re: [Enum] New Security Considerations section (including DNSSEC statements) In-Reply-To: <5.2.0.9.2.20030326145008.025197e8@popd.ix.netcom.com> References: <43698.1048706187@shell.nominum.com> <43698.1048706187@shell.nominum.com> <5.2.0.9.2.20030326145008.025197e8@popd.ix.netcom.com> 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 Richard, >> > Jaap> I always thought that the security section list the threats RS> Really ... I really dont see the problem with listing known threats RS> here. IMHO this is a bit of hair splitting. IETF specifications often contain key bits of pedogagy, in addition to normative specification, when the working group feels that readers will benefit from the information. This, of course, creates some challenges to make sure the document does not get fragmented, distracted, etc. Based on the IETF's history deploying security-based solutions, it is an area where more pedagogy is probably helpful. It might help to have the normative part(s) of that section distinguished from the pedagogic parts. Other than that, I think the current text is nicely done. 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 Apr 9 07:21: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 HAA22000 for ; Wed, 9 Apr 2003 07:21:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39BQtv03358 for enum-archive@odin.ietf.org; Wed, 9 Apr 2003 07:26:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39BQT803345; Wed, 9 Apr 2003 07:26:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39BOR803198 for ; Wed, 9 Apr 2003 07:24:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21802; Wed, 9 Apr 2003 07:18:46 -0400 (EDT) Message-Id: <200304091118.HAA21802@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: Wed, 09 Apr 2003 07:18:46 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-05.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-05.txt Pages : 24 Date : 2003-4-8 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 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-rfc2916bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-8142002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8142002.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Apr 9 12:48: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 MAA05850 for ; Wed, 9 Apr 2003 12:48:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39EvQe20286 for enum-archive@odin.ietf.org; Wed, 9 Apr 2003 10:57:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Euq820263; Wed, 9 Apr 2003 10:56:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Eps820018 for ; Wed, 9 Apr 2003 10:51:54 -0400 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 KAA01361 for ; Wed, 9 Apr 2003 10:46:08 -0400 (EDT) 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 h39EmH128198; Wed, 9 Apr 2003 07:48:17 -0700 Message-Id: <5.2.0.9.2.20030409092112.01c93958@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 10:49:27 -0400 To: enum@ietf.org From: Richard Shockey Cc: jon.peterson@neustar.biz, mankin@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] LAST CALL for draft-ietf-enum-rfc2916bis-05.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 think it is fair to say we have thoroughly discussed this document and reached rough consensus on the contentious issues as reflected in this version so as the non author chair I'm going to declare a last call on this for a 2 week period. So .... This is a formal request for final comments within the IETF ENUM WG working group for one document. The document below is being proposed for forwarding on to the IESG for consideration as Standards Track RFC. This is a working group product, which has been thoroughly discussed since 2001. This document has undergone extensive review and revisions during the past few months and I believe that we now have working group consensus on its adequacy based on discussion on this list and at several working group meetings. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. The 2 week Last Call will begin immediately and will end on April 23 at 12PM EST >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-05.txt > Pages : 24 > Date : 2003-4-8 > >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 3401. It is very important to >note that it is impossible to read and understand this document >without reading the documents discussed in RFC 3401. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-05.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 Wed Apr 9 15:53: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 PAA12051 for ; Wed, 9 Apr 2003 15:53:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39JwqG22996 for enum-archive@odin.ietf.org; Wed, 9 Apr 2003 15:58:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39JwN822963; Wed, 9 Apr 2003 15:58:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39J54819151 for ; Wed, 9 Apr 2003 15:05:04 -0400 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 OAA09653 for ; Wed, 9 Apr 2003 14:59:14 -0400 (EDT) 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 h39J1T108285 for ; Wed, 9 Apr 2003 12:01:29 -0700 Message-Id: <5.2.0.9.2.20030409115937.027a59f0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Apr 2003 15:02:38 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Raw Preliminary Meeting notes from IETF ENUM WG in San Francisco 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: , Many thanks to Brian for taking these notes. I apologize for not having posted these sooner. I've added text based on my memory if there are any clarifications here let me know. I'll clean up the text in the meantime ... Remind me about the right initials behind the right folks ENUM Meeting Minutes - Brian Rosen Scribe WEDNESDAY, March 19, 2003 0900-1130 Morning Sessions TSV enum Telephone Number Mapping WG AGENDA BASH JP Jon Peterson - vovi clarifications helped, do we need less time..can this be devoted to 2916 RS Rich Shockey - we'll take it's much time as we need to finish the review of 2916bis this is the most important task for this meeting. Thanks to Scott Bradner for the creation of the ENUM WG and his support for many many years. ( Applause ) ITEM 1 . 2916bis 04 review... a) Some feel DNSSEC with opt-in makes it possible to deploy PF- Patrik Faltstrom Don't see any connection. WG should be neutral KM - helpful SB Scott Bradner - Well discussed in other venues, no need to discuss ?? - DNSSEC without opt-in still useful hum for if it should remain neutral - WIDE AGREEMENT b) Some requests to make latest proposed DNSSEC language stronger. Want to be MUST, but DNSSEC not ready yet PF Patrik Faltstrom Patrik Faltstrom- DNSSEC at SHOULD needs some language MM Mike Mealling - Text talks about ongoing work should be deleted SB Scott Bradner - SHOULD is strong guidance JP Jon Peterson - IESG wants mandatory-to-implement language SB - DNSSEC is not baked, so can't require it yet. Could announce intentions HA - Can say it will be a MUST some day JH - Talking futures doesn't make much sense. May want under some circumstances to do other things RS - Rich Shockey What do we do? DC Dave Crocker - Doesn't like future intentions text. State why it wasn't a MUST, and that's good enough. State requirements for MUST. JP - Jon Peterson Might consider add more text in responsibilities of service designers part of security considerations SB Scott Bradner - DC's idea good, put short synopsis of DNSSEC in doc, say "when it's available, SHOULD becomes MUST" No significant objections to SHOULD. Will add some text to security section on consequences of not implementing it. Text to list within a few hours c) Issues surrounding partial number resolution Client given number outside dialing plan, doesn't know it's not a full E.164, but you don't know it. May get into middle of ENUM, not edge. Do we need a way to figure out that it's busted JP - Jon Peterson Little error handling is available. Need to give advice. Okay if just simple statement that it could happen LC - Intentional partial lookup may be okay. Don't restrict anything JP - Jon Peterson Intentional query for partial is a bad idea because we don't have any meaning for it, so don't allow. RS - Intential Partial Resolution is out of scope for this doc LC - Don't know if there is a good reason to do it, but there might be. Okay for a heads-up on no definition of what can be found. KM - This is an application issue, don't need to see any text DC - Out of scope is right, don't even mention it JP - Jon Peterson Still wants to warn about the problem DC - Dave Crocker Needs OPS discussion because will cause massive numbers of failed queries, much more than current operation D? - Worried about numbers that are subsets of other numbers JP - Jon Peterson Tel URI worried about that, we don't think it's possible KD - Sub-addresses are not E.164. Service numbers are not E.164s Doesn't believe it can happen ?? - It happens in common practice, doesn't matter if they aren't E.164s ?? - "Pilot" numbers exist ?? - Public space means E.164, problem doesn't exist JP - Jon Peterson If you have any subset E.164s, send them to list hum on Text in draft is acceptable - NO ROUGH CONSENSUS Option 1 - current text Option 2 - change text to say that things could be at partial nodes, but not E2Us, and thats's all we spec option 3 - declare partial resolution is out of scope Show of hands - little sentiment for option 1. NO ROUGH CONSENSUS between option 2 and 3. LC - I have a pair of subset (Austria) ?? - Might be able to come up with text that works Possible to do this before end of meeting, but move on at the moment ITEM 2. draft-toyoda-faxservice-enum-00.txt Fax over email. Better if you can use telephone number as an address. So, map telephone numbers to an email address, using ENUM. Defines the NAPTR for this purpose. ifax service and mailto URI. RS Rich Shockey Document will move forward in the FAX WG ITEM 3. draft-brandner-enumservice-msg-00.txt RBrandner draft-brandner-enumservice-vovi-00.txt draft-brandner-enumservice-webft-00.txt webft - obvious, but since it's a public database, don't put usernames or paswords in there! msg - will incorporate MMS comments. Solicit other comments hum for accepting these two into enum - ROUGH CONSENSUS TO MAKE THESE DOCUMENTS WG ITEMS Allison Mankin- Do we have the right people looking at the MMS stuff? Lawrence Conrad - Yes, the one response we got was from an MMS person vovi - lots of argument on list. Split into two drafts. Non contentious and contentious. Basically the sip:voice and sip:video are the contentious parts. H.323 stuff is still there. Some issues regarding H.323 version capability and what is deployed. Current deployed H.323 could use the current proposed mechanisms. Orit Levin - Still need discussions to reach consensus. SIP and current H.323 work in similar ways. LC - V4 H.323 would have same issues as sip, current stuff could use vovi OL - vovi for V2 H.323 is usefull. FA - H.323 versions won't matter much, vovi is usefull CJ - version issues are more nuanced, but it doesn't matter Hum - accept vovi without sip stuff as a WG item - NO OPPOSITION, BUT LITTLE SUPPORT. JP - Jon Peterson Not a lot of support, let's not make it a WG item BR - Brian Rosen can be an individual effort LC - Larry Conroy Is there something we should fix? Many people are not here, can still be WG consensus to progress the vovi draft sans references to SIP Hum for WG item vs individual draft - NO CONSENSUS PF - Patrik Faltstrom If we are discussing it, then wants it listed AM - Allison Mankin acceptable to continue to discuss without making it a WG item PF Patrik Faltstrom - Service can be created without making it a WG item ?? - Don't understand what the problem is JP Jon Peterson - It happens, sometimes there is no enthusiasm to work on something Group doesn't have to have a reason LCLayrry Conroy - If there are technical objections, please put them on the list What is the process if there is no WGLC? AM Allison Mankin- AD does an extended Last Call. Submit to AD. WG needs to do the review. ITEM 4. LC - Experimental should be allowed to be an enum service (ie allowed to be IANA registered) X- is not registered. PF Patrik Faltstrom- Could make a simple mod to allow this JP - Jon Peterson Want to exclude INFO PF Patrik Faltstrom- Don't want to have proprietary registrations Restricting to standards track is too strong Will make some adjustments ITEM 5. Back to partial resolutions. Propose to add applicability statement that says: ENUM is for E.164 only MUST only query for what it thinks is a valid E.164. E2U MUST NOT be used for non E.164 Some real time discussion over "what it thinks". JK - Be careful about how explicit rules are BR Brian Rosen- real time editing often doesn't work, ask for general consensus and debate wording on list RS - Rich Shockey - Would like to finish this JP - Jon Peterson even E.164 could change; specs move. PF Patrik Faltstrom- Can't do wordsmithing in a meeting JH - Change to something simpler (cc+some number of digits) RS Rich Shockey- SEND TEXT TO THE LIST ! ITEM 6. draft-peterson-enum-pres-00.txt Jon Peterson defines e2U+pres exact protocol is not specified in enum - negotiated per IMPP (cpp) presence for telephone requires more spec work RG - where would extensions for presence be done? SPIRITS? JP - Apps area or transport area maybe JH - What is relationship to e2u+sip JP - other presence protocols, e.g. mobile telephones,... JR Jonathan Rosenberg - draft assumes presence of phone. Don't have to do that, E.164 to pres uri, doesn't matter what kind of phone JP - True but E.164 represents something in the PSTN Generalizable beyond presence for a phone JH - Looks like rerun of vovi. JP - Accommodates other presence protocols JR - pres URI won't get you a sip uri! JP - yeah, you will be able to get to a sip service RS - Rich Shockey Confused JP - pres: uri dereferences to a service, could be sip, jabber,... LC Layry Conroy - Point is that ENUM gets you pres: and then you are out of DDDS hum should this be a WG item - CONSENUS TO MAKE IT A WG ITEM Meeting closes. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Thu Apr 10 12:10: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 MAA25290 for ; Thu, 10 Apr 2003 12:10:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AGGdq23498 for enum-archive@odin.ietf.org; Thu, 10 Apr 2003 12:16:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGGW823489; Thu, 10 Apr 2003 12:16:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGEv823393 for ; Thu, 10 Apr 2003 12:14:57 -0400 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 MAA25249 for ; Thu, 10 Apr 2003 12:08:39 -0400 (EDT) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA10728; Thu, 10 Apr 2003 18:11:10 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA09430; Thu, 10 Apr 2003 18:11:12 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Apr 2003 18:10:52 +0200 Message-ID: <79D5F4B2D775204D9C7852EE41C5477391CF63@mchh2a1e.mchh.siemens.de> From: Brandner Rudolf To: "'Richard Shockey'" Cc: enum@ietf.org Subject: RE: [Enum] Raw Preliminary Meeting notes from IETF ENUM WG in San Francisco Date: Thu, 10 Apr 2003 18:10:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , One minor nit: Regarding the vovi draft in ITEM 3. it is written that sip:voice and sip:video is contentious, which is true. However, the vovi draft has been about voice:sip and video:sip, which are contentious, too. Besides that, I would like to thank Brian Rosen for having taken the minutes. Job very well done. Rudi > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Mittwoch, 9. April 2003 21:03 > To: enum@ietf.org > Subject: [Enum] Raw Preliminary Meeting notes from IETF ENUM WG in San > Francisco > > > > Many thanks to Brian for taking these notes. I apologize for > not having > posted these sooner. I've added text based on my memory if > there are any > clarifications here let me know. I'll clean up the text in > the meantime ... > > Remind me about the right initials behind the right folks > > ENUM Meeting Minutes - Brian Rosen Scribe > > WEDNESDAY, March 19, 2003 > 0900-1130 Morning Sessions > TSV enum Telephone Number Mapping WG > > > AGENDA BASH > > JP Jon Peterson - vovi clarifications helped, do we need > less time..can > this be devoted to 2916 > RS Rich Shockey - we'll take it's much time as we need to > finish the > review of 2916bis this is the most important task for this meeting. > > Thanks to Scott Bradner for the creation of the ENUM WG and > his support for > many many years. ( Applause ) > > ITEM 1 . 2916bis 04 review... > > a) Some feel DNSSEC with opt-in makes it possible to deploy > > PF- Patrik Faltstrom Don't see any connection. WG should be neutral > KM - helpful > SB Scott Bradner - Well discussed in other venues, no need to > discuss ?? - > DNSSEC without opt-in still useful > > hum for if it should remain neutral - WIDE AGREEMENT > > b) Some requests to make latest proposed DNSSEC language > stronger. Want to > be MUST, but DNSSEC not ready yet > > PF Patrik Faltstrom Patrik Faltstrom- DNSSEC at SHOULD needs > some language > MM Mike Mealling - Text talks about ongoing work should be deleted > SB Scott Bradner - SHOULD is strong guidance > JP Jon Peterson - IESG wants mandatory-to-implement language > SB - DNSSEC is not baked, so can't require it yet. Could > announce intentions > HA - Can say it will be a MUST some day > JH - Talking futures doesn't make much sense. May want under some > circumstances to do other things > RS - Rich Shockey What do we do? > DC Dave Crocker - Doesn't like future intentions text. State > why it wasn't > a MUST, and that's good enough. State requirements for MUST. > JP - Jon Peterson Might consider add more text in > responsibilities of service > designers part of security considerations > SB Scott Bradner - DC's idea good, put short synopsis of DNSSEC in > doc, say "when it's available, SHOULD becomes MUST" > > No significant objections to SHOULD. > Will add some text to security section on consequences of not > implementing it. > Text to list within a few hours > > c) Issues surrounding partial number resolution > > Client given number outside dialing plan, doesn't know it's not a full > E.164, but you don't know it. May get into middle of ENUM, not edge. > Do we need a way to figure out that it's busted > > JP - Jon Peterson Little error handling is available. Need to give > advice. Okay if just simple statement that it could happen > LC - Intentional partial lookup may be okay. Don't restrict anything > JP - Jon Peterson Intentional query for partial is a bad idea > because we > don't have any meaning for it, so don't allow. > RS - Intential Partial Resolution is out of scope for this doc > LC - Don't know if there is a good reason to do it, but there might > be. Okay for a heads-up on no definition of what can be found. > KM - This is an application issue, don't need to see any text > DC - Out of scope is right, don't even mention it > JP - Jon Peterson Still wants to warn about the problem > DC - Dave Crocker Needs OPS discussion because will cause > massive numbers > of failed queries, much more than current operation > D? - Worried about numbers that are subsets of other numbers > JP - Jon Peterson Tel URI worried about that, we don't think > it's possible > KD - Sub-addresses are not E.164. Service numbers are not > E.164s Doesn't > believe it can happen > ?? - It happens in common practice, doesn't matter if they > aren't E.164s > ?? - "Pilot" numbers exist > ?? - Public space means E.164, problem doesn't exist > JP - Jon Peterson If you have any subset E.164s, send them to list > > hum on Text in draft is acceptable - NO ROUGH CONSENSUS > > Option 1 - current text > Option 2 - change text to say that things could be at partial > nodes, but > not E2Us, and thats's all we spec > option 3 - declare partial resolution is out of scope > > Show of hands - little sentiment for option 1. NO ROUGH CONSENSUS > between option 2 and 3. > > LC - I have a pair of subset (Austria) > > ?? - Might be able to come up with text that works > > Possible to do this before end of meeting, but move on at the moment > > ITEM 2. draft-toyoda-faxservice-enum-00.txt > > Fax over email. Better if you can use telephone number as an address. > So, map telephone numbers to an email address, using ENUM. > Defines the NAPTR for this purpose. ifax service and mailto URI. > > RS Rich Shockey Document will move forward in the FAX WG > > ITEM 3. draft-brandner-enumservice-msg-00.txt RBrandner > draft-brandner-enumservice-vovi-00.txt > draft-brandner-enumservice-webft-00.txt > > webft - obvious, but since it's a public database, don't put > usernames or > paswords in there! > > msg - will incorporate MMS comments. Solicit other comments > > hum for accepting these two into enum - ROUGH CONSENSUS TO MAKE THESE > DOCUMENTS WG ITEMS > > Allison Mankin- Do we have the right people looking at the MMS stuff? > Lawrence Conrad - Yes, the one response we got was from an MMS person > > vovi - lots of argument on list. Split into two drafts. > > Non contentious and contentious. Basically the sip:voice and > sip:video are > the contentious parts. > > H.323 stuff is still there. Some issues regarding H.323 > version capability > and what is deployed. Current deployed H.323 could use the current > proposed mechanisms. > > Orit Levin - Still need discussions to reach consensus. SIP > and current > H.323 work in similar ways. > LC - V4 H.323 would have same issues as sip, current stuff > could use vovi > OL - vovi for V2 H.323 is usefull. > FA - H.323 versions won't matter much, vovi is usefull > CJ - version issues are more nuanced, but it doesn't matter > > Hum - accept vovi without sip stuff as a WG item - NO OPPOSITION, BUT > LITTLE SUPPORT. > > JP - Jon Peterson Not a lot of support, let's not make it a WG item > BR - Brian Rosen can be an individual effort > LC - Larry Conroy Is there something we should fix? Many > people are not > here, can still be > > WG consensus to progress the vovi draft sans references to SIP > Hum for WG item vs individual draft - NO CONSENSUS > > PF - Patrik Faltstrom If we are discussing it, then wants it listed > AM - Allison Mankin acceptable to continue to discuss without > making it a > WG item > PF Patrik Faltstrom - Service can be created without making > it a WG item > ?? - Don't understand what the problem is > JP Jon Peterson - It happens, sometimes there is no > enthusiasm to work on > something > Group doesn't have to have a reason > LCLayrry Conroy - If there are technical objections, please > put them on the > list > What is the process if there is no WGLC? > AM Allison Mankin- AD does an extended Last Call. Submit to > AD. WG needs > to do the review. > > ITEM 4. LC - Experimental should be allowed to be an enum service (ie > allowed to be IANA registered) X- is not registered. > > PF Patrik Faltstrom- Could make a simple mod to allow this > JP - Jon Peterson Want to exclude INFO > PF Patrik Faltstrom- Don't want to have proprietary registrations > Restricting to standards track is too strong > > Will make some adjustments > > ITEM 5. Back to partial resolutions. Propose to add applicability > statement that says: > ENUM is for E.164 only MUST only query for what it thinks is > a valid E.164. > E2U MUST NOT be used for non E.164 > > Some real time discussion over "what it thinks". > > JK - Be careful about how explicit rules are > BR Brian Rosen- real time editing often doesn't work, ask for general > consensus and debate wording on list > RS - Rich Shockey - Would like to finish this > JP - Jon Peterson even E.164 could change; specs move. > PF Patrik Faltstrom- Can't do wordsmithing in a meeting > JH - Change to something simpler (cc+some number of digits) > > RS Rich Shockey- SEND TEXT TO THE LIST ! > > ITEM 6. draft-peterson-enum-pres-00.txt > Jon Peterson defines e2U+pres exact protocol is not specified > in enum - > negotiated per IMPP (cpp) presence for telephone requires > more spec work > > RG - where would extensions for presence be done? SPIRITS? > JP - Apps area or transport area maybe > JH - What is relationship to e2u+sip > JP - other presence protocols, e.g. mobile telephones,... > JR Jonathan Rosenberg - draft assumes presence of phone. > Don't have to do > that, E.164 to pres uri, doesn't matter what kind of phone > JP - True but E.164 represents something in the PSTN > Generalizable beyond presence for a phone > JH - Looks like rerun of vovi. > JP - Accommodates other presence protocols > JR - pres URI won't get you a sip uri! > JP - yeah, you will be able to get to a sip service > RS - Rich Shockey Confused > JP - pres: uri dereferences to a service, could be sip, jabber,... > LC Layry Conroy - Point is that ENUM gets you pres: and then > you are out of > DDDS > > hum should this be a WG item - CONSENUS TO MAKE IT A WG ITEM > > Meeting closes. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 Thu Apr 10 12:19:25 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 MAA25506 for ; Thu, 10 Apr 2003 12:19:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AGPBF23868 for enum-archive@odin.ietf.org; Thu, 10 Apr 2003 12:25:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGPA823863; Thu, 10 Apr 2003 12:25:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AGO6823801 for ; Thu, 10 Apr 2003 12:24:06 -0400 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 MAA25469 for ; Thu, 10 Apr 2003 12:17:50 -0400 (EDT) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA11080; Thu, 10 Apr 2003 18:20:15 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA10471; Thu, 10 Apr 2003 18:20:17 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Apr 2003 18:19:57 +0200 Message-ID: <79D5F4B2D775204D9C7852EE41C5477391CF64@mchh2a1e.mchh.siemens.de> From: Brandner Rudolf To: enum@ietf.org Cc: "'Richard Shockey'" , "'paf@cisco.com'" , CONROY LAWRENCE , "Richard Stastny (E-mail)" Date: Thu, 10 Apr 2003 18:19:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] 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 all, the vovi draft in version 01 had been sent out on 23 March and can be obtained from http://www.ietf.org/internet-drafts/draft-brandner-enumservice-vovi-01.txt As per the minutes of the WG meeting in SFO, we pulled out the contentious parts and want to submit it to Allison Mankin as a personal draft real soon. So if you have comments on version 01, please send them in really soon. Many thanks, Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Fri Apr 11 15:43: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 PAA27056 for ; Fri, 11 Apr 2003 15:43:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BJnau22507 for enum-archive@odin.ietf.org; Fri, 11 Apr 2003 15:49:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJnH822488; Fri, 11 Apr 2003 15:49:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJRd820635 for ; Fri, 11 Apr 2003 15:27:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26270 for ; Fri, 11 Apr 2003 15:20:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 19447S-00053F-00 for enum@ietf.org; Fri, 11 Apr 2003 15:23:26 -0400 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19447R-00053C-00 for enum@ietf.org; Fri, 11 Apr 2003 15:23:26 -0400 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 h3BJMr126269; Fri, 11 Apr 2003 12:22:53 -0700 Message-Id: <5.2.0.9.2.20030410220454.052d5cc8@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Apr 2003 15:24:06 -0400 To: "bill" From: Richard Shockey Subject: Re: [Enum] LAST CALL for draft-ietf-enum-rfc2916bis-05.txt Cc: In-Reply-To: <003101c2ffcb$220f7ec0$6207e29f@enum1> References: <5.2.0.9.2.20030409092112.01c93958@popd.ix.netcom.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 09:39 AM 4/11/2003 +0800, bill wrote: >Hello, folks: > >Following is some of my comments: > >[1]section 1.2:"...that is how to handle numbers allocated according to >the ITU-T standard E.164...", E.164 is a recommendation, so I prefer to >use recommendation than standard here. OK ..this is an appropriate nit .. I agree with your suggestion. >[2]section 5, the two paragraph in the middle: " > IAB is to coordinate with ITU-T TSB if the technical contact for the > domain e164.arpa is to change, as ITU-T TSB has an operational > working relationship with this technical contact which needs to be > reestablished. > > Delegations in the zone e164.arpa (not delegations in delegated > domains of e164.arpa) should be done after Expert Review, and the > IESG will appoint a designated expert." > >I personally think these words are related to the management of e164.arpa >in practice and not very suitable in this section. There have been an >instruction to RIPE from IAB and an interim procedure from ITU-TSB in >place, as well as liaison between ITU-TSB and ISOC/IAB dealing with the >future cooperation. So maybe here just give some reference in this paper >for those who may interested in the management of e164.arpa. Well IMHO this is almost the same text as in 2916 I think we have strong consensus in the WG that we don't want to see this document delayed any longer. IMHO this issue is not fundamental to the protocol >[3] the security consideration section said too many things about the DNS >security threat which was mostly cited from a I-D of DNSEXT WG. I >personally think it should make some summary here about the DNS security >problems and give reference to the documents for further information. I appreciate your comments but I think given the unique audience for this draft it is useful and prudent to be somewhat pedagogical as Dave Crocker mentioned in a earlier message on the list. I continue to support the text as is. >Best > >-bill > >2003/04/11 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 11 19:28: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 TAA04960 for ; Fri, 11 Apr 2003 19:28:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BNYtj07589 for enum-archive@odin.ietf.org; Fri, 11 Apr 2003 19:34:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BNYl807576; Fri, 11 Apr 2003 19:34:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BNXT807542 for ; Fri, 11 Apr 2003 19:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04916 for ; Fri, 11 Apr 2003 19:26:36 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1947xH-0006Yz-00 for enum@ietf.org; Fri, 11 Apr 2003 19:29:11 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1947xG-0006Yw-00 for enum@ietf.org; Fri, 11 Apr 2003 19:29:11 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 12 Apr 2003 00:29:10 +0100 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 HSB1XX1S; Sat, 12 Apr 2003 00:29:06 +0100 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey Cc: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.2.0.9.2.20030409092112.01c93958@popd.ix.netcom.com> References: <5.2.0.9.2.20030409092112.01c93958@popd.ix.netcom.com> Date: Sat, 12 Apr 2003 00:29:05 +0100 Subject: Re: [Enum] LAST CALL for draft-ietf-enum-rfc2916bis-05.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:49 am -0400 9/4/03, Richard Shockey wrote: >I think it is fair to say we have thoroughly discussed this document >and reached rough consensus on the contentious issues as reflected >in this version so as the non author chair I'm going to declare a >last call on this for a 2 week period. > >So .... > >This is a formal request for final comments within the IETF ENUM WG >working group for one document. The document below is being proposed for >forwarding on to the IESG for consideration as Standards Track RFC. > Hi Folks, first comment. Change to section 3 requested. At the meeting (BTW, MANY thanks to Brian and our esteemed co-chair for the minutes) in response to my question, it was agreed to change the spec to require a standards track or experimental RFC, as some of the enumservices done during trials will be experimental (that's why we do trials :). This is not reflected in -05. In 2916bis-05, the last sentence of Section 3 currently reads: "In order to be a registered ENUM Service, the entire specification, including the template, requires approval by the IESG and publication of the Enumservice registration specification as an RFC either on the Standards Track or as a BCP". Please change this to: "In order to be a registered ENUM Service, the entire specification, including the template, requires approval by the IESG and publication of the Enumservice registration specification as an RFC either on the Standards Track or as a BCP or an Experimental RFC". (side) point: Looking at 2026 section 5, I don't see how an enumservice could ever be defined in a BCP. The meeting minutes show a group reluctance to include Informational (as I read it), but it seems that the 2026 description of BCP is not really appropriate to an enumservice definition as described in 2916bis section 3; a Standards track RFC would seem to be required, if the enumservice is not defined in an Experimental. I'm not asking that "BCP" be removed, but I just don't understand this. Any elucidation gratefully received. 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 Tue Apr 22 10:29: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 KAA11662 for ; Tue, 22 Apr 2003 10:29:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MEfXl10249 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 10:41:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEf8810226; Tue, 22 Apr 2003 10:41:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEc9809965 for ; Tue, 22 Apr 2003 10:38:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11501 for ; Tue, 22 Apr 2003 10:26:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197ykx-00026W-00 for enum@ietf.org; Tue, 22 Apr 2003 10:28:23 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 197ykx-00026K-00 for enum@ietf.org; Tue, 22 Apr 2003 10:28:23 -0400 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 h3MESBe01110 for ; Tue, 22 Apr 2003 14:28:11 GMT Message-Id: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 10:29:12 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. 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: , Speak now or forever hold your send button.. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 22 12:23: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 MAA15321 for ; Tue, 22 Apr 2003 12:23:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MGZXF18978 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 12:35:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGZN818959; Tue, 22 Apr 2003 12:35:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGYh818910 for ; Tue, 22 Apr 2003 12:34:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15231 for ; Tue, 22 Apr 2003 12:22:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980Zl-0002tZ-00 for enum@ietf.org; Tue, 22 Apr 2003 12:24:57 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1980Zk-0002tH-00 for enum@ietf.org; Tue, 22 Apr 2003 12:24:56 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <20R1A6N0>; Tue, 22 Apr 2003 17:25:02 +0100 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 HSB1YF52; Tue, 22 Apr 2003 17:24:57 +0100 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey , enum@ietf.org Cc: michael@neonym.net Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> References: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> Date: Tue, 22 Apr 2003 17:25:00 +0100 Subject: Re: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. 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:29 am -0400 22/4/03, Richard Shockey wrote: >Speak now or forever hold your send button.. > Hi again folks, Apart from , (to which still no response yet :( These are D3S questions (Michael ?) but impinge on 2916bis. Question - can D3S allow a "switch" in between non-terminal processing rounds from one D3S application to another? (i.e. can a subsequent round look for rules with a different D3S application from the one considered in the current round?) [This is important as without it I don't think we can use E2U NAPTRs in which the D3S processing starts outside the golden tree - it's not quite clear in 3401/3402, and There IS a change from 2916/2915 due to the restrictions on NAPTR use introduced when 2915 was obsoleted by 340x. => 2916bis could spell the answer to the question out (perhaps in a new (short) subsection immediately after 1.3 in the "general use" stuff)] Question - can D3S allow one database to be examined for rules for a D3S application in one round, and a different database to be examined for rules for that application in a subsequent round? (i.e. if a D3S application defines use of more than one database to store its rules, can it "switch" databases in between non-terminal rounds?) [My goal here is to be able to re-use the majority of 2916bis if we ever decide to plant some rules in another database (i.e. not all data need be in DNS) - it could happen. => I'm not sure that 2916bis is as "database-clean" as I think Michael originally intended in 340x; a single sentence spelling out what can or cannot be done in terms of Rule DB switching might be useful, in the "general use" section; again, after 1.3] Question - is the "1st Well Known Rule" application-specific or database-specific? As defined in 3402, the "1st Well Known Rule" is used to produce the first key. As this is described in 3401 as being in the D3S Application definition section (rather than the supported database section) I had thought that this meant that it is NOT a database-specific key. It is defined for 2916bis (section 2.4) to be identity; however, the "end" of this step is a domain name, so *IS* database-specific. Thus this implies that there should be one "1st Well Known Rule" for each supported D3S database. => Can we at least name this sequence of steps used to convert from (AUS (x) Identity) into a database-specific key? My suggestion is "Database-specific Key Generation", as that's what it does. This would split the text in the current section 2.4 into two parts, with a separate sub-section to cover the (reverse digits, interpose periods, append .e164.arpa.) DNS key generation text that's there already. so, new subsection 2.4.1. with text from "The output of the..." up to and including the "form of domain-names from the DNS". Looking at it, the BIND-specific stuff that follows starting "Some nameserver implementations" might me moved above the key generation stuff as well, but a minor point. 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 Tue Apr 22 12:31: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 MAA15559 for ; Tue, 22 Apr 2003 12:31:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MGh8w20258 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 12:43:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGh7820253; Tue, 22 Apr 2003 12:43:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGgo820234 for ; Tue, 22 Apr 2003 12:42:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15536 for ; Tue, 22 Apr 2003 12:30:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980hb-0002xy-00 for enum@ietf.org; Tue, 22 Apr 2003 12:33:03 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1980hb-0002xp-00 for enum@ietf.org; Tue, 22 Apr 2003 12:33:03 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <20R1A638>; Tue, 22 Apr 2003 17:33:25 +0100 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 HSB1YF57; Tue, 22 Apr 2003 17:33:20 +0100 From: "Conroy, Lawrence (SMTP)" To: enum@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Tue, 22 Apr 2003 17:33:24 +0100 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: 2916bis last call 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 again folks, minor point - example 2 of section 4.1 - could we swap this to "voice:h323" or remove the ":voice"? The current version is not quite right. From experience, folk tend to look at the "main" doc only and misunderstand, causing unnecessary confusion. 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 Tue Apr 22 13:16: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 NAA16900 for ; Tue, 22 Apr 2003 13:16:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MHSQm23010 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 13:28:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHSP823005; Tue, 22 Apr 2003 13:28:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHRh822963 for ; Tue, 22 Apr 2003 13:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16858 for ; Tue, 22 Apr 2003 13:15:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981P1-0003FN-00 for enum@ietf.org; Tue, 22 Apr 2003 13:17:55 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1981P1-0003Ef-00 for enum@ietf.org; Tue, 22 Apr 2003 13:17:55 -0400 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 h3MHHhe05705; Tue, 22 Apr 2003 17:17:43 GMT Message-Id: <5.2.0.9.2.20030422131506.06d81428@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 13:15:47 -0400 To: "Conroy, Lawrence (SMTP)" , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Re: 2916bis last call In-Reply-To: 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:33 PM 4/22/2003 +0100, Conroy, Lawrence (SMTP) wrote: >Hi again folks, > minor point - example 2 of section 4.1 - could we swap this >to "voice:h323" or remove the ":voice"? The current version is >not quite right. how about just h323? > From experience, folk tend to look at the "main" doc only and >misunderstand, causing unnecessary confusion. yes... I agree this is a minor editorial nit ... >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 22 13:16: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 NAA16914 for ; Tue, 22 Apr 2003 13:16:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MHSSv23038 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 13:28:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHSS823033; Tue, 22 Apr 2003 13:28:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHRh822968 for ; Tue, 22 Apr 2003 13:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16861 for ; Tue, 22 Apr 2003 13:15:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981P2-0003FS-00 for enum@ietf.org; Tue, 22 Apr 2003 13:17:56 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1981P2-0003Ec-00 for enum@ietf.org; Tue, 22 Apr 2003 13:17:56 -0400 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 h3MHHge05702; Tue, 22 Apr 2003 17:17:42 GMT Message-Id: <5.2.0.9.2.20030422131104.06d88e98@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 13:18:55 -0400 To: "Conroy, Lawrence (SMTP)" , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. Cc: michael@neonym.net In-Reply-To: References: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.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 05:25 PM 4/22/2003 +0100, Conroy, Lawrence (SMTP) wrote: >At 10:29 am -0400 22/4/03, Richard Shockey wrote: >>Speak now or forever hold your send button.. >Hi again folks, > >Apart from >, >(to which still no response yet :( > >These are D3S questions (Michael ?) but impinge on 2916bis. Impinge yes but are you suggesting clarifying text or something...are your comments more appropriate for a DDDSbis or 2916? There are lots of issue , like the partial number, that may be appropriate for another draft on ENUM Operations etc. >Question - can D3S allow a "switch" in between non-terminal processing >rounds from one D3S application to another? (i.e. can a subsequent round >look for rules with a different D3S application from the one considered >in the current round?) > >[This is important as without it I don't think we can use E2U NAPTRs in >which the D3S processing starts outside the golden tree - it's not quite >clear in 3401/3402, and There IS a change from 2916/2915 due to the >restrictions on NAPTR use introduced when 2915 was obsoleted by 340x. > >=> 2916bis could spell the answer to the question out (perhaps in a >new (short) subsection immediately after 1.3 in the "general use" stuff)] > >Question - can D3S allow one database to be examined for rules for a D3S >application in one round, and a different database to be examined for >rules for that application in a subsequent round? (i.e. if a D3S >application defines use of more than one database to store its rules, >can it "switch" databases in between non-terminal rounds?) > >[My goal here is to be able to re-use the majority of 2916bis if we >ever decide to plant some rules in another database (i.e. not all data >need be in DNS) - it could happen. > >=> I'm not sure that 2916bis is as "database-clean" as I think Michael >originally intended in 340x; a single sentence spelling out what can >or cannot be done in terms of Rule DB switching might be useful, >in the "general use" section; again, after 1.3] > >Question - is the "1st Well Known Rule" application-specific or >database-specific? > >As defined in 3402, the "1st Well Known Rule" is used to produce the first >key. As this is described in 3401 as being in the D3S Application definition >section (rather than the supported database section) I had thought that this >meant that it is NOT a database-specific key. It is defined for 2916bis >(section 2.4) to be identity; however, the "end" of this step is a domain >name, so *IS* database-specific. Thus this implies that there should be one >"1st Well Known Rule" for each supported D3S database. > >=> Can we at least name this sequence of steps used to convert from >(AUS (x) Identity) into a database-specific key? > >My suggestion is "Database-specific Key Generation", as that's what it >does. This would split the text in the current section 2.4 into two >parts, with a separate sub-section to cover the (reverse digits, interpose >periods, append .e164.arpa.) DNS key generation text that's there already. >so, new subsection 2.4.1. with text from "The output of the..." >up to and including the "form of domain-names from the DNS". > >Looking at it, the BIND-specific stuff that follows starting "Some >nameserver implementations" might me moved above the key generation >stuff as well, but a minor point. > >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 22 14:51: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 OAA20221 for ; Tue, 22 Apr 2003 14:51:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MJ3Xo30844 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 15:03:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJ36830828; Tue, 22 Apr 2003 15:03:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJ1V830768 for ; Tue, 22 Apr 2003 15:01:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20155 for ; Tue, 22 Apr 2003 14:49:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1982rm-00049t-00 for enum@ietf.org; Tue, 22 Apr 2003 14:51:42 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1982rl-00049q-00 for enum@ietf.org; Tue, 22 Apr 2003 14:51:42 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <20R1A69R>; Tue, 22 Apr 2003 19:52:05 +0100 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 HSB1YGAM; Tue, 22 Apr 2003 19:52:03 +0100 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey , enum@ietf.org Cc: michael@neonym.net Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.2.0.9.2.20030422131104.06d88e98@shockey.us> References: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> <5.2.0.9.2.20030422131104.06d88e98@shockey.us> Date: Tue, 22 Apr 2003 19:52:05 +0100 Subject: Re: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. 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 1:18 pm -0400 22/4/03, Richard Shockey wrote: >At 05:25 PM 4/22/2003 +0100, Conroy, Lawrence (SMTP) wrote: > >>At 10:29 am -0400 22/4/03, Richard Shockey wrote: >>>Speak now or forever hold your send button.. >>Hi again folks, >> >>Apart from >>, >>(to which still no response yet :( >> >>These are D3S questions (Michael ?) but impinge on 2916bis. > > >Impinge yes but are you suggesting clarifying text or >something...are your comments more appropriate for a DDDSbis or 2916? > >There are lots of issue , like the partial number, that may be >appropriate for another draft on ENUM Operations etc. > Hi Richard, folks, BTW, I'm not just doing the traditional IETF "comments at the last moment" for fun. I also considered whether these comments were appropriate for an Admin/"Care and Feeding" doc or were for 2916bis, hence the long pause. I AM asking for the clarifications on 2916bis, as the questions I raised were to do with this document - they were all aimed at "can we re-use the text when introducing other docs"? The Partial Number stuff is advice on how one populates a valid golden tree zone set. That's usage and provisioning. These Qs relate to some poor sod trying to write a D3S/E2U client, and relate to how it should handle the NAPTRs. For that, 2916bis and 340x are the one and only guide, so they have to be clear. E2U *is* different from other D3S applications in that the AUS and the database-specific key are in reverse order. This gives problems with REGEXP processing - it's hard to convert the order of the AUS by a REGEXP into a "golden tree" FQDN. The DNS key generation step is not mentioned as such in 3402, and confusion over this (whether or not this happened ONLY at the same time as the 1st Well Known Rule is generated or on loop back between non-terminal processing D3S rounds as well) triggered an earlier set of mail exchanges on this list - (see the "D3S details redux", "ENUM root shift" and "Relief Area Codes and REGEXP" threads from last September). Having gone through that learning experience (many thanks to Michael), I'd like others not to fall into the same confusion. Hence the proposals to spell out that this happens only at the start of the first round and to highlight it as a separate sub-step, and that you can/can't change rule database or D3S applications between non-terminal rounds. 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 Tue Apr 22 15:03: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 PAA20838 for ; Tue, 22 Apr 2003 15:03:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MJFEW32242 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 15:15:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJFD832237; Tue, 22 Apr 2003 15:15:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJEd832178 for ; Tue, 22 Apr 2003 15:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20759 for ; Tue, 22 Apr 2003 15:02:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19834T-0004FY-00 for enum@ietf.org; Tue, 22 Apr 2003 15:04:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19834T-0004FJ-00 for enum@ietf.org; Tue, 22 Apr 2003 15:04:49 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Re: 2916bis last call MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Tue, 22 Apr 2003 21:08:47 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F1620DF11F@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Re: 2916bis last call Thread-Index: AcMI9HDNwWnblDTfTl+9V3TAejI/DAADfq1J From: "Stastny Richard" To: "Richard Shockey" , "Conroy, Lawrence (SMTP)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h3MJEd832179 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 Before we start the whole discussion all over again ;-) I would also suggest to leave it just with h323. Richard -----Ursprüngliche Nachricht----- Von: Richard Shockey [mailto:rich.shockey@neustar.biz] Gesendet: Di 22.04.2003 19:15 An: Conroy, Lawrence (SMTP); enum@ietf.org Cc: Betreff: Re: [Enum] Re: 2916bis last call At 05:33 PM 4/22/2003 +0100, Conroy, Lawrence (SMTP) wrote: >Hi again folks, > minor point - example 2 of section 4.1 - could we swap this >to "voice:h323" or remove the ":voice"? The current version is >not quite right. how about just h323? > From experience, folk tend to look at the "main" doc only and >misunderstand, causing unnecessary confusion. yes... I agree this is a minor editorial nit ... >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Tue Apr 22 16:19: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 QAA24666 for ; Tue, 22 Apr 2003 16:19:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MKVAA05438 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 16:31:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKUU805362; Tue, 22 Apr 2003 16:30:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKR7805143 for ; Tue, 22 Apr 2003 16:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24338 for ; Tue, 22 Apr 2003 16:14:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1984CZ-0004s3-00 for enum@ietf.org; Tue, 22 Apr 2003 16:17:15 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1984CZ-0004re-00 for enum@ietf.org; Tue, 22 Apr 2003 16:17:15 -0400 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 h3MKH7e15026; Tue, 22 Apr 2003 20:17:07 GMT Message-Id: <5.2.0.9.2.20030422161242.0511c900@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 16:18:17 -0400 To: "Conroy, Lawrence (SMTP)" , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. Cc: michael@neonym.net In-Reply-To: References: <5.2.0.9.2.20030422131104.06d88e98@shockey.us> <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> <5.2.0.9.2.20030422131104.06d88e98@shockey.us> 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: , A >>Impinge yes but are you suggesting clarifying text or something...are >>your comments more appropriate for a DDDSbis or 2916? >> >>There are lots of issue , like the partial number, that may be >>appropriate for another draft on ENUM Operations etc. > >Hi Richard, folks, > BTW, I'm not just doing the traditional IETF "comments at the >last moment" for fun. I also considered whether these comments >were appropriate for an Admin/"Care and Feeding" doc or were for >2916bis, hence the long pause. > >I AM asking for the clarifications on 2916bis, as the questions >I raised were to do with this document - they were all aimed at >"can we re-use the text when introducing other docs"? > >The Partial Number stuff is advice on how one populates a valid >golden tree zone set. That's usage and provisioning. So my question still stands Is this a 2916bis issue? DDDS bis issue? or ENUM Care and Feeding issue? Your chair would like to avoid another round trip here.... >These Qs relate to some poor sod trying to write a D3S/E2U client, >and relate to how it should handle the NAPTRs. For that, 2916bis >and 340x are the one and only guide, so they have to be clear. > >E2U *is* different from other D3S applications in that the AUS >and the database-specific key are in reverse order. This gives >problems with REGEXP processing - it's hard to convert the order >of the AUS by a REGEXP into a "golden tree" FQDN. The DNS key >generation step is not mentioned as such in 3402, and confusion >over this (whether or not this happened ONLY at the same time as >the 1st Well Known Rule is generated or on loop back between >non-terminal processing D3S rounds as well) triggered an earlier >set of mail exchanges on this list - (see the "D3S details redux", >"ENUM root shift" and "Relief Area Codes and REGEXP" threads from >last September). Having gone through that learning experience >(many thanks to Michael), I'd like others not to fall into the same >confusion. > >Hence the proposals to spell out that this happens only at the >start of the first round and to highlight it as a separate sub-step, >and that you can/can't change rule database or D3S applications >between non-terminal rounds. > > >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 22 16:19: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 QAA24681 for ; Tue, 22 Apr 2003 16:19:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MKVIr05485 for enum-archive@odin.ietf.org; Tue, 22 Apr 2003 16:31:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKVI805480; Tue, 22 Apr 2003 16:31:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKR8805148 for ; Tue, 22 Apr 2003 16:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24342 for ; Tue, 22 Apr 2003 16:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1984Ca-0004sB-00 for enum@ietf.org; Tue, 22 Apr 2003 16:17:16 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1984Ca-0004rf-00 for enum@ietf.org; Tue, 22 Apr 2003 16:17:16 -0400 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 h3MKH7e15023; Tue, 22 Apr 2003 20:17:07 GMT Message-Id: <5.2.0.9.2.20030422161129.04f75e60@shockey.us> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 22 Apr 2003 16:11:50 -0400 To: "Stastny Richard" , "Conroy, Lawrence (SMTP)" , From: Richard Shockey Subject: Re: AW: [Enum] Re: 2916bis last call In-Reply-To: <06CF906FE3998C4E944213062009F1620DF11F@oefeg-s02.oefeg.loc > 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 h3MKR8805149 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 09:08 PM 4/22/2003 +0200, Stastny Richard wrote: >Before we start the whole discussion all over again ;-) >I would also suggest to leave it just with h323. >Richard Thank you _very_ much... > -----Ursprüngliche Nachricht----- > Von: Richard Shockey [mailto:rich.shockey@neustar.biz] > Gesendet: Di 22.04.2003 19:15 > An: Conroy, Lawrence (SMTP); enum@ietf.org > Cc: > Betreff: Re: [Enum] Re: 2916bis last call > > > > At 05:33 PM 4/22/2003 +0100, Conroy, Lawrence (SMTP) wrote: > > >Hi again folks, > > minor point - example 2 of section 4.1 - could we swap this > >to "voice:h323" or remove the ":voice"? The current version is > >not quite right. > > how about just h323? > > > From experience, folk tend to look at the "main" doc only and > >misunderstand, causing unnecessary confusion. > > yes... I agree this is a minor editorial nit ... > > > >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 > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 23 11:16:21 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 LAA22896 for ; Wed, 23 Apr 2003 11:16:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NFSRg01595 for enum-archive@odin.ietf.org; Wed, 23 Apr 2003 11:28:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NFS5801584; Wed, 23 Apr 2003 11:28:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NFQA801465 for ; Wed, 23 Apr 2003 11:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22827 for ; Wed, 23 Apr 2003 11:13:34 -0400 (EDT) From: Joakim.Stralmark@pts.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LyV-0004iU-00 for enum@ietf.org; Wed, 23 Apr 2003 11:15:55 -0400 Received: from mail.pts.se ([192.121.211.220]) by ietf-mx with esmtp (Exim 4.12) id 198LyU-0004iC-00 for enum@ietf.org; Wed, 23 Apr 2003 11:15:54 -0400 Received: from NT3.pts.se (unverified) by mail.pts.se (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 23 Apr 2003 17:20:01 +0200 Received: by NT3.pts.se with Internet Mail Service (5.5.2655.55) id <1V3D7T8L>; Wed, 23 Apr 2003 17:17:04 +0200 Message-ID: <6913523FE9720C4A8778E1BB51755D2F125E9D@NT3.pts.se> To: rich.shockey@neustar.biz, enum@ietf.org Cc: paf@cisco.com, enum@autonomica.se Subject: SV: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. Date: Wed, 23 Apr 2003 17:16:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 h3NFQA801466 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 Some comments from the Swedish Administration/NRA about version 05 of RFC 2916bis. 1. In 1. Introduction and in 1.3 Application of local policy there are two entities mentioned; "approriate zone administrator" and "zone authoority" - for us it´s not clear if this means the same kind of entity or different ones - please clarify. Use of word "authority" when talking about entities might mean governmental agencies and we think it must be clear what kind of "authority" to be used in this RFC. 2. In 1.2 Use for ... Please change "standard" to "recommendation" togheter with ITU-T and E.164. 3. In 1.3 Application .... There is the use of the wording "intranet specific zone" - is this the same as the concept of "private dialing plan" in 1.2 - please clarify the difference or similarity of these topics in the RFC. 4. In 2 The ENUM Application... In the second paragraph - it´s very unclear what is meant by "numerous numbering plans that can change over time" - does this mean numbering plans like X.121 and E.212 or does it mean diffrent national numbering plans that is based on E.164 - please clarify this. This paragraph also gives an uncertanity about the correctnes about the E.164-number used in ENUM when talking about "syntactically correct E.164-number" - as we see it an E.164 number is an E.164-number and the rules for this can be found in ITU-T Recommendation E.164 which describes the E.164 numbering plan. It is stated there that an E.164 number identifies a unique subscriber, service or network termination point (both fixed and mobile) independently of the level at which the dialling takes place in relation to the E.164 number. Furthermore, it is stated that an E.164 number has a hierarchical structure that facilitates this particular dialling at different levels (local, national and international), that E.164 numbers are reachable from other countries by international dialling and that the number length in the international format is a maximum of 15 digits. Finally, it is stated in the ITU-T Recommendation that a numbering plan does not include prefixes, suffixes or other additional information that is needed to complete a call connection. These are included in what is referred to in the ITU-T's E.164 Recommendation as the dialling plan and which states how the numbering plan is used. Last comment about 2 - what is the meaning of "non-E.164-number" in the RFC - does it mean numbers from other numbering plans, e.g. X.121 or E.118 or does it mean numbers in the national numbering plan (based on E.164) that not strictly is E.164-numbers, e.g. number 112 used for emergency services in some European countries - please clarify this. 5. In 2.1 Application .... The word "telephone numbers" is used that not are part of the E.164 namespace - this is also unclear - please see our comments above about "non-E.164-numbers" - please clarify. 6. In 3.1.1. in the bracket in last paragraph the abbreviation "DNs" is used - does this mean "directory Numbers(s)" or not? 7. In 3.1.3 Security.... The example in indent 3. about "confidential medical information" sounds very far-away from communications applications and service over Internet/PSTN/PLMNs- please give an example more related to "ENUM" mapping functions. 8. In 5. IANA Considerations - it should be "ITU-T Recommendation E.164" - not just ITU Rec... And also change ITU-T TSB to just "ITU TSB". In general the text under 5 looks OK for the relationship to the ITU TSB concerning delegations for .e164.arpa. Maybe the second sentence in the first paragraph could look as: "Names within this zone are to be delegated to assignes that has been assigned numbering resources according to the ITU-T Recommendation E.164." Sincerely Joakim Strålmark National Post & Telecom Agency Sweden Tel. +46 70 811 4064 E-mail joakim.stralmark@pts.se -----Ursprungligt meddelande----- Från: Richard Shockey [mailto:rich.shockey@neustar.biz] Skickat: den 22 april 2003 16:29 Till: enum@ietf.org Ämne: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. Speak now or forever hold your send button.. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 23 12:08: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 MAA24782 for ; Wed, 23 Apr 2003 12:08:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NGKGO06386 for enum-archive@odin.ietf.org; Wed, 23 Apr 2003 12:20:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGKF806381; Wed, 23 Apr 2003 12:20:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGJw806331 for ; Wed, 23 Apr 2003 12:19:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24764 for ; Wed, 23 Apr 2003 12:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198MoX-00059p-00 for enum@ietf.org; Wed, 23 Apr 2003 12:09:41 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 198MoX-00059g-00 for enum@ietf.org; Wed, 23 Apr 2003 12:09:41 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id F16FB137F0E; Wed, 23 Apr 2003 09:09:34 -0700 (PDT) To: rich.shockey@neustar.biz, enum@ietf.org Date: Wed, 23 Apr 2003 09:09:34 -0700 Message-ID: <67215.1051114174@shell.nominum.com> From: Jim Reid Subject: [Enum] minor nit with 2916bis 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: , There are a couple of typos at the top of page 17: [1] "Finally, as an ENUM services will be....". This should be "an ENUM service" or "as ENUM services". [2] receive is mis-spelt. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Wed Apr 23 12:46:21 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 MAA25635 for ; Wed, 23 Apr 2003 12:46:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NGwRt08995 for enum-archive@odin.ietf.org; Wed, 23 Apr 2003 12:58:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGwO808989; Wed, 23 Apr 2003 12:58:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGuh808867 for ; Wed, 23 Apr 2003 12:56:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25588 for ; Wed, 23 Apr 2003 12:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198NO5-0005Oa-00 for enum@ietf.org; Wed, 23 Apr 2003 12:46:25 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 198NO5-0005OM-00 for enum@ietf.org; Wed, 23 Apr 2003 12:46:25 -0400 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 h3NGkFe04865 for ; Wed, 23 Apr 2003 16:46:15 GMT Message-Id: <5.2.0.9.2.20030423124339.04fa0370@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Apr 2003 12:46:28 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] OK.... I think we need to recycle 2906bis into version 06 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 think I've seen enough comments on nits and substantive issues to ask the authors of 2906bis to recycle version 05 into 06. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 29 13:11: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 NAA02024 for ; Tue, 29 Apr 2003 13:11:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3THGxl01150 for enum-archive@odin.ietf.org; Tue, 29 Apr 2003 13:16:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THGS801087; Tue, 29 Apr 2003 13:16:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THEn800923 for ; Tue, 29 Apr 2003 13:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01655 for ; Tue, 29 Apr 2003 13:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AYdX-0006BT-00 for enum@ietf.org; Tue, 29 Apr 2003 13:11:23 -0400 Received: from [209.10.143.221] (helo=neonym.net) by ietf-mx with esmtp (Exim 4.12) id 19AYdW-0006BQ-00 for enum@ietf.org; Tue, 29 Apr 2003 13:11:22 -0400 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Mon, 28 Apr 2003 23:43:12 -0400 Subject: Re: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. From: Michael Mealling To: "Conroy, Lawrence (SMTP)" Cc: Richard Shockey , enum@ietf.org In-Reply-To: References: <5.2.0.9.2.20030422102817.05285ec8@popd.ix.netcom.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1051636129.11902.17.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: 29 Apr 2003 13:08:49 -0400 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-04-22 at 12:25, Conroy, Lawrence (SMTP) wrote: > At 10:29 am -0400 22/4/03, Richard Shockey wrote: > >Speak now or forever hold your send button.. Apologies for just now getting to this.... > Apart from > , > (to which still no response yet :( You are correct. The document was simply changed to this: In order to be a registered ENUM Service, the entire specification, including the template, requires approval by the IESG and publication of the Enumservice registration specification as an RFC. > These are D3S questions (Michael ?) but impinge on 2916bis. > > Question - can D3S allow a "switch" in between non-terminal processing > rounds from one D3S application to another? (i.e. can a subsequent round > look for rules with a different D3S application from the one considered > in the current round?) > > [This is important as without it I don't think we can use E2U NAPTRs in > which the D3S processing starts outside the golden tree - it's not quite > clear in 3401/3402, and There IS a change from 2916/2915 due to the > restrictions on NAPTR use introduced when 2915 was obsoleted by 340x. > => 2916bis could spell the answer to the question out (perhaps in a > new (short) subsection immediately after 1.3 in the "general use" stuff)] The problem is that delegations higher in the process may not be aware of what you are doing. But it is a 'may' only. Since the input to a rule is always the AUS and not the output of the last rule, each node in the delegation process is essentially 'stateless'. Thus a Rule can't know or care about why it got requested, as long as the Services and Flags fields are interpreted consistently with that Rule's application. I would say it this way: you SHOULD not switch from one application to another, but as long as you really know what you're doing, it might be ok. But, you should never switch from one application to another one 'willy nilly'. I.e. be VERY aware of what you are doing. As far as the document goes I'm not sure if I'd really want to put that in there. It doesn't say anything about it right now and that's probably a good thing. > Question - can D3S allow one database to be examined for rules for a D3S > application in one round, and a different database to be examined for > rules for that application in a subsequent round? (i.e. if a D3S > application defines use of more than one database to store its rules, > can it "switch" databases in between non-terminal rounds?) Icky! Umm..... by 'round' do you mean an iteration through the algorithm or a completely new start at the beginning of the algorithm? I'm going to assume you mean the first. I would strongly suggest against it unless you really standardized the process. I can't really say definitively if you can or can't since I only know of two databases. Is it generally ok? Probably not. Might it be ok in controlled circumstances? possibly. > [My goal here is to be able to re-use the majority of 2916bis if we > ever decide to plant some rules in another database (i.e. not all data > need be in DNS) - it could happen. > => I'm not sure that 2916bis is as "database-clean" as I think Michael > originally intended in 340x; a single sentence spelling out what can > or cannot be done in terms of Rule DB switching might be useful, > in the "general use" section; again, after 1.3] I really don't want to open up that issue in this document. The pedagogical requirements around making it understandable by the average reader would be prohibitive. I would suggest we simply keep that in our drawer of 'things some crazy person might do one day' to keep an eye out for. Believe me, I've come up with crazier stuff! ;-) > Question - is the "1st Well Known Rule" application-specific or > database-specific? The AUS is application specific. The database format method converts the general Key to a database specific one. > As defined in 3402, the "1st Well Known Rule" is used to produce the first > key. As this is described in 3401 as being in the D3S Application definition > section (rather than the supported database section) I had thought that this > meant that it is NOT a database-specific key. Correct.... > It is defined for 2916bis > (section 2.4) to be identity; Actually, the mention of that in 2.4 is just to recall the actual definition of the AUS which is in Section 2.2. Section 2.4 is the database specific part. > however, the "end" of this step is a domain > name, so *IS* database-specific. Thus this implies that there should be one > "1st Well Known Rule" for each supported D3S database. Correct. 2.4 is the database part which handles converting the new, database agnostic Key into a domain-name. > => Can we at least name this sequence of steps used to convert from > (AUS (x) Identity) into a database-specific key? > > My suggestion is "Database-specific Key Generation", as that's what it > does. This would split the text in the current section 2.4 into two > parts, with a separate sub-section to cover the (reverse digits, interpose > periods, append .e164.arpa.) DNS key generation text that's there already. > so, new subsection 2.4.1. with text from "The output of the..." > up to and including the "form of domain-names from the DNS". Hmm.... Isn't section 2.2 sufficiently separate? > Looking at it, the BIND-specific stuff that follows starting "Some > nameserver implementations" might me moved above the key generation > stuff as well, but a minor point. I might make it a subsection considering the fact that its implementation advice for that particular database. -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Apr 29 13:45: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 NAA03312 for ; Tue, 29 Apr 2003 13:45:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3THoK204601 for enum-archive@odin.ietf.org; Tue, 29 Apr 2003 13:50:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THoI804592; Tue, 29 Apr 2003 13:50:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THnG804553 for ; Tue, 29 Apr 2003 13:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03230 for ; Tue, 29 Apr 2003 13:43:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZAr-0006Y6-00 for enum@ietf.org; Tue, 29 Apr 2003 13:45:49 -0400 Received: from [209.10.143.221] (helo=neonym.net) by ietf-mx with esmtp (Exim 4.12) id 19AZAq-0006Y3-00 for enum@ietf.org; Tue, 29 Apr 2003 13:45:48 -0400 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Tue, 29 Apr 2003 00:17:37 -0400 Subject: Re: SV: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. From: Michael Mealling To: Joakim.Stralmark@pts.se Cc: rich.shockey@neustar.biz, enum@ietf.org, paf@cisco.com, enum@autonomica.se In-Reply-To: <6913523FE9720C4A8778E1BB51755D2F125E9D@NT3.pts.se> References: <6913523FE9720C4A8778E1BB51755D2F125E9D@NT3.pts.se> Organization: Harriman Heavy Industries, Inc. Message-Id: <1051638193.11902.48.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Apr 2003 13:43:13 -0400 X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.39.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3THnH804554 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 Wed, 2003-04-23 at 11:16, Joakim.Stralmark@pts.se wrote: > Hello > > Some comments from the Swedish Administration/NRA about version 05 of RFC > 2916bis. > > 1. In 1. Introduction and in 1.3 Application of local policy there are two > entities mentioned; "approriate zone administrator" and "zone authoority" - > for us it´s not clear if this means the same kind of entity or different > ones - please clarify. Use of word "authority" when talking about entities > might mean governmental agencies and we think it must be clear what kind of > "authority" to be used in this RFC. I think they can be separate entities. An administrator takes direction from an authority. How does this sound: Holders of E.164 numbers which want to be listed in DNS should contact the administrator or authority for the zone (authority meaning simply the entity that has change control over that zone, nothing more) in order to be listed. This information can be found by examining the SOA resource record associated with the zone, just like in normal DNS operations. > 2. In 1.2 Use for ... Please change "standard" to "recommendation" togheter > with ITU-T and E.164. Done. > 3. In 1.3 Application .... There is the use of the wording "intranet > specific zone" - is this the same as the concept of "private dialing plan" > in 1.2 - please clarify the difference or similarity of these topics in the > RFC. I simply changed 'intranet' to 'private-dialing-plan' since for that example there is no real pedagogical difference. > 4. In 2 The ENUM Application... In the second paragraph - it´s very unclear > what is meant by "numerous numbering plans that can change over time" - does > this mean numbering plans like X.121 and E.212 or does it mean diffrent > national numbering plans that is based on E.164 - please clarify this. I qualified 'numbering plan' by putting 'national' in front of it. It now reads like this: Since there are numerous national numbering plans which can change over time , it is probably impossible for a client application to have perfect knowledge about every E.164 numbering plan. > This paragraph also gives an uncertanity about the correctnes about the > E.164-number used in ENUM when talking about "syntactically correct > E.164-number" - as we see it an E.164 number is an E.164-number and the > rules for this can be found in ITU-T Recommendation E.164 which describes > the E.164 numbering plan. It is stated there that an E.164 number identifies > a unique subscriber, service or network termination point (both fixed and > mobile) independently of the level at which the dialling takes place in > relation to the E.164 number. Furthermore, it is stated that an E.164 number > has a hierarchical structure that facilitates this particular dialling at > different levels (local, national and international), that E.164 numbers are > reachable from other countries by international dialling and that the number > length in the international format is a maximum of 15 digits. Finally, it is > stated in the ITU-T Recommendation that a numbering plan does not include > prefixes, suffixes or other additional information that is needed to > complete a call connection. These are included in what is referred to in the > ITU-T's E.164 Recommendation as the dialling plan and which states how the > numbering plan is used. The problem here seems to be in picking the correct terminology. The other problem is that there probably isn't an agreed upon term to use. The issue is that I can create a number that is an E.164 number that is actually invalid according to a nations specific numbering plan. For example, +46-770-923-9695 is probably correct according to E.164 but not according to the numbering plan for Sweden. Since a) nations can change their numbering plans and b) it is prohibitive to include the numbering plan of every country code within my cell phone, I run the probably chance of asking ENUM for that number. What do you call that number? Invalid? Incorrect? syntactically correct but numbering-plan-invalid? > Last comment about 2 - what is the meaning of "non-E.164-number" in the RFC > - does it mean numbers from other numbering plans, e.g. X.121 or E.118 or > does it mean numbers in the national numbering plan (based on E.164) that > not strictly is E.164-numbers, e.g. number 112 used for emergency services > in some European countries - please clarify this. Any number that isn't compatible with E.164. Are X.121 and E.118 based on E.164? Numbering plans are 'based on' E.164 so they're an E.164 number. '112' isn't so it isn't..... Again, its terminology, my cell phone's number is +1-404-579-8900. What do you call that number? Is it "a number that is _based_ on E.164" or is "it an E.164 number" or "an number that is in compliance with ITU Recommendation E.164"? > 5. In 2.1 Application .... The word "telephone numbers" is used that not are > part of the E.164 namespace - this is also unclear - please see our comments > above about "non-E.164-numbers" - please clarify. Why is it unclear? There are numbers I can dial on a telephone that are not E.164 numbers? Correct? Either a number is or is not an E.164 number? Or am I missing something fundamental? > 6. In 3.1.1. in the bracket in last paragraph the abbreviation "DNs" is used > - does this mean "directory Numbers(s)" or not? Within LDAP the term 'DN' means 'Distinguished Name'. I've expanded that acronym... > 7. In 3.1.3 Security.... The example in indent 3. about "confidential > medical information" sounds very far-away from communications applications > and service over Internet/PSTN/PLMNs- please give an example more related to > "ENUM" mapping functions. I've changed it to phone system activated alarm systems and message centers. Still, health systems seems appropriate. My uncle's pacemaker calls in to the doctor's system every few days and is reprogrammed over the phone to a new cardiac rhythm. I'd surely want that number secure! ;-) > 8. In 5. IANA Considerations - it should be "ITU-T Recommendation E.164" - > not just ITU Rec... And also change ITU-T TSB to just "ITU TSB". In general > the text under 5 looks OK for the relationship to the ITU TSB concerning > delegations for .e164.arpa. Maybe the second sentence in the first > paragraph could look as: "Names within this zone are to be delegated to > assignes that has been assigned numbering resources according to the ITU-T > Recommendation E.164." Since I didn't write this section I'm going to differ to Patrik on these wording changes. Patrik? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From mailnull@www1.ietf.org Tue Apr 29 21:42: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 VAA20835 for ; Tue, 29 Apr 2003 21:42:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U1lp819646 for enum-archive@odin.ietf.org; Tue, 29 Apr 2003 21:47:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U1lh819635; Tue, 29 Apr 2003 21:47:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U1ka819564 for ; Tue, 29 Apr 2003 21:46:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20789 for ; Tue, 29 Apr 2003 21:40:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Agcd-0002Vk-00 for enum@ietf.org; Tue, 29 Apr 2003 21:42:59 -0400 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Agcc-0002Vb-00 for enum@ietf.org; Tue, 29 Apr 2003 21:42:58 -0400 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 h3U1hHN08405 for ; Tue, 29 Apr 2003 18:43:17 -0700 Message-Id: <5.2.0.9.2.20030429214055.04d2bea0@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 21:44:53 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FW: [DPSWG] ENUM - CDT Report Analyzes Public Policy Issues 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 ... many of you will know John Morris of CDT from his IETF work in GEOPRIV he is one of the few if perhaps only Washington DC Policy Advocates that has taken the time and effort to work directly in the IETF. IMHO Its a fine report BTW worthy of our careful consideration. >__________________________________________ > >CDT POLICY POST Volume 9, Number 9, April 28, 2003 > >A Briefing On Public Policy Issues Affecting Civil Liberties Online >from >The Center For Democracy and Technology > >(1) CDT Report Analyzes Public Policy Concerns About ENUM Technology >(2) What is ENUM, and Has It Been Deployed Yet? >(3) Policy Issues Raised by ENUM >(4) Recommendations for ENUM Implementations > >------------------------------------------------------------- >(1) CDT Report Analyzes Public Policy Concerns About ENUM Technology > >ENUM, a technology protocol that may provide a critical tool in the >more widespread adoption of "voice over the Internet" services, also >poses risks to privacy. > >CDT's Standards, Technology & Policy Project has issued a report >analyzing a range of privacy and other public policy concerns raised >by the ENUM protocol. The report sets out detailed policy >recommendations that should be followed by national governments and >service providers in any implementation of ENUM. > >"ENUM: Mapping Telephone Numbers onto the Internet -- Potential >Benefits With Public Policy Risks" is available at >http://www.cdt.org/standards/enum/. > >Additional information about CDT's Standards Project is available at >http://www.cdt.org/standards/. > >------------------------------------------------------------- >(2) What is ENUM and Has it Been Deployed Yet? > >ENUM is a protocol that allows the translation of normal telephone >numbers into a format that can be used to store and retrieve Internet >addressing information, which can in turn be used to route >communications over the Internet. With ENUM and "Voice over Internet >Protocol" ("VoIP") technology, an increasingly amount of voice >communications can be carried over the Internet instead of over the >traditional telephone network. Initially, ENUM is likely to be >deployed by corporations and other large institutions that seek to >reduce their use of traditional telephone services (especially >international and other long distance service). This technology has >the potential to allow users -- corporations and individuals -- to >save money and increase the choices they can exercise in their >communications. > >ENUM will facilitate the routing of telephone calls over the >Internet, in a manner that is seamless to the end users. To place a >call with ENUM, (1) a person dials a standard phone number on a >normal telephone (or on a telephone-like device connected to a >computer), (2) the computer or telephone system uses ENUM to check if >the called number can be reached over the Internet using VoIP >technology, (3) if the number can be reached, a VoIP call is >initiated, and (4) if the number cannot be reached over the Internet, >the call is routed to the traditional telephone network. > >ENUM-compliant technologies and implementations are still in the >development and testing stages. A number of nations around the world >have initiated formal ENUM "test bed" implementations. The United >States Department of Commerce has endorsed the U.S.'s participation >in ENUM, and set out a series of guidelines to be met before formal >tests or government-sanctioned implementations can proceed. >Commercial deployment of ENUM services is likely to take place by the >end of 2004. > >------------------------------------------------------------- >(3) Policy Issues Raised by ENUM > >ENUM's potential benefits also bring risks in terms of privacy and >other public policy concerns. The simplest implementation of ENUM >envisions that individuals' personal contact information (such as >telephone numbers and e-mail addresses) will be stored in special >records located in the Domain Name System (or DNS) of the global >Internet. Because the DNS is publicly available, ENUM could >significantly compromise the privacy of its users, and could lead to >additional spam and other problems. > >A more complex use of ENUM (in conjunction with a device called a >"proxy server"), however, offers the opportunity to gain the benefits >of ENUM without sacrificing control over personal information. To >minimize the potential harmful effect of ENUM on privacy, it is vital >that this second, more complex approach to ENUM be permitted and >available in the marketplace. > >Other important issues turn, for example, on (a) how much information >individuals or companies will be required to provide in order to take >advantage of ENUM, and (b) how much of that information will be >revealed in a public database (similar to the "whois" database which >reveals information about domain name holders). >In a different vein, ENUM raises a range of policy issues about how >closely "ENUM numbers" should be tied to existing traditional >telephone numbers. > >One critical aspect of the global public policy issues surrounding >ENUM is the fact that ENUM will, for the most part, be implemented >within each country by the telephone authorities or companies that >operate within that country. Thus, many critical decisions (for >example, about how much information will be required to obtain an >ENUM number) will be made on a country-by-country basis. It is >critical that within each country, the relevant telephone authorities >must closely consult with the public interest and civil society >sector, the communications industry, and the computer industry. > >------------------------------------------------------------- >(4) Recommendations for ENUM Implementations > >To ensure that users can take advantage of ENUM without sacrificing >privacy, any implementation of ENUM should follow a number of >guidelines to ensure that there is a diversity of ENUM service >providers and that those providers will be able to offer >privacy-protecting ENUM options. CDT's report on ENUM details 14 >specific policy recommendations. Among the specific recommendations >are: > >- At no time should any ENUM record be created without the express >consent of the individual or entity that subscribes to the >corresponding telephone number on the traditional telephone network. >An ENUM user should explicitly "opt-in" to the ENUM service. > >- No publicly accessible whois-like database of ENUM subscribers >should be created. > >- Prospective ENUM users should receive clear notice of the privacy >risks and consequences of using ENUM. > >- ENUM policy within a country should be set in close consultation >with the public interest and civil society sector, the communications >industry, and the Internet industry. > >CDT's report on ENUM also provides a bibliography of references and >links to ENUM resources and analyses. > >------------------------------------------------------------- >Detailed information about online civil liberties issues may be found >at http://www.cdt.org/. > >This document may be redistributed freely in full or linked to >http://www.cdt.org/publications/pp_9.09.shtml. > >Excerpts may be re-posted with prior permission of ari@cdt.org > >Policy Post 9.09. Copyright 2003 Center for Democracy and Technology > >_______________________________________________ >http://www.cdt.org/mailman/listinfo/policy-posts >_______________________________________________ >http://www.cdt.org/mailman/listinfo/dpswg >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Apr 30 00:44: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 AAA25479 for ; Wed, 30 Apr 2003 00:44:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U4o5t07714 for enum-archive@odin.ietf.org; Wed, 30 Apr 2003 00:50:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U4nw807695; Wed, 30 Apr 2003 00:49:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U4cK807255 for ; Wed, 30 Apr 2003 00:38:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25207 for ; Wed, 30 Apr 2003 00:32:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AjIl-0003iA-00 for enum@ietf.org; Wed, 30 Apr 2003 00:34:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AjIl-0003gw-00 for enum@ietf.org; Wed, 30 Apr 2003 00:34:39 -0400 Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3U4YHZA029743; Wed, 30 Apr 2003 00:34:42 -0400 (EDT) Received: from cisco.com (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id GAA28401; Wed, 30 Apr 2003 06:29:20 +0200 (MET DST) Date: Wed, 30 Apr 2003 06:29:18 +0200 Subject: Re: SV: [Enum] REMINDER ... Last call on 2916 bis ends tommrrow. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Joakim.Stralmark@pts.se, rich.shockey@neustar.biz, enum@ietf.org, enum@autonomica.se To: Michael Mealling From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1051638193.11902.48.camel@blackdell.neonym.net> Message-Id: <4EFFD411-7AC4-11D7-91C2-000A959CF516@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U4cL807256 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 tisdag, apr 29, 2003, at 19:43 Europe/Stockholm, Michael Mealling wrote: > On Wed, 2003-04-23 at 11:16, Joakim.Stralmark@pts.se wrote: >> Hello >> >> Some comments from the Swedish Administration/NRA about version 05 of >> RFC >> 2916bis. >> >> 1. In 1. Introduction and in 1.3 Application of local policy there >> are two >> entities mentioned; "approriate zone administrator" and "zone >> authoority" - >> for us it´s not clear if this means the same kind of entity or >> different >> ones - please clarify. Use of word "authority" when talking about >> entities >> might mean governmental agencies and we think it must be clear what >> kind of >> "authority" to be used in this RFC. > > I think they can be separate entities. An administrator takes direction > from an authority. How does this sound: > > Holders of E.164 numbers which want to be listed in DNS > should contact the administrator or authority for the zone (authority > meaning simply the entity that has change control over that zone, > nothing more) in order to be listed. This information can be found by > examining the SOA resource record associated with the zone, just like > in > normal DNS operations. There might be more than two entities. From my point of view, there is "one authority" for a DNS zone. Who the registrant is to contact is up to the policy which is attached to the zone. For example one of the registrars. So, I would prefer something like the following: Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations. >> 5. In 2.1 Application .... The word "telephone numbers" is used that >> not are >> part of the E.164 namespace - this is also unclear - please see our >> comments >> above about "non-E.164-numbers" - please clarify. > > Why is it unclear? There are numbers I can dial on a telephone that are > not E.164 numbers? Correct? Either a number is or is not an E.164 > number? Or am I missing something fundamental? I think Joakim might want the term "dialing plan" here somewhere. We once again is caught by the dialing plan / number plan issues. I feel we have several things here (without proper names): - Dialed number (what the usre dials on the phone) - Syntactically correct E.164 number (max 15 digits etc) - E.164 number correct according to E.164 and local national number plans - E.164 number allocated to an end user - Numbers which looks like E.164, but, is only valid on national level (various 800-version for example) - Numbers which are just part of the national dialing plan (112/911 etc) ...and of course the negations of the above. >> 8. In 5. IANA Considerations - it should be "ITU-T Recommendation >> E.164" - >> not just ITU Rec... And also change ITU-T TSB to just "ITU TSB". In >> general >> the text under 5 looks OK for the relationship to the ITU TSB >> concerning >> delegations for .e164.arpa. Maybe the second sentence in the first >> paragraph could look as: "Names within this zone are to be delegated >> to >> assignes that has been assigned numbering resources according to the >> ITU-T >> Recommendation E.164." > > Since I didn't write this section I'm going to differ to Patrik on > these > wording changes. Patrik? The paragraph has been agreed upon between IAB and ITU-T and TSB and RIPE NCC. I need to take this proposed change back. Interesting that noone else "complained". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum