From richard@shockey.us Fri, 01 Oct 2004 12:42:53 -0400 From: Richard Shockey Date: Fri, 01 Oct 2004 12:42:53 -0400 To: enum at ietf.org Subject: [Enum] FYI - ENUM in Germany Message-ID: <6.1.0.6.2.20041001113753.0449d190@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R 28.09.2004 ENUM Gaining Momentum DENIC Organizes Third ENUM Day with Focus on Security In the context of the ongoing ENUM trial in Germany, DENIC, the registry in charge, organized its third ENUM Day on 28 September 2004. ENUM is a new technology which bridges the gap between the worlds of telecommunications and the Internet. ENUM and the ENUM services provide users with access to the whole communications universe through established telephone numbers. Some 140 experts, including many DENIC members already offering ENUM domains, telecommunication-services providers and academics, discussed the progress that ENUM had made in Germany in the preceding months. Since the second ENUM Day in March 2004, the number of providers handling the registration of ENUM domains had more than doubled. Users can now choose from 43 providers in Germany. Even stronger - 227% - had been the increase recorded for the number of ENUM domains (up from 260 to 850). These figures might appear only marginal given the large number of telephone connections. However, with a single ENUM domain, it is possible to operate whole telephone installations, including several hundreds and even thousands of lines, which means that the number of ENUM users is significantly greater than the number of domains. Two of the crucial subjects discussed in the course of the ENUM Day were security and concepts for dealing with SPAM in the field of Internet telephony (also known as "SPIT"). In each of these cases, there are issues of authentication (i.e. verification that the sender indicated and the true sender are identical) and protection against data espionage and data corruption. The speakers presented various models for future solution strategies. Professor Andreas Steffen of the Zurich University of Applied Sciences in Winterthur, for instance, spoke about tackling security matters at the technical protocol level of the ENUM standard. John-Erik Horn presented his ideas for a nationwide telephone network for Germany that would use only the Internet and that would route all its calls using ENUM. Not all speakers approached ENUM in terms of its technical potential. Dr. Volker Leib, a social scientist from the Nexus Institute in Berlin, rates the Internet, voice-over-IP and ENUM as highly significant innovations, which are going to lead to fundamental structural changes; indeed, he believes that some such changes have already occurred and foresees massive shifts in the technological basis of telephony in the coming years. He reported that telecommunications giants, such as Deutsche Telekom and British Telecom, are already working on the assumption of the existing network being closed down within a period of 5-10 years to be replaced by a new IP network based on Internet technology. Despite that, the current telephone numbers will remain in use, as will the more than two billion telephone connections existing worldwide. Leib went on to appeal for a forward-looking innovation policy to provide the general environment for future developments and to ensure legal and planning certainty for the companies involved. Market access must also be made easier for suppliers of voice-over-IP services. Leib finished by stressing the tremendous importance of working for an early launch of commercial ENUM operations and for ensuring an uncomplicated transition from the current trial phase to the "live" phase. The presentations and the accompanying notes are made available at the DENIC web-site. Background to ENUM The term ENUM is derived from telephone number mapping. It is a protocol defining how to link together resources from the telecommunications and Internet spheres. It sets out a rule by means of which a telephone number can be uniquely mapped to a domain. This domain can then be used for the identification of various communication services, such as telefaxes, cell phones, voice-mail systems, e-mail addresses, IP-telephony addresses, web pages or call diverts. The idea behind ENUM is simple yet ingenious. Instead of having to grapple with lots of different numbers and addresses for private, office and mobile phones as well as telefax, e-mail and websites, which demand a really big effort just to keep them up-to-date, it is going to be possible in future to enter just one single number per person in our address books. Making sure that each communication is routed to the appropriate output device is then going to be handled by the entries in the ENUM name server. The linking of telephone numbers and Internet resources is leading to the creation of totally new services. One basic service is finding an Internet terminal with telephony capability from a conventional telephone. As an option, it is possible with ENUM to draw callers attention to alternative communication channels that are actually available. If no Internet device with telephony capability is available, the caller will be able to select an appropriate alternative from the list of additional applications presented. Further general information about ENUM and specific information about the trial operation at DENIC are available on DENICs website. Copyright DENIC eG 2004. Reprint permitted, author's copy requested. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Fri, 01 Oct 2004 18:26:05 -0400 From: Andrew Newton Date: Fri, 01 Oct 2004 18:26:05 -0400 To: Richard Shockey Subject: Re: [Enum] Its that time again .. IETF 61 is coming. In-Reply-To: <6.1.0.6.2.20040924141649.040eb1a0@joy.songbird.com> Message-ID: <382740FD-13F2-11D9-A95B-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain Status: R On Sep 24, 2004, at 2:18 PM, Richard Shockey wrote: The chairs would like to get a sense of what new documents we should be prepared for and what topics of discussion the WG needs to cover. Richard, I'd like time to talk about draft-newton-iris-ereg-02.txt. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sat, 02 Oct 2004 12:17:26 -0400 From: Richard Shockey Date: Sat, 02 Oct 2004 12:17:26 -0400 To: Andrew Newton Subject: Re: [Enum] Its that time again .. IETF 61 is coming. In-Reply-To: <6.1.0.6.2.20040924141649.040eb1a0@joy.songbird.com> Message-ID: <6.1.0.6.2.20041002120050.0416d980@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 05:38 PM 10/1/2004, Andrew Newton wrote: On Sep 24, 2004, at 2:18 PM, Richard Shockey wrote: The chairs would like to get a sense of what new documents we should be prepared for and what topics of discussion the WG needs to cover. Richard, I'd like time to talk about draft-newton-iris-ereg-02.txt. done ... I think the timing is very good to revisit the WHOIS / ENUM directory requirements here. This is part of the whole ENUM service provisioning suite we have a charter to look at beginning with EPP for E164. We have a significant number of global deployments and I'm sure at some point National Regulatory Authorities are going to want to see the technologies that can create those directories. -andy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Thu, 07 Oct 2004 17:48:56 -0400 From: Michael Haberler Date: Thu, 07 Oct 2004 17:48:56 -0400 To: enum at ietf.org Subject: [Enum] New I/D: ENUM Validation Architecture and Token Format Definition Message-ID: <6.1.2.0.2.20041007232301.087bc2c0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R hello, We're submitting a new I/D: draft-mayrhofer-enum-validation-00.txt Abstract: ENUM domains track the right-to-use of the underlying E.164 number. The process of asserting this is called "validation". This document describes a generalized role model and a XML data format -- the validation token -- to convey validation related information. Until it appears in the archives, you can download it from the following URLs: * http://www.enum.at/ietf/draft-mayrhofer-enum-validation-00.html * http://www.enum.at/ietf/draft-mayrhofer-enum-validation-00.txt We'd be interested in comments and suggestions, in particular the fit of our model in your enviroments. regards Michael Haberler Internet Foundation Austria _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Oct 2004 19:21:01 -0400 From: Richard Shockey Date: Thu, 07 Oct 2004 19:21:01 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-stastny-iptel-tel-enumdi-00.txt Message-ID: <6.1.0.6.2.20041007190430.05421a10@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Mssrs Stastny, Conroy and myself are submitting this draft to IPTEL for due consideration. IPTEL will not be meeting ( as I understand it ) so without objection we will invite any of the IPTEL folks interested in this draft to join us at the ENUM WG meeting for a discussion of this. To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Thu, 07 Oct 2004 15:34:30 -0400 Subject: I-D ACTION:draft-stastny-iptel-tel-enumdi-00.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : New parameter for the "tel" URI to support ENUM Author(s) : R. Stastny, et al. Filename : draft-stastny-iptel-tel-enumdi-00.txt Pages : 0 Date : 2004-10-7 This document defines a new parameter "enumdi" in the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in SIP proxies, H.323 gatekeepers and other VoIP network elements. The presence of the "enumdi" parameter indicates to the VoIP network element receiving an URI containing an E.164 number that an ENUM query as defined in RFC3761 has already been performed on the E.164 number indicated by the previous VoIP network element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stastny-iptel-tel-enumdi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-7155318.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 08 Oct 2004 20:35:44 -0400 From: Richard Shockey Date: Fri, 08 Oct 2004 20:35:44 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-mayrhofer-enum-validation-00.txt Message-ID: <6.1.0.6.2.20041008201116.049f3d70@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Fri, 08 Oct 2004 15:39:02 -0400 Subject: I-D ACTION:draft-mayrhofer-enum-validation-00.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Validation Architecture and Token Format Definition Author(s) : A. Mayrhofer, et al. Filename : draft-mayrhofer-enum-validation-00.txt Pages : 17 Date : 2004-10-8 ENUM domains track the right-to-use of the underlying E.164 number. The process of asserting this is called "validation". This document describes a generalized role model and a XML data format -- the validation token -- to convey validation related information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mayrhofer-enum-validation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-mayrhofer-enum-validation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-8160059.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-mayrhofer-enum-validation-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 12 Oct 2004 16:39:02 -0400 From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 16:39:02 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt Message-ID: <200410122009.QAA28168@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-void-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-void-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 14 Oct 2004 05:30:09 -0400 From: Richard Shockey Date: Thu, 14 Oct 2004 05:30:09 -0400 To: enum at ietf.org Subject: [Enum] Proposed Agenda ENUM WG IETF 61 Message-ID: <6.1.0.6.2.20041001102750.04538eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R This is what I have so far.... any addtitions? Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) MONDAY, November 8, 2004 1730-1930 Break 1930-2200 Evening Sessions RTG rtgarea Routing Area Meeting * SEC msec Multicast Security WG TSV enum Telephone Number Mapping WG TSV rddp Remote Direct Data Placement WG 1. The ENUM dip indicator ( with ITPEL ) ???? This is coming. It is a draft that discusses the use of a ENUM dip indicatior in the TEL URL that indicates that a ENUM query has been done . 2. Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt 3. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt 4. "Conveying number properties with a Validation Token" Coming from Michael Haberler Ongoing work. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 14 Oct 2004 05:30:09 -0400 From: Richard Shockey Date: Thu, 14 Oct 2004 05:30:09 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-ietf-dnsext-wcard-clarify-03.txt Message-ID: <6.1.0.6.2.20041014052142.04261570@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I forward this since one and a while I see discussions of the use of Wild Cards in ENUM ... To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 11 Oct 2004 15:38:19 -0400 Cc: namedroppers at ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-03.txt X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-03.txt Pages : 18 Date : 2004-10-11 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-11155131.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Thu, 14 Oct 2004 07:25:18 -0400 From: "Klaus Darilion" Date: Thu, 14 Oct 2004 07:25:18 -0400 To: Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt Message-ID: <8BC845943058D844ABFC73D2220D466585E3C8@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi! Is there a proposed way how an ENUM client should handle ambiguous situations, e.g: 3.8.0 NAPTR 10 100 "u" "E2U+void:mailto" "!^.*$!mailto:num-drama-info at nra.foo!" 3.8.0 NAPTR 10 100 "u" "E2U+voice:sip" "!^.*$!sip:12345 at fwd.foo!" I'm pretty sure this will happen if customers will manage their NAPTRs themselves. regards, klaus > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Internet-Drafts at ietf.org > Sent: Tuesday, October 12, 2004 10:10 PM > To: i-d-announce at ietf.org > Cc: enum at ietf.org > Subject: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping > Working Group of the IETF. > > Title : IANA Registration for Enumservice VOID > Author(s) : R. Stastny, L. Conroy > Filename : draft-ietf-enum-void-00.txt > Pages : 0 > Date : 2004-10-12 > > This document registers the Enumservice 'void' using the URI schemes > 'mailto:' and 'http:' as per the IANA registration process defined > in the ENUM specification, RFC3761. This Enumservice may be used to > indicate that the E.164 number (or E.164 number range) tied to the > domain in which the enclosing NAPTR is published is not > assigned for > communications service. When such an indication is > provided, an ENUM > client can detect calls that will fail "early". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request at ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-enum-void-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-void-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 14 Oct 2004 08:11:26 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 14 Oct 2004 08:11:26 -0400 To: Klaus Darilion Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt In-Reply-To: <8BC845943058D844ABFC73D2220D466585E3C8@nics-mail.sbg.nic.at> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Klaus, folks, Strictly, this example is invalid, as the priorities and ORDER field values are the same. In this situation, it is a client's choice whether they reject the NAPTRs or just choose a random order/priority for them. However, whilst having a 'e2u+void:mailto' NAPTR (or e2u+void:http) with any non-void NAPTR is pretty strange as VOID implies that the number is not in service, it's not possible to stop people doing stupid things. Thus how should a client react? As the client SHOULD be processing these in order/priority sort, in theory "the lowest one wins". However... In practice I would HOPE that a void NAPTR would be handled first (i.e. at the same time that the NAPTRs are being sorted/pre-discarded/...) - that's what our client is going to do. If the client 'sees' a void NAPTR, it gives up at that point on the current ENUM domain. (Note that, if the domain was entered as a result of a non-final NAPTR reference, then I guess you would just ignore that domain rather than abort the whole query). hth, Lawrence On 14 Oct 2004, at 12:18, Klaus Darilion wrote: Hi! Is there a proposed way how an ENUM client should handle ambiguous situations, e.g: 3.8.0 NAPTR 10 100 "u" "E2U+void:mailto" "!^.*$!mailto:num-drama-info at nra.foo!" 3.8.0 NAPTR 10 100 "u" "E2U+voice:sip" "!^.*$!sip:12345 at fwd.foo!" I'm pretty sure this will happen if customers will manage their NAPTRs themselves. regards, klaus -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Tuesday, October 12, 2004 10:10 PM To: i-d-announce at ietf.org Cc: enum at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-void-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-void-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Thu, 14 Oct 2004 08:41:39 -0400 From: "Klaus Darilion" Date: Thu, 14 Oct 2004 08:41:39 -0400 To: "Conroy, Lawrence \(SMTP\)" Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt Message-ID: <8BC845943058D844ABFC73D2220D466585E3C9@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi! > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] > Hi Klaus, folks, > Strictly, this example is invalid, as the priorities and > ORDER field values are the same. > In this situation, it is a client's choice whether they > reject the NAPTRs or just choose a random order/priority for them. Sorry for my ignorance, but where is it defined that NAPTRs with the same order and priority field are invalid? Although the example in RFC 3403 on Page 8 has same order/priority. regards, klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 14 Oct 2004 12:25:54 -0400 From: "Stastny Richard" Date: Thu, 14 Oct 2004 12:25:54 -0400 To: "Richard Shockey" Subject: RE: [Enum] Proposed Agenda ENUM WG IETF 61 Message-ID: <06CF906FE3998C4E944213062009F16244393A@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Just a minor addition: The I-D on the regarding agenda item 1. ENUM dip Indicator is available at: http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.tx t Richard Stastny > -----Original Message----- > From: Richard Shockey [mailto:richard at shockey.us] > Sent: Thursday, October 14, 2004 11:28 AM > To: enum at ietf.org > Subject: [Enum] Proposed Agenda ENUM WG IETF 61 > > > > This is what I have so far.... any addtitions? > > Chair(s): > Patrik Faltstrom > Richard Shockey > > Transport Area Advisor: > Allison Mankin > > Mailing Lists: > General Discussion:enum at ietf.org > To Subscribe: enum-request at ietf.org > In Body: subscribe > Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ > > > AGENDA BASHING (5 min) > > > > MONDAY, November 8, 2004 > > 1730-1930 Break > 1930-2200 Evening Sessions > RTG rtgarea Routing Area Meeting * > SEC msec Multicast Security WG > TSV enum Telephone Number Mapping WG > TSV rddp Remote Direct Data Placement WG > > > > 1. The ENUM dip indicator ( with ITPEL ) ???? This is > coming. It is a > draft that discusses the use of a ENUM dip indicatior in the > TEL URL that > indicates that a ENUM query has been done . > > > 2. Title : An ENUM Registry Type for the > Internet Registry > Information Service > Author(s) : A. Newton > Filename : draft-newton-iris-ereg-02.txt > Pages : 45 > Date : 2004-9-28 > > This document describes an IRIS > (draft-ietf-crisp-iris-core-02.txt ) > registry schema for ENUM administrative information. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt > > > > > 3. Title : ENUM Validation Information Mapping for the > Extensible Provisioning Protocol > Author(s) : B. Hoeneisen > Filename : draft-hoeneisen-enum-validation-epp-00.txt > Pages : 17 > Date : 2004-9-30 > > This document describes an EPP extension for mapping information > about the validation process the ENUM Registrar has > applied for the > E.164 number (or number range), which the ENUM domain > name is based > on. Specified in XML, this mapping extends the EPP domain name > mapping to provide an additional feature required for the > provisioning of E.164 numbers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-valid > ation-epp-00.txt > > > 4. "Conveying number properties with a Validation Token" Coming from > Michael Haberler > > > Ongoing work. > > Title : IANA Registration for Enumservice VOID > Author(s) : R. Stastny, L. Conroy > Filename : draft-ietf-enum-void-00.txt > Pages : 0 > Date : 2004-10-12 > > This document registers the Enumservice 'void' using the URI schemes > 'mailto:' and 'http:' as per the IANA registration process defined > in the ENUM specification, RFC3761. This Enumservice may > be used to > indicate that the E.164 number (or E.164 number range) tied to the > domain in which the enclosing NAPTR is published is not > assigned for > communications service. When such an indication is > provided, an ENUM > client can detect calls that will fail "early". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology > Initiatives NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, > Fax: +1 815.333.1237 or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 14 Oct 2004 12:28:20 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 14 Oct 2004 12:28:20 -0400 To: Klaus Darilion Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt In-Reply-To: <8BC845943058D844ABFC73D2220D466585E3C9@nics-mail.sbg.nic.at> Message-ID: <655B700E-1DFD-11D9-9341-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Klaus, First rule of the RFC - never ever trust examples. Ever. Read the normative sections of the document. Any examples MIGHT help to clarify the text, but the text wins over the examples every time. From paf@cisco.com Wed, 20 Oct 2004 08:57:51 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 20 Oct 2004 08:57:51 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-00.txt In-Reply-To: <8BC845943058D844ABFC73D2220D466585E3C9@nics-mail.sbg.nic.at> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 14, 2004, at 18:23, Conroy, Lawrence (SMTP) wrote: If you put NAPTRs with identical ORDER and PREFERENCE/Priority values in a zone, then are these or are these not identical? From the DDDS perspective, they are and the choice of which is the "real one" is indeterminate. As the creator of the examples in the RFC, let me explain my thinking (that might still be weird according to the majority on this list of course): The order/preference field on the NAPTR RR's set a prefered order in which I as the owner of the E.164 want to be contacted. This imply a policy is published. The client looking up the NAPTR get this policy, but, we are not done yet. The client have a policy as well that might include for example a list with priorities SIP, Email etc should be tried. If nothing else it can be based on cost (real $$). So, the order in what the records will be used is a mix between the policy published by the owner of the E.164 (the order/preference in the NAPTR) and the policy the client have. When I then added an example of the same order/preference in the RFC that was to say only "it doesn't matter in what order you try these records". Because the policy the owner of the records state exists is neutral, the policy the client have implemented will be what rules. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Robert.Shaw@itu.int Thu, 21 Oct 2004 07:16:24 -0400 From: Robert.Shaw@itu.int Date: Thu, 21 Oct 2004 07:16:24 -0400 To: enum at ietf.org Subject: [Enum] Request for assistance from list members... Message-ID: <2ECA12DF5FCB7948A1CD9047C3DAF3DC0522C4@MAILBOX1.blue.itu.ch> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear ENUM list members, At the beginning of November I will be speaking at an African regulators meeting in Kampala. My session will discuss ENUM as well as the status of implementation in various ITU Member States (although I will also note that an increasing number of MS appear to be allocating VoIP-specific numbering resources). If members of this list could point me by private mail to resources about the current status of ENUM in their national context, this would greatly assist me in preparation of my presentations and would be very appreciated. Recent ppt presentations on these national implementations would also be greatly appreciated. Thanks in advance, Robert Shaw -- Robert Shaw ITU Internet Strategy and Policy Advisor Strategy and Policy Unit _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 21 Oct 2004 12:26:12 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 21 Oct 2004 12:26:12 -0400 To: "'enum at ietf.org> Subject: [Enum] FYI - another topic for the experiences draft Message-ID: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, Now it has been processed/announced, I want to give everyone notice about a topic we'll be adding to the update of the experiences draft - the thorny issue of Authoritative DNS servers (also known, in some circles, as T2 servers) and the *need* for TCP and EDNSO support. In short, we believe that Authoritative servers for ENUM domains SHOULD support EDNSO and SHOULD support TCP queries. I an interested in the group's feeling on whether or not this SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD in the basic specs, but is ENUM a special case where this can be stronger? - also, of course, TCP DNS queries SHOULD NOT be filtered by your friendly I.T. Department, if the Authoritative servers are hosted by a Company, or else name server support for TCP queries is pointless - I find a baseball bat helps. (From experience, firewall config is the biggest nuisance, and real fun to debug). My esteemed co-author Fujiwara-san has a draft that details this issue, so please look at this - it is concerned with large RRsets, and even without DNSSEC, we are likely to have those in the real world in ENUM (a couple of Austrian zones come to mind :). see all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Thu, 21 Oct 2004 14:33:22 -0400 From: Adrian Georgescu Date: Thu, 21 Oct 2004 14:33:22 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <6EFF225C-238D-11D9-BBDF-000A95C7765A@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Next to PTR examples given, 4-5 NAPTR records can already fill up the maximum packet size via UDP. TCP is a valid transport option but some performance requirements I have seen demanded from ENUM servers must be reviewed and the providers must take provision to be able to take the load of more expensive TCP connections, it has the same impact of operating a SIP server on TCP, performance decreases dramatically. I am wondering if anyone knows the performance ratio of UDP/TCP transport on a DNS server. On Oct 21, 2004, at 6:16 PM, Conroy, Lawrence (SMTP) wrote: Hi Folks, Now it has been processed/announced, I want to give everyone notice about a topic we'll be adding to the update of the experiences draft - the thorny issue of Authoritative DNS servers (also known, in some circles, as T2 servers) and the *need* for TCP and EDNSO support. In short, we believe that Authoritative servers for ENUM domains SHOULD support EDNSO and SHOULD support TCP queries. I an interested in the group's feeling on whether or not this SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD in the basic specs, but is ENUM a special case where this can be stronger? - also, of course, TCP DNS queries SHOULD NOT be filtered by your friendly I.T. Department, if the Authoritative servers are hosted by a Company, or else name server support for TCP queries is pointless - I find a baseball bat helps. (From experience, firewall config is the biggest nuisance, and real fun to debug). My esteemed co-author Fujiwara-san has a draft that details this issue, so please look at this - it is concerned with large RRsets, and even without DNSSEC, we are likely to have those in the real world in ENUM (a couple of Austrian zones come to mind :). see all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 21 Oct 2004 15:18:58 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 21 Oct 2004 15:18:58 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <7B918E8E-2394-11D9-9D24-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 21, 2004, at 18:16, Conroy, Lawrence (SMTP) wrote: Hi Folks, Now it has been processed/announced, I want to give everyone notice about a topic we'll be adding to the update of the experiences draft - the thorny issue of Authoritative DNS servers (also known, in some circles, as T2 servers) and the *need* for TCP and EDNSO support. In short, we believe that Authoritative servers for ENUM domains SHOULD support EDNSO and SHOULD support TCP queries. Well, DNS servers MUST support TCP and SHOULD support EDNS0. The latter because packet size might be larger than 512 bytes, and for use of DNSSEC use of EDNS0 is a MUST. For these reasons I am nervous the ENUM wg working on these DNS deployment issues. This is a DNSOP issue, and the question -- if it has to be answered -- should be passed over the fence. Maybe it is the case that we (ENUM people) have discovered there is no "BCP on DNS deployment", and that is something we should ask DNS people to create? Or at least look at what we have? The baseball bat issue below, I agree with ;-) paf I an interested in the group's feeling on whether or not this SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD in the basic specs, but is ENUM a special case where this can be stronger? - also, of course, TCP DNS queries SHOULD NOT be filtered by your friendly I.T. Department, if the Authoritative servers are hosted by a Company, or else name server support for TCP queries is pointless - I find a baseball bat helps. (From experience, firewall config is the biggest nuisance, and real fun to debug). My esteemed co-author Fujiwara-san has a draft that details this issue, so please look at this - it is concerned with large RRsets, and even without DNSSEC, we are likely to have those in the real world in ENUM (a couple of Austrian zones come to mind :). see all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Thu, 21 Oct 2004 18:06:59 -0400 From: "Conroy, Lawrence (SMTP)" Date: Thu, 21 Oct 2004 18:06:59 -0400 To: Patrik Fältström Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Patrik, folks, Sorry if I was unclear. I'm very happy with MUST for Authoritative Name Server TCP support, and a SHOULD for EDNSO (at least "before DNSSEC"). I'm glad it's not just me - I'm also unaware of a BCP for DNS Deployment. That is NOT the job of the ENUM experiences draft - Fujiwara-san's draft *is* intended for the dnsop WG. As this will "bite" for ENUM deployments, I suggest ONLY that we highlight that folk need to set their servers (and clients) correctly, as otherwise they will have problems. Summarising the "rules" and the kind of problems they will have if they (or their I.T. department) don't do the right thing seems to me appropriate for an ENUM doc. For the gory details we will have a reference to Fujiwara-san's dnsop draft precisely as that's where it is treated (please, please, please not in ENUM). Unless I get some strong objections before the weekend I'll add it to the updated experiences (-01) draft and with luck, this will be accepted by the deadline. all the best, Lawrence On 21 Oct 2004, at 20:07, Patrik Fältström wrote: On Oct 21, 2004, at 18:16, Conroy, Lawrence (SMTP) wrote: Hi Folks, Now it has been processed/announced, I want to give everyone notice about a topic we'll be adding to the update of the experiences draft - the thorny issue of Authoritative DNS servers (also known, in some circles, as T2 servers) and the *need* for TCP and EDNSO support. In short, we believe that Authoritative servers for ENUM domains SHOULD support EDNSO and SHOULD support TCP queries. Well, DNS servers MUST support TCP and SHOULD support EDNS0. The latter because packet size might be larger than 512 bytes, and for use of DNSSEC use of EDNS0 is a MUST. For these reasons I am nervous the ENUM wg working on these DNS deployment issues. This is a DNSOP issue, and the question -- if it has to be answered -- should be passed over the fence. Maybe it is the case that we (ENUM people) have discovered there is no "BCP on DNS deployment", and that is something we should ask DNS people to create? Or at least look at what we have? The baseball bat issue below, I agree with ;-) paf I an interested in the group's feeling on whether or not this SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD in the basic specs, but is ENUM a special case where this can be stronger? - also, of course, TCP DNS queries SHOULD NOT be filtered by your friendly I.T. Department, if the Authoritative servers are hosted by a Company, or else name server support for TCP queries is pointless - I find a baseball bat helps. (From experience, firewall config is the biggest nuisance, and real fun to debug). My esteemed co-author Fujiwara-san has a draft that details this issue, so please look at this - it is concerned with large RRsets, and even without DNSSEC, we are likely to have those in the real world in ENUM (a couple of Austrian zones come to mind :). see all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Thu, 21 Oct 2004 18:10:08 -0400 From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 18:10:08 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-03.txt Message-ID: <200410212002.QAA14414@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-03.txt Pages : 20 Date : 2004-10-21 This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-msg-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-msg-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 21 Oct 2004 18:11:24 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 21 Oct 2004 18:11:24 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <8758173A-239E-11D9-9D24-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote: Unless I get some strong objections before the weekend I'll add it to the updated experiences (-01) draft and with luck, this will be accepted by the deadline. Please do! paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Fri, 22 Oct 2004 03:39:54 -0400 From: Adrian Georgescu Date: Fri, 22 Oct 2004 03:39:54 -0400 To: Stastny Richard Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R There is a discrepancy between previous document and ETSI TS 102 172 recommendation regarding the default value of naptr order field. Could a unique value be agreed upon? ETSI doc (order=10) Conroy experiences draft (order=100) Adrian On Oct 21, 2004, at 10:19 PM, Patrik Fältström wrote: On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote: Unless I get some strong objections before the weekend I'll add it to the updated experiences (-01) draft and with luck, this will be accepted by the deadline. Please do! paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 22 Oct 2004 06:59:06 -0400 From: Jim Reid Date: Fri, 22 Oct 2004 06:59:06 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <27426.1098442542@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "lwc" == Conroy, Lawrence (SMTP) writes: lwc> Hi Folks, Now it has been processed/announced, I want to give lwc> everyone notice about a topic we'll be adding to the update lwc> of the experiences draft - the thorny issue of Authoritative lwc> DNS servers (also known, in some circles, as T2 servers) and lwc> the *need* for TCP and EDNSO support. lwc> In short, we believe that Authoritative servers for ENUM lwc> domains SHOULD support EDNSO and SHOULD support TCP queries. lwc> I an interested in the group's feeling on whether or not this lwc> SHOULD -> MUST, for the specific case of ENUM - it's a SHOULD lwc> in the basic specs, but is ENUM a special case where this can lwc> be stronger? Support for EDNS0 should be a MUST. Here's some suggested text to explain why. Responses to ENUM lookups are likely to contain many NAPTR records and could well exceed the 512-byte payload limit on UDP responses defined in RFC1035. If these replies are also signed using Secure DNS, they will be considerably larger than 512 bytes. When this limit is exceeded, the server truncates the response and sets the TC bit in the reply. The client then repeats the query using TCP so that all the data can be obtained. This is undesirable for two reasons. Firstly, there is the overhead and additional latency of creating a TCP connection and repeating the query. Those delays are not conducive to environments like ENUM where high query throughput is necessary. The second reason is large numbers of TCP queries can place undue load on the server's operating system because it may have to maintain state information for many hundreds or thousands of short-lived TCP connections. When a resolver uses EDNS0, it can inform the name server that it is able to receive more than 512 bytes in a UDP response. Therefore ENUM clients SHOULD use EDNS0 when making queries to avoid the potential delays and undesirable overheads caused by truncated responses followed by repeated queries over TCP. Clients making queries with EDNS0 should indicate that they can accept appropriately large enough UDP responses: perhaps as much as 4096 bytes. Authoritative name servers for ENUM zones MUST support EDNS0. BTW, stating that name servers SHOULD support TCP is a bit like saying they SHOULD support RFC1035. :-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 22 Oct 2004 07:33:53 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 22 Oct 2004 07:33:53 -0400 To: Adrian Georgescu Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <8A511A21-241D-11D9-9978-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 22, 2004, at 09:34, Adrian Georgescu wrote: There is a discrepancy between previous document and ETSI TS 102 172 recommendation regarding the default value of naptr order field. Could a unique value be agreed upon? ETSI doc (order=10) Conroy experiences draft (order=100) The order value has no meaning, so there is no need for a default value. I.e. why do you ask? paf Adrian On Oct 21, 2004, at 10:19 PM, Patrik Fältström wrote: On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote: Unless I get some strong objections before the weekend I'll add it to the updated experiences (-01) draft and with luck, this will be accepted by the deadline. Please do! paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 22 Oct 2004 07:33:54 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 22 Oct 2004 07:33:54 -0400 To: Jim Reid Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <27426.1098442542@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 22, 2004, at 12:55, Jim Reid wrote: Support for EDNS0 should be a MUST. Here's some suggested text to explain why. I don't see how we can say MUST on EDNS0 if not all nameservers (including all recursive resolvers) do support it. I do see the need for a MUST regarding TCP, because that is what is in 1034/1035, but EDNS0? Has the DNSOP wg decided support of EDNS0 is a MUST for DNS? We all know EDNS0 is a MUST if the packet size is larger than 512 bytes, and the truncated data is something that "is needed" (whatever that is, it is still to be defined), but... paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Fri, 22 Oct 2004 08:21:16 -0400 From: "Conroy, Lawrence (SMTP)" Date: Fri, 22 Oct 2004 08:21:16 -0400 To: Patrik Fältström Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <67B050E4-2424-11D9-9D57-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Patrik, folks, It can be hard to decode RFC3403 and RFC3761 section 1.3, so I'm in favour of giving people a hint in plain text that "The order value has no meaning" :). Telling everyone to use the same ORDER field value within a given zone is a good solution. It's also true that using a different ORDER field value in different zones is unimportant for most queries. However... If anyone really wants the joy of implementing non-final NAPTRs, then they MAY be confused by section 1.3 - if there's a different (lower) order field value in a zone referred to by a non-final, then does this mean that one discards the other NAPTRs in the referring zone. Conversely, if the zone referred to by a non-final NAPTR contains entries that have a higher ORDER field value, then does one ignore those? My guess is that one just "forgets to consider" the order field value in NAPTRs that are scanned as the result of a non-final NAPTR zone reference, and that's what we propose in the experiences draft. It's possible to interpret RFC3761 ss 1.3 differently, which means that someone somewhere has/is/will read/is reading/will read it that way. Thus using the same ORDER field value for ALL zones is "a good idea" - it avoids arguments over the meaning of 3403 and 3761 ss 1.3, so removing the need for a philosophy higher degree before implementing this stuff. The short answer is "I vote we propose 100", for those obscure corner cases where it matters. all the best, Lawrence On 22 Oct 2004, at 12:28, Patrik Fältström wrote: On Oct 22, 2004, at 09:34, Adrian Georgescu wrote: There is a discrepancy between previous document and ETSI TS 102 172 recommendation regarding the default value of naptr order field. Could a unique value be agreed upon? ETSI doc (order=10) Conroy experiences draft (order=100) The order value has no meaning, so there is no need for a default value. I.e. why do you ask? paf Adrian On Oct 21, 2004, at 10:19 PM, Patrik Fältström wrote: On Oct 21, 2004, at 21:52, Conroy, Lawrence (SMTP) wrote: Unless I get some strong objections before the weekend I'll add it to the updated experiences (-01) draft and with luck, this will be accepted by the deadline. Please do! paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Fri, 22 Oct 2004 11:30:44 -0400 From: "Klaus Darilion" Date: Fri, 22 Oct 2004 11:30:44 -0400 To: "Conroy, Lawrence \(SMTP\)" Subject: RE: [Enum] FYI - another topic for the experiences draft Message-ID: <8BC845943058D844ABFC73D2220D4665367F0C@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi! I'm glad that you discuss this topic as this is really a big problem in the ENUM world. If someone wants to benefit from enum and configures all the nice services (fax, voice, http, sms, mms,..), the 512 bytes limit is reached easily. Therefore, at least one method (TCP or EDNS0) must be supported for ENUM. As Jim said EDNSO will benefit from smaller overhead. But the main problem is not the standard ('should' or 'must'), but the administrators of the name servers (authoritive and chaching servers). I don't know if TCP is a should or a must, but there are definitely a lot of name servers configured to block TCP. Anyway, using resolvers which are capable of both (EDNS0 and TCP) will increase the chance to get all NAPTRs for a domain. regards, klaus > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Conroy, Lawrence (SMTP) > Sent: Thursday, October 21, 2004 6:16 PM > To: 'enum at ietf.org' > Cc: fujiwara at jprs.co.jp > Subject: [Enum] FYI - another topic for the experiences draft > > Hi Folks, > Now it has been processed/announced, I want to give > everyone notice about a topic we'll be adding to the update > of the experiences draft > - the thorny issue of Authoritative DNS servers (also known, > in some circles, as T2 servers) and the *need* for TCP and > EDNSO support. > > In short, we believe that Authoritative servers for ENUM > domains SHOULD support EDNSO and SHOULD support TCP queries. > > I an interested in the group's feeling on whether or not this > SHOULD -> MUST, for the specific case of ENUM > - it's a SHOULD in the basic specs, but is ENUM a special > case where this can be stronger? > > - also, of course, TCP DNS queries SHOULD NOT be filtered by > your friendly I.T. Department, if the Authoritative servers > are hosted by a Company, or else name server support for TCP > queries is pointless - I find a baseball bat helps. > (From experience, firewall config is the biggest nuisance, > and real fun to debug). > > My esteemed co-author Fujiwara-san has a draft that details > this issue, so please look at this - it is concerned with > large RRsets, and even without DNSSEC, we are likely to have > those in the real world in ENUM (a couple of Austrian zones > come to mind :). > > see > dns-auth > -00.txt> > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From pk@TechFak.Uni-Bielefeld.DE Fri, 22 Oct 2004 12:41:00 -0400 From: Peter Koch Date: Fri, 22 Oct 2004 12:41:00 -0400 To: enum at ietf.org Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BC845943058D844ABFC73D2220D4665367F0C@nics-mail.sbg.nic.at> Message-ID: <200410221636.i9MGaAG24385@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: text/plain Status: R "Klaus Darilion" wrote: > is reached easily. Therefore, at least one method (TCP or EDNS0) must be > supported for ENUM. As Jim said EDNSO will benefit from smaller yes, but requiring this in the enum spec is kind of a layer violation. As Patrik already explained: you cannot control all the intermediate nameservers ('recursive servers', 'forwarders'). And, it's not the client that has to support EDNS0 but the resolver it uses. > But the main problem is not the standard ('should' or 'must'), but the > administrators of the name servers (authoritive and chaching servers). I > don't know if TCP is a should or a must, but there are definitely a lot > of name servers configured to block TCP. There are firewalls which let tcp/53 pass out but not back in. SYN succeeds, SYN/ACK gets dropped. Nice DoS, expect to suffer. > Anyway, using resolvers which are capable of both (EDNS0 and TCP) will > increase the chance to get all NAPTRs for a domain. TCP could turn out to be a performance problem (although this is currently discussed on namedroppers). -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Fri, 22 Oct 2004 17:11:17 -0400 From: Internet-Drafts@ietf.org Date: Fri, 22 Oct 2004 17:11:17 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-06.txt Message-ID: <200410222014.QAA06895@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-06.txt Pages : 17 Date : 2004-10-22 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-epp-e164-06.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Sun, 24 Oct 2004 11:34:48 -0400 From: Jim Reid Date: Sun, 24 Oct 2004 11:34:48 -0400 To: Patrik Fältström Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: Message-ID: <2072.1098631873@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: >> Support for EDNS0 should be a MUST. Here's some suggested text >> to explain why. paf> I don't see how we can say MUST on EDNS0 if not all paf> nameservers (including all recursive resolvers) do support it. By that argument, we shouldn't use NAPTR records either because not all DNS software supports them. ENUM was first documented in RFC2916 which came out in Sept 2000. EDNS0 predates it. RFC2671 was published in Aug 1999. So the chances are that a DNS implementation which doesn't support EDNS0 won't support NAPTR records either. paf> I do see the need for a MUST regarding TCP, because that is paf> what is in 1034/1035, but EDNS0? I would say EDNS0 is much more important than TCP for ENUM queries. Making TCP a MUST and not EDNS0 will send out the wrong message: ie that truncated responses and TCP retries are preferable to jumbogram UDP replies. This is very bad. It even worse because we already know that ENUM replies are likely to be bigger than 512 bytes even if they're not signed. So we should be taking protective measures like demanding the use of EDNS0 now to avoid the evils of truncated responses before these become a crippling operational problem. paf> Has the DNSOP wg decided support of EDNS0 is a MUST for DNS? Dunno. paf> We all know EDNS0 is a MUST if the packet size is larger than paf> 512 bytes, and the truncated data is something that "is paf> needed" (whatever that is, it is still to be defined), but... This seems to contradict what you just said. (ie Support for EDNS0 should be a SHOULD.) Real-world ENUM replies are almost certainly going to always exceed 512 bytes. So mandating EDNS0 now will save us a whole world of pain later. It'll be too late to make EDNS0 mandatory when everyone's ENUM name servers are dying because they are having to keep state about zillions of short-lived TCP connections caused by loadsaqueries that result in truncated responses. Since ENUM doesn't have much of an installed base yet, there shouldn't be a problem mandating that ENUM-aware applications support reasonably current DNS protocol features. There isn't an army of BIND4 servers hosting zones under e164.arpa or legacy applications that have to be considered. After all RFC3761 says software that implements ENUM MUST be prepared to handle standard signed responses. It even goes on to say they MUST be prepared to receive large responses, EDNS0 signaling, unknown RRs, etc. [Last para of 6.1] I read this as implying EDNS0 is already mandatory. As a compromise I could live with a doc for ENUM that said: stub resolvers SHOULD use EDNS0 resolving name servers MUST use EDNS0 for lookups in e164.arpa authoritative name servers MUST support EDNS0 TCP lookups under e164.arpa are strongly discouraged _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sun, 24 Oct 2004 12:09:39 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sun, 24 Oct 2004 12:09:39 -0400 To: Jim Reid Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <2072.1098631873@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Jim, folks, OK - I wasn't going to mention this, it isn't (and won't be) spelt out in the experiences draft I'm updating, and most importantly, IT'S OFF TOPIC for ENUM WG, but... AFAIK, EDNS0 only helps if the MTU is more than 512 octets (see the comment at the end of 2671 on ICMP storms for a hint). You can't guarantee that this is the case in all access networks. ===>>> Thus EDNS0 may not be the "Great White Hope" that folk assume it to be. <<<=== TCP queries do work. RFC1123 makes them a SHOULD for DNS servers. => That's what's going into the experiences update, only as a hint, as experiences is an INFORMATIONAL document. The Masters are still the DNSOPS docs. (BTW, RFC1123 also says that Clients SHOULD discard any partial response they receive, and RFC1035 makes TCP a MUST for AXFR, as UDP is excluded). With that, I leave you so I can get the fr*gg*n XML version sorted. all the best, Lawrence On 24 Oct 2004, at 16:31, Jim Reid wrote: "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: Support for EDNS0 should be a MUST. Here's some suggested text to explain why. paf> I don't see how we can say MUST on EDNS0 if not all paf> nameservers (including all recursive resolvers) do support it. By that argument, we shouldn't use NAPTR records either because not all DNS software supports them. ENUM was first documented in RFC2916 which came out in Sept 2000. EDNS0 predates it. RFC2671 was published in Aug 1999. So the chances are that a DNS implementation which doesn't support EDNS0 won't support NAPTR records either. paf> I do see the need for a MUST regarding TCP, because that is paf> what is in 1034/1035, but EDNS0? I would say EDNS0 is much more important than TCP for ENUM queries. Making TCP a MUST and not EDNS0 will send out the wrong message: ie that truncated responses and TCP retries are preferable to jumbogram UDP replies. This is very bad. It even worse because we already know that ENUM replies are likely to be bigger than 512 bytes even if they're not signed. So we should be taking protective measures like demanding the use of EDNS0 now to avoid the evils of truncated responses before these become a crippling operational problem. paf> Has the DNSOP wg decided support of EDNS0 is a MUST for DNS? Dunno. paf> We all know EDNS0 is a MUST if the packet size is larger than paf> 512 bytes, and the truncated data is something that "is paf> needed" (whatever that is, it is still to be defined), but... This seems to contradict what you just said. (ie Support for EDNS0 should be a SHOULD.) Real-world ENUM replies are almost certainly going to always exceed 512 bytes. So mandating EDNS0 now will save us a whole world of pain later. It'll be too late to make EDNS0 mandatory when everyone's ENUM name servers are dying because they are having to keep state about zillions of short-lived TCP connections caused by loadsaqueries that result in truncated responses. Since ENUM doesn't have much of an installed base yet, there shouldn't be a problem mandating that ENUM-aware applications support reasonably current DNS protocol features. There isn't an army of BIND4 servers hosting zones under e164.arpa or legacy applications that have to be considered. After all RFC3761 says software that implements ENUM MUST be prepared to handle standard signed responses. It even goes on to say they MUST be prepared to receive large responses, EDNS0 signaling, unknown RRs, etc. [Last para of 6.1] I read this as implying EDNS0 is already mandatory. As a compromise I could live with a doc for ENUM that said: stub resolvers SHOULD use EDNS0 resolving name servers MUST use EDNS0 for lookups in e164.arpa authoritative name servers MUST support EDNS0 TCP lookups under e164.arpa are strongly discouraged _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Sun, 24 Oct 2004 13:37:47 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sun, 24 Oct 2004 13:37:47 -0400 To: Jim Reid Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <2072.1098631873@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 24, 2004, at 17:31, Jim Reid wrote: "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: Support for EDNS0 should be a MUST. Here's some suggested text to explain why. paf> I don't see how we can say MUST on EDNS0 if not all paf> nameservers (including all recursive resolvers) do support it. By that argument, we shouldn't use NAPTR records either because not all DNS software supports them. ENUM was first documented in RFC2916 which came out in Sept 2000. EDNS0 predates it. RFC2671 was published in Aug 1999. So the chances are that a DNS implementation which doesn't support EDNS0 won't support NAPTR records either. My point is that a MUST is very very strong, and I ask whether requiring EDNS0 will make too many ENUM-capable nameservers no longer correct? paf> I do see the need for a MUST regarding TCP, because that is paf> what is in 1034/1035, but EDNS0? I would say EDNS0 is much more important than TCP for ENUM queries. Making TCP a MUST and not EDNS0 will send out the wrong message: ie that truncated responses and TCP retries are preferable to jumbogram UDP replies. TCP is already a MUST according to the DNS protocol, something EDNS0 is not. This is very bad. It even worse because we already know that ENUM replies are likely to be bigger than 512 bytes even if they're not signed. So we should be taking protective measures like demanding the use of EDNS0 now to avoid the evils of truncated responses before these become a crippling operational problem. paf> Has the DNSOP wg decided support of EDNS0 is a MUST for DNS? Dunno. Very important if they are. paf> We all know EDNS0 is a MUST if the packet size is larger than paf> 512 bytes, and the truncated data is something that "is paf> needed" (whatever that is, it is still to be defined), but... This seems to contradict what you just said. (ie Support for EDNS0 should be a SHOULD.) Real-world ENUM replies are almost certainly going to always exceed 512 bytes. No, they are not. My NAPTR things are not larger than 512. I did not contradict what I said. Read what I wrote. I said EDNS0 is needed if the response is larger than 512 bytes. So mandating EDNS0 now will save us a whole world of pain later. It'll be too late to make EDNS0 mandatory when everyone's ENUM name servers are dying because they are having to keep state about zillions of short-lived TCP connections caused by loadsaqueries that result in truncated responses. I want the DNSOP wg to state requirements on the DNS protocol. Not the ENUM wg. Since ENUM doesn't have much of an installed base yet, there shouldn't be a problem mandating that ENUM-aware applications support reasonably current DNS protocol features. That's not what we are discussing here. The question is whether EDNS0 is a MUST requirement for any DNS server holding NAPTR records for ENUM. I said that is a too strong requirement. There isn't an army of BIND4 servers hosting zones under e164.arpa or legacy applications that have to be considered. After all RFC3761 says software that implements ENUM MUST be prepared to handle standard signed responses. It even goes on to say they MUST be prepared to receive large responses, EDNS0 signaling, unknown RRs, etc. [Last para of 6.1] I read this as implying EDNS0 is already mandatory. No, the paragraph says: Finally, as an ENUM service will be implementing some type of security mechanism, software which implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, unknown RRs, etc. This is something completely different than requiring that a DNS server MUST implement it. It doesn't even say the ENUM service implementation MUST be able to understand DNSSEC signed responses. Only that it is prepared on getting such responses. Don't compare apples and pears. As a compromise I could live with a doc for ENUM that said: stub resolvers SHOULD use EDNS0 This is a DNSOP requirement. resolving name servers MUST use EDNS0 for lookups in e164.arpa This is a DNSOP requirement. authoritative name servers MUST support EDNS0 This is a DNSOP requirement. TCP lookups under e164.arpa are strongly discouraged I strongly oppose this. You are doing massive layering violations here Jim. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Mon, 25 Oct 2004 11:43:40 -0400 From: The IESG Date: Mon, 25 Oct 2004 11:43:40 -0400 To: IETF-Announce Subject: [Enum] Last Call: 'E.164 Number Mapping for the Extensible Provisioning Protocol' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'E.164 Number Mapping for the Extensible Provisioning Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2004-11-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Mon, 25 Oct 2004 16:31:33 -0400 From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:31:33 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-01.txt Message-ID: <200410252008.QAA00538@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-01.txt Pages : 26 Date : 2004-10-25 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-experiences-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Patrick.Guillemin@etsi.org Tue, 26 Oct 2004 06:06:44 -0400 From: =?Windows-1252?Q?Patrick_Ren=E9_Guillemin?= Date: Tue, 26 Oct 2004 06:06:44 -0400 To: "Plugtests" Subject: [Enum] ETSI Plugtests ENUM Call for Expert and extension of Task Force Message-ID: <4091553999CBE4409CC2B562152B5A330406FAAD@email10.etsihq.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear All, CALL FOR ONE ENUM INDEPENDENT EXPERT AND VOLUNTEERS TO CONTRIBUTE TO THE TASK FORCE TO SUPPORT THE 1ST ENUM INTEROPERABILITY EVENT (Spring 2005) The ETSI Plugtests Interoperability service, hosted the first ENUM Workshop event in February 2004 to serve the whole global market in cooperation with the ETSI TC TISPAN committee. The ETSI Plugtests service is independent and has, over the last 4 years, gained a unique experience in organising 50 events for a broad range of domains. Further information on the service is available at www.etsi.org/plugtests. While being part of the ETSI structure, this service is self-financed and fully independent. Half of the organized events are related to non ETSI Standards (e.g. IPv6, SIP, Bluetooth, etc). The ETSI Plugtests service is now preparing a 1st ENUM interoperability event to be held spring 2005 with the objective of having a broad technical scope to address ENUM technologies. Preliminary ENUM tests could be conducted during the 1st NGN Plugtests from 29-Nov to 3-Dec: http://www.etsi.org/plugtests/NGN_VoIP.htm To serve all the global ENUM solutions and all involved companies in an open, independent and transparent process, ETSI is looking for further assistance and support in two directions: 1) CALL FOR AN INDEPENDENT EXPERT ETSI Plugtests Service is looking for appointing an independent expert mainly to assist in the definition of the ENUM interoperability event, its architecture, its test bed and on the test cases to be performed. This expert will be under contractual arrangement with ETSI and under the financial rules of the EU eEurope programme. He will coordinate the work under the supervision of both the ETSI TC TISPAN committee and an independent task force to be set-up for providing main input to the programme. The expert effort can be estimated in a range of 40 to 80 days. Should you like to be candidate for such expertise, please send your application and references to philippe.cousin at etsi.org (CC patrick.guillemin at etsi.org and plugtests at etsi.org) before 15 November 2004. 2) CALL FOR ADDITIONNAL VOLUNTEERS TO CONTRIBUTE TO A FIRST ENUM INTEROPERABILITY EVENT TASK FORCE ETSI Interoperability Service is looking for volunteers to extend the task force (EPTF, ENUM Plugtests Task Force) for providing inputs and guidance to the 1st Interoperability event in a more open, transparent and independent manner as possible . The main objective of this task force assisted by dedicated resources of an independent expert is to provide guidance of the architecture, the test beds, and the test cases. This 1st interoperability event should address all the interoperability concerns for the ENUM solutions. Should you like to be candidate to participate to this Task force, please send your application and references to Patrick.guillemin at etsi.org CC plugtests at etsi.org before 15 November 2004. Any expert is welcome, even non-ETSI members as long as the expert is committed to actively and constructively contribute to the work. It is expected that most of the work could be done by email and audio-conference but meeting(s) can also be convened when necessary. I am looking forward to getting a lot of applications and support Best regards Patrick GUILLEMIN, Coordinator of EPTF ETSI - Plugtests Technical Coordinator http://www.etsi.org/plugtests tel +33 (0)4 92 94 43 31 and Philippe COUSIN Interoperability Service Manager + 33 (0)4 92 94 43 06 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 26 Oct 2004 13:59:34 -0400 From: Richard Shockey Date: Tue, 26 Oct 2004 13:59:34 -0400 To: enum at ietf.org Subject: [Enum] Fwd: objections: draft-ietf-enum-epp-e164-06.txt Message-ID: <6.1.2.0.2.20041026133804.03c623a0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Date: Mon, 25 Oct 2004 14:20:47 -0400 (EDT) From: Frank Thompson X-X-Sender: fot at orion.int.libertyrms.com To: iesg at iesg.org X-SA-Exim-Mail-From: fot at ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Tue, 26 Oct 2004 12:52:26 -0400 Cc: ietf at ietf.org Subject: objections: draft-ietf-enum-epp-e164-06.txt X-BeenThere: ietf at ietf.org X-Mailman-Version: 2.1.5 List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces at ietf.org Hi All, I would like to raise an issue with this draft which is currently in "Last Call" in regards to the storage of the extension element: Currently: 3.1.2 EPP Command . . The element contains one or more elements that contain the following child elements: . . 3.2.1 EPP Command . . The element contains one or more elements that contain the following child elements: . . 3.2.5 EPP Command . . The element contains one or more or elements. Each and element contains an element that contains the following child elements: . . Objection: The mandatory inclusion of one or more elements is the major point of contension. By way of using the current epp schema for domain mapping, elements may be used to point to external DNS servers which will host the owning NAPTR records. Thus creating a "thin" enum registry while still accepting and generating "referral" e164 domains. This allows the registry to host the native NAPTR records and all the personal details that come along with that data or allow an external name service to host these dynamic NAPTR records. As a further extension to the current support for is the ability to allow or support. These would work much like the above approach, in that the zone generated by the registry would point to an external DNS that would then resolve the actual NAPTR records for public use. While these are more experimental additions, they are a valuable addition to the draft, while enum trials are taking place to see how usability case studies perform in the real world. To ensure the integrity of the e164 domain, only one of the four types may be associated with an e164 domain at a time. The four types are , , and . This way the zone generated for the e164 domain names will have a deterministic output each and every time. frank thompson Afilias Canada Inc. _______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 26 Oct 2004 14:13:06 -0400 From: Richard Shockey Date: Tue, 26 Oct 2004 14:13:06 -0400 To: enum at ietf.org Subject: [Enum] last call Agenda Items ENUM WG IETF 61 Message-ID: <6.1.2.0.2.20041024120045.03f44ca0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R This is what I have so far.... any additions? Did I forget something ... Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin  Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) MONDAY, November 8, 2004 1730-1930 Break 1930-2200 Evening Sessions RTG  rtgarea   Routing Area Meeting * SEC  msec      Multicast Security WG TSV  enum      Telephone Number Mapping WG TSV  rddp      Remote Direct Data Placement WG There seems to be a strange objection to our ENUM EPP document during IETF Last Call we need to formulate a response to this ASAP. http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt 1. [ 10  min] The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2.    [20 M ]  Title           : An ENUM Registry Type for the Internet Registry Information Service         Author(s)       : A. Newton         Filename        : draft-newton-iris-ereg-02.txt         Pages           : 45           Date            : 2004-9-28         This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt )         registry schema for ENUM administrative information.         A URL for this Internet-Draft is:         http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt NEW ITEMS  : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ]    Title           : ENUM Validation Information Mapping for the                           Extensible Provisioning Protocol         Author(s)       : B. Hoeneisen         Filename        : draft-hoeneisen-enum-validation-epp-00.txt         Pages           : 17         Date            : 2004-9-30 This document describes an EPP extension for mapping information    about the validation process the ENUM Registrar has applied for the    E.164 number (or number range), which the ENUM domain name is based    on.  Specified in XML, this mapping extends the EPP domain name    mapping to provide an additional feature required for the    provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt 4. [  20 M  ] ENUM Validation Architecture and Token Format Definition http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt ONGOING WORK: Title           : IANA Registration for Enumservice VOID         Author(s)       : R. Stastny, L. Conroy         Filename        : draft-ietf-enum-void-00.txt         Pages           : 0         Date            : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes    'mailto:' and 'http:' as per the IANA registration process defined    in the ENUM specification, RFC3761. This Enumservice may be used to    indicate that the E.164 number (or E.164 number range) tied to the    domain in which the enclosing NAPTR is published is not assigned for    communications service. When such an indication is provided, an ENUM    client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title           : ENUM Implementation Issues and Experiences         Author(s)       : L. Conroy, K. Fujiwara         Filename        : draft-ietf-enum-experiences-01.txt         Pages           : 26         Date            : 2004-10-25          This document captures experience in implementing systems based on   the ENUM protocol, and experience of ENUM data that have been created   by others. As such, it is informational only, and produced as a help   to others in reporting what is "out there" and the potential pitfalls   in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-01.txt Title           : IANA Registration for ENUMservices email, fax, mms, ems and sms         Author(s)       : R. Brandner, et al.         Filename        : draft-ietf-enum-msg-03.txt         Pages           : 20         Date            : 2004-10-21          This document registers the 'ENUMservices' "email", "fax", "sms",    "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the    IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.txt There seems to be a strange objection to our ENUM EPP document during IETF Last Call http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 26 Oct 2004 15:10:59 -0400 From: Richard Shockey Date: Tue, 26 Oct 2004 15:10:59 -0400 To: Frank Thompson Subject: [Enum] Re: objections: draft-ietf-enum-epp-e164-06.txt In-Reply-To: Message-ID: <6.1.2.0.2.20041026144137.04c58b80@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 02:20 PM 10/25/2004, Frank Thompson wrote: Hi All, Since there was no discussion of this objection during WG last call could you at least explain why you waited till precisely the last minute to object? . Objection: The mandatory inclusion of one or more elements is the major point of contension. By way of using the current epp schema for domain mapping, elements may be used to point to external DNS servers which will host the owning NAPTR records. Thus creating a "thin" enum registry while still accepting and generating "referral" e164 domains. This allows the registry to host the native NAPTR records and all the personal details that come along with that data or allow an external name service to host these dynamic NAPTR records. As a further extension to the current support for is the ability to allow or support. Could you detail what cname or dname have to do with this? The use of either in the ENUM context have been considered harmful in the past. These would work much like the above approach, in that the zone generated by the registry would point to an external DNS that would then resolve the actual NAPTR records for public use. While these are more experimental additions, they are a valuable addition to the draft, while enum trials are taking place to see how usability case studies perform in the real world. Well a better way to deal this would have been to permit the original draft to proceed to RFC and propose these as extensions. To ensure the integrity of the e164 domain, only one of the four types may be associated with an e164 domain at a time. The four types are , , and . This way the zone generated for the e164 domain names will have a deterministic output each and every time. frank thompson Afilias Canada Inc. _______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Tue, 26 Oct 2004 17:44:20 -0400 From: Andrew Newton Date: Tue, 26 Oct 2004 17:44:20 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <2072.1098631873@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Oct 24, 2004, at 12:08 PM, Conroy, Lawrence (SMTP) wrote: AFAIK, EDNS0 only helps if the MTU is more than 512 octets (see the comment at the end of 2671 on ICMP storms for a hint). You can't guarantee that this is the case in all access networks. True, but pragmatically speaking won't almost anybody doing voip be connected in such a way to allow higher PMTUs anyway? -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Patrick.Guillemin@etsi.org Wed, 27 Oct 2004 05:50:47 -0400 From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= Date: Wed, 27 Oct 2004 05:50:47 -0400 To: Subject: RE: [Enum] last call Agenda Items ENUM WG IETF 61 Message-ID: <4091553999CBE4409CC2B562152B5A33064517B2@email10.etsihq.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear All,   I cannot attend this IETF meeting but I would like to let you know that we would like to provide ENUM tests during our VoIP (SIP, H.323) Plugtests www.etsi.org/plugtests/NGN_VoIP.htm We are currently searching for one ENUM expert (funded by ETSI Plugtests/EC-eEurope) to help us defining test cases for ENUM tests to be conducted in another well prepared (more dedicated) ENUM Plugtests planned in Spring 2005.   If interested just tell me.   BR Patrick GUILLEMIN ETSI Plugtests www.etsi.org/plugtests From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Richard Shockey Sent: 26 October 2004 20:05 To: enum at ietf.org Subject: [Enum] last call Agenda Items ENUM WG IETF 61   This is what I have so far.... any additions? Did I forget something ... Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin  Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) MONDAY, November 8, 2004 1730-1930 Break 1930-2200 Evening Sessions RTG  rtgarea   Routing Area Meeting * SEC  msec      Multicast Security WG TSV  enum      Telephone Number Mapping WG TSV  rddp      Remote Direct Data Placement WG There seems to be a strange objection to our ENUM EPP document during IETF Last Call we need to formulate a response to this ASAP. http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt 1. [ 10  min] The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2.    [20 M ]  Title           : An ENUM Registry Type for the Internet Registry Information Service         Author(s)       : A. Newton         Filename        : draft-newton-iris-ereg-02.txt         Pages           : 45           Date            : 2004-9-28         This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt )         registry schema for ENUM administrative information.         A URL for this Internet-Draft is:         http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt NEW ITEMS  : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ]    Title           : ENUM Validation Information Mapping for the                           Extensible Provisioning Protocol         Author(s)       : B. Hoeneisen         Filename        : draft-hoeneisen-enum-validation-epp-00.txt         Pages           : 17         Date            : 2004-9-30 This document describes an EPP extension for mapping information    about the validation process the ENUM Registrar has applied for the    E.164 number (or number range), which the ENUM domain name is based    on.  Specified in XML, this mapping extends the EPP domain name    mapping to provide an additional feature required for the    provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt 4. [  20 M  ] ENUM Validation Architecture and Token Format Definition http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt ONGOING WORK: Title           : IANA Registration for Enumservice VOID         Author(s)       : R. Stastny, L. Conroy         Filename        : draft-ietf-enum-void-00.txt         Pages           : 0         Date            : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes    'mailto:' and 'http:' as per the IANA registration process defined    in the ENUM specification, RFC3761. This Enumservice may be used to    indicate that the E.164 number (or E.164 number range) tied to the    domain in which the enclosing NAPTR is published is not assigned for    communications service. When such an indication is provided, an ENUM    client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title           : ENUM Implementation Issues and Experiences         Author(s)       : L. Conroy, K. Fujiwara         Filename        : draft-ietf-enum-experiences-01.txt         Pages           : 26         Date            : 2004-10-25          This document captures experience in implementing systems based on   the ENUM protocol, and experience of ENUM data that have been created   by others. As such, it is informational only, and produced as a help   to others in reporting what is "out there" and the potential pitfalls   in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-01.txt Title           : IANA Registration for ENUMservices email, fax, mms, ems and sms         Author(s)       : R. Brandner, et al.         Filename        : draft-ietf-enum-msg-03.txt         Pages           : 20         Date            : 2004-10-21          This document registers the 'ENUMservices' "email", "fax", "sms",    "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the    IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.txt There seems to be a strange objection to our ENUM EPP document during IETF Last Call http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-06.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Thu, 28 Oct 2004 12:06:19 -0400 From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 12:06:19 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-07.txt Message-ID: <200410281514.LAA24055@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R 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 : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-07.txt Pages : 17 Date : 2004-10-27 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-epp-e164-07.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From samia.mtimet@nic.fr Fri, 29 Oct 2004 01:49:28 -0400 From: "Samia M'timet" Date: Fri, 29 Oct 2004 01:49:28 -0400 To: enum at ietf.org Subject: Re: [Enum] FYI - another topic for the experiences draft In-Reply-To: <8BD5AA9E-237C-11D9-8BBF-000393A70BB2@roke.co.uk> Message-ID: <20041022141141.7849dbce.samia.mtimet@nic.fr> MIME-Version: 1.0 Content-Type: text/plain Status: R On Fri, 22 Oct 2004 11:55:42 +0100 Jim Reid wrote: > Responses to ENUM lookups are likely to contain many NAPTR records and > could well exceed the 512-byte payload limit on UDP responses defined > in RFC1035. If these replies are also signed using Secure DNS, they > will be considerably larger than 512 bytes. I think there's a real need of documentation to explain what is the difference between "Secure DNS" and "walled garden". There's a lot of confusing words in this field. -- Samia M'timet AFNIC _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 29 Oct 2004 12:34:01 -0400 From: Richard Shockey Date: Fri, 29 Oct 2004 12:34:01 -0400 To: enum at ietf.org Subject: [Enum] FYI news on CC 1 Message-ID: <6.1.2.0.2.20041029120723.03e11eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I'm hoping to have a "special guest star" at the Monday night meeting to give us some more details on this. ############# For Immediate Release: Media Contact: Jackie Henson McKenna Long and Aldridge LLP 202-496-7549 jhenson at mckennalong.com TOP TELECOMMUNICATIONS AND INTERNET COMPANIES FORM COUNTRY CODE 1 ENUM LLC TO FOSTER NEW INTERNET TELECOM TECHNOLOGY New Organization to Promote Development of Technology to Combine Internet with Traditional Telephony to Offer Streamlined Communication Washington DC - (October 28, 2004) - Today, several leading telecommunications and Internet companies have announced the formation of a new organization, the Country Code 1 ENUM Limited Liability Company (CC1 ENUM LLC), to build the public infrastructure that will promote the development of ENUM technology in a single, carrier-class manner within the countries of the North American Numbering Plan (NANP). The countries of the NANP include the United States, Canada and the Caribbean nations. ENUM is a technology that allows users to combine the resources of the Internet with traditional telephony, uniting these two diverse worlds of communications and enabling a whole new range of communication applications.  The ENUM system effectively enables individuals, businesses and other organizations to maximize the use of both the public Internet and the Public Switched Telephone Network (PSTN) by associating telephone numbers with Internet domain names.   As a result, phone numbers can be used to send traditional telephony services like voice calls or faxes which can be converted to digital packets for delivery to a variety of devices. A common ENUM system becomes increasingly essential as applications like voice over IP (VoIP) become more widely adopted.  The ENUM system bridges the technology gap between the public Internet and the Public Switched Telephone Network so that VoIP users of different service providers can communicate more simply with each other. Through the launch of this new organization, the founding companies are seeking to build a commercial implementation consistent with the relevant open standards of the Internet Engineering Task Force (IETF) and the International Telecommunication Union (ITU) upon which ENUM is based.  The new company will help to implement a single, public ENUM system for those nations within the NANP that choose to participate.  It is intended that the North American implementation of ENUM will adhere to national and industry privacy requirements.  The LLC?s first task will involve selection of a vendor to take the initial steps towards creation of an infrastructure that would enable the countries within the NANP to establish their own national ENUM implementations. The limited liability company will also be responsible for selecting a vendor to develop the national infrastructure for the United States. Country Code 1 ENUM LLC will manage the public infrastructure that translates traditional telephone numbers into Internet domain names, combining the reach and capabilities of the Internet with the Public Switched Telephone Network (PSTN) to enable new communications capabilities.  CC1 ENUM LLC members include AT&T, GoDaddy.com, MCI, SBC Laboratories, Sprint, and Verizon. # # # >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 29 Oct 2004 13:40:40 -0400 From: Richard Shockey Date: Fri, 29 Oct 2004 13:40:40 -0400 To: enum at ietf.org Subject: [Enum] FYI more news on CC 1 Message-ID: <6.1.2.0.2.20041029133357.058b1eb0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Attached is a statement and web link that was released today by Michael Gallagher, US Department of Commerce NTIA regarding the formation of the CC1 ENUM LLC.   http://www.ntia.doc.gov/ntiahome/press/2004/enumorg_10292004.html   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 29 Oct 2004 17:12:59 -0400 From: Richard Shockey Date: Fri, 29 Oct 2004 17:12:59 -0400 To: enum at ietf.org Subject: [Enum] FINAL Agenda ENUM WG IETF 61 Washington DC Message-ID: <6.1.2.0.2.20041029162226.03d1bb40@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ MONDAY, November 8, 2004 1730-1930 Break 1930-2200 Evening Sessions RTG rtgarea Routing Area Meeting * SEC msec Multicast Security WG TSV enum Telephone Number Mapping WG TSV rddp Remote Direct Data Placement WG AGENDA BASHING (5 min) Short Presentation on current status of ENUM in CC 1: Special Guest - Karen Mulberry MCI 1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2. [20 M ] Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt ) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt NEW ITEMS : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt 4. [ 20 M ] ENUM Validation Architecture and Token Format Definition http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt ONGOING WORK: Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-01.txt Pages : 26 Date : 2004-10-25 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-01.txt Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-03.txt Pages : 20 Date : 2004-10-21 This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum