From rfc-editor@rfc-editor.org Mon, 06 Jun 2005 20:38:42 -0400 From: rfc-editor@rfc-editor.org Date: Mon, 06 Jun 2005 20:38:42 -0400 To: ietf-announce at ietf.org Subject: [Enum] RFC 4114 on E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) Message-ID: <200506070037.j570bfL21870@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain Status: RO A new Request for Comments is now available in online RFC libraries. RFC 4114 Title: E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) Author(s): S. Hollenbeck Status: Standards Track Date: June 2005 Mailbox: shollenbeck at verisign.com Pages: 17 Characters: 31490 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-epp-e164-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4114.txt This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent 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. This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 06 Jun 2005 21:16:26 -0400 From: Richard Shockey Date: Mon, 06 Jun 2005 21:16:26 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00.txt Message-ID: <6.2.1.2.2.20050606211449.0420f080@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 06 Jun 2005 15:44:08 -0400 Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-user-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 X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Carrier/User enumservice Registration Author(s) : P. Pfautz, et al. Filename : draft-pfautz-lind-enum-carrier-user-00.txt Pages : 10 Date : 2005-6-6 This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-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-pfautz-lind-enum-carrier-user-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-pfautz-lind-enum-carrier-user-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: <2005-6-6161842.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff 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 bhoeneis@switch.ch Tue, 07 Jun 2005 05:39:40 -0400 From: Bernie Hoeneisen Date: Tue, 07 Jun 2005 05:39:40 -0400 To: rfc-editor at rfc-editor.org Subject: [Enum] Erratum in RFC 4114 In-Reply-To: <200506070037.j570bfL21870@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO FYI and the RFC errata Database: As reported months ago (before publication as RFC) directly to the author, there is an erratum in RFC 4114 in section 3.1.2. EPP Command: Example response: [...] S: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa [...] S: ns1.example.com S: ns2.example.com S: --> S: ns1.example.com --> S: ns2.example.com [...] There is the that should list the "fully qualified names of the subordinate host objects that exist under this superordinate domain object." As the is not "example.com:, those elements should be removed in this case. cheers, Bernie On Mon, 6 Jun 2005 rfc-editor at rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 4114 Title: E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) Author(s): S. Hollenbeck Status: Standards Track Date: June 2005 Mailbox: shollenbeck at verisign.com Pages: 17 Characters: 31490 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-epp-e164-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4114.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Tue, 07 Jun 2005 07:52:45 -0400 From: "Hollenbeck, Scott" Date: Tue, 07 Jun 2005 07:52:45 -0400 To: "Bernie Hoeneisen" Subject: [Enum] RE: Erratum in RFC 4114 Message-ID: <046F43A8D79C794FA4733814869CDF07988822@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Yes, Bernie brought this to my attention a while back and I completely forgot about it during auth48. It is an editorial error in the example. -Scott- > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis at switch.ch] > Sent: Tuesday, June 07, 2005 5:38 AM > To: rfc-editor at rfc-editor.org > Cc: enum at ietf.org; Hollenbeck, Scott > Subject: Erratum in RFC 4114 > > FYI and the RFC errata Database: > > As reported months ago (before publication as RFC) directly > to the author, > there is an erratum in RFC 4114 in section 3.1.2. EPP Command: > > > Example response: > > [...] > S: > 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa > [...] > S: ns1.example.com > S: ns2.example.com > S: > --> S: ns1.example.com > --> S: ns2.example.com > [...] > > There is the that should list the "fully > qualified names of > the subordinate host objects that exist under this > superordinate domain > object." > > As the is not "example.com:, those > elements should be removed in this case. > > cheers, > Bernie > > > On Mon, 6 Jun 2005 rfc-editor at rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 4114 > > > > Title: E.164 Number Mapping for the Extensible > > Provisioning Protocol (EPP) > > Author(s): S. Hollenbeck > > Status: Standards Track > > Date: June 2005 > > Mailbox: shollenbeck at verisign.com > > Pages: 17 > > Characters: 31490 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-enum-epp-e164-08.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4114.txt > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Wed, 08 Jun 2005 07:50:14 -0400 From: Michael Haberler Date: Wed, 08 Jun 2005 07:50:14 -0400 To: Richard Shockey Message-ID: <6.2.1.2.2.20050608134529.044c4e78@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO at first glance, this looks like it could resolve the user/carrier discussion while subsuming both flavours under one tree, with the corresponding cost advantage, and simpler interfacing A potential issue I could think of - how does this work in a open number plan (variable number length, and variable length DDI *extension*) ? -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Wed, 08 Jun 2005 10:55:41 -0400 From: Michael Haberler Date: Wed, 08 Jun 2005 10:55:41 -0400 To: "Lupton, Ronan" Message-ID: <6.2.1.2.2.20050608164849.03bdb1c8@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO What I am suggesting is that the proposal be actually tried out given, say, the JPRS resolver (which says it can do a single nonterminal) and lookups of numbers at the delegation boundary (likely works) and what happens if a longer number (with a DDI appended) and thus points into on of the user and/or carrier subtree I assume it can be made to work, or maybe it works anyway, I'm just curious on the results in a setting where you cant assume all numbers are 10 digits we're currently looking into it over here in non-NANPA land -Michael At 15:59 08.06.2005, Lupton, Ronan wrote: Michael, Does ITU E164 standard not define certain characteristics of numbering in a standard format? I attach a copy of the specification. I make specific reference to page 13 of this standard. I gather it is the fundamental basis for the .e164.arpa addressing structure. I had a number of conversations re: same at ETSI last week. DDI (Direct Dial Inwards) allocations are generally relevant to B/P - ISDN services are generally the last 4 digits in a given E164 number within the national number plan. Regards, Ronan Lupton MCI -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Michael Haberler Sent: 08 June 2005 12:50 To: Richard Shockey; enum at ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00.txt at first glance, this looks like it could resolve the user/carrier discussion while subsuming both flavours under one tree, with the corresponding cost advantage, and simpler interfacing A potential issue I could think of - how does this work in a open number plan (variable number length, and variable length DDI *extension*) ? -Michael _______________________________________________ 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 Richard.Stastny@oefeg.at Wed, 08 Jun 2005 11:57:35 -0400 From: "Stastny Richard" Date: Wed, 08 Jun 2005 11:57:35 -0400 To: "Michael Haberler" Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF2F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Roman, I think you refer to Figure 2/E.164 on page 13 First, there is nowhere anything about 4 digits Second you mix up the partial number (which is the DDI) which is part of the SN and therefore part of the E.164 number, and the ISDN SubAddress, which is not part of the E.164 number (up to 40 dgits) and therefore not in ENUM. There is no restriction of the lenght of the DDI, as long as the E.164 number (pilot + DDI) is not exceeding 15 digits. The pilot number is the full E.164 number - DDI ;-) The problem with DDI numbers already exists in "normal" ENUM, because a user (e.g in Austria or Germany) may either dial the Pilot number alone or the Pilot + 0 to get to the switchboard. In the first case by timeout, in the second direct. or he may dial the extension direct. If he dials a non existing extension, he also ends up with the switchboard by timeout The problem is that the DDI number plan is up to the PBX admin; he even does not need to be constent in number lenght, so he may have a internal number plan such as: 0 for outcalls 2xx 3xx 4xx 5xx 6xxx 7xxx 91 92 for cross-trunks and he may change this at any time without telling the provider. Ok you may forget 0 and 9, because they are not reachable via DDI. In normal ENUM you delegate the pilot say +4350811 from tier 1 Nameserver with NS records to a tier 2 NS RUN by the enterprise having the PBX with DDI In the tier 2 NS you enter the NAPTR to reach the switchboard and additional NAPTRs for each DDI number (subdomain) The basic idea with the Pfautz draft is that you enter 2 non terminal NAPTRs for each single E.164 number. Since the DDI number space is administrated by the PBX admin, he may do so, but he would have to with each extension via the Tier 1 (which may charge for each transaction) in the above case he is only changing his own tier 2 nameserver In addition, the carrier record needs to be updated in parallel, so the user is managing carrier records ;-) So DDIs may be implemented, but would require a transaction in Tier 1 for each change in DDI numbers. best regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Mi 08.06.2005 16:55 An: Lupton, Ronan; enum at ietf.org Betreff: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt What I am suggesting is that the proposal be actually tried out given, say, the JPRS resolver (which says it can do a single nonterminal) and lookups of numbers at the delegation boundary (likely works) and what happens if a longer number (with a DDI appended) and thus points into on of the user and/or carrier subtree I assume it can be made to work, or maybe it works anyway, I'm just curious on the results in a setting where you cant assume all numbers are 10 digits we're currently looking into it over here in non-NANPA land -Michael At 15:59 08.06.2005, Lupton, Ronan wrote: >Michael, > >Does ITU E164 standard not define certain characteristics of numbering in >a standard format? > >I attach a copy of the specification. I make specific reference to page 13 >of this standard. > >I gather it is the fundamental basis for the .e164.arpa addressing structure. > >I had a number of conversations re: same at ETSI last week. > >DDI (Direct Dial Inwards) allocations are generally relevant to B/P - ISDN >services are generally the last 4 digits in a given E164 number within the >national number plan. > >Regards, > >Ronan Lupton >MCI > >-----Original Message----- >From: enum-bounces at ietf.org >[mailto:enum-bounces at ietf.org] On Behalf Of >Michael Haberler >Sent: 08 June 2005 12:50 >To: Richard Shockey; enum at ietf.org >Subject: Re: [Enum] Fwd: I-D >ACTION:draft-pfautz-lind-enum-carrier-user-00.txt > > >at first glance, this looks like it could resolve the user/carrier >discussion while subsuming both flavours under one tree, with the >corresponding cost advantage, and simpler interfacing > >A potential issue I could think of - how does this work in a open number >plan (variable number length, and variable length DDI *extension*) ? > >-Michael > >_______________________________________________ >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 Richard.Stastny@oefeg.at Thu, 09 Jun 2005 06:17:52 -0400 From: "Stastny Richard" Date: Thu, 09 Jun 2005 06:17:52 -0400 To: "Michael Haberler" Subject: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Additional thoughts to the handling of DDIs The need to enter for each single DDI number could only be avoided if the following wild cards are possible If in the below example from the draft the number 1-497-867 is considered the "pilot" number and 5309 the partial number: $Origin 7.6.8.7.9.4.1.e164.arpa. * IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com * IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net Question to the experts: is this allowed? Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Stastny Richard > Sent: Wednesday, June 08, 2005 6:00 PM > To: Michael Haberler; Lupton, Ronan; enum at ietf.org > Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 > .txt > > Roman, > > I think you refer to Figure 2/E.164 on page 13 > > First, there is nowhere anything about 4 digits > Second you mix up the partial number (which is the DDI) > which is part of the SN and therefore part of the E.164 number, > > and the ISDN SubAddress, which is not part of the E.164 number (up to 40 > dgits) > and therefore not in ENUM. > > There is no restriction of the lenght of the DDI, as long as the > E.164 number (pilot + DDI) is not exceeding 15 digits. > > The pilot number is the full E.164 number - DDI ;-) > > The problem with DDI numbers already exists in "normal" ENUM, > because a user (e.g in Austria or Germany) may either dial the Pilot > number alone or the Pilot + 0 to get to the switchboard. In the first case > by timeout, in the second direct. > > or he may dial the extension direct. If he dials a non existing extension, > he also ends up with the switchboard by timeout > > The problem is that the DDI number plan is up to the PBX admin; > he even does not need to be constent in number lenght, so he may > have a internal number plan such as: > 0 for outcalls > 2xx > 3xx > 4xx > 5xx > 6xxx > 7xxx > 91 > 92 for cross-trunks > and he may change this at any time without telling the provider. > > Ok you may forget 0 and 9, because they are not reachable via DDI. > > In normal ENUM you delegate the pilot > say +4350811 from tier 1 Nameserver with NS records to a tier 2 NS > RUN by the enterprise having the PBX with DDI > In the tier 2 NS you enter the NAPTR to reach the switchboard > and additional NAPTRs for each DDI number (subdomain) > > The basic idea with the Pfautz draft is that you enter 2 non terminal > NAPTRs for each single E.164 number. Since the DDI number space > is administrated by the PBX admin, he may do so, but he would have to > with each extension via the Tier 1 (which may charge for each transaction) > in the above case he is only changing his own tier 2 nameserver > > In addition, the carrier record needs to be updated in parallel, > so the user is managing carrier records ;-) > > So DDIs may be implemented, but would require a transaction > in Tier 1 for each change in DDI numbers. > > best regards > Richard > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Michael Haberler > Gesendet: Mi 08.06.2005 16:55 > An: Lupton, Ronan; enum at ietf.org > Betreff: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 > .txt > > > > What I am suggesting is that the proposal be actually tried out given, > say, > the JPRS resolver (which says it can do a single nonterminal) and lookups > of numbers at the delegation boundary (likely works) and what happens if a > longer number (with a DDI appended) and thus points into on of the user > and/or carrier subtree > > I assume it can be made to work, or maybe it works anyway, I'm just > curious > on the results in a setting where you cant assume all numbers are 10 > digits > > we're currently looking into it over here in non-NANPA land > > -Michael > > > At 15:59 08.06.2005, Lupton, Ronan wrote: > > >Michael, > > > >Does ITU E164 standard not define certain characteristics of numbering in > >a standard format? > > > >I attach a copy of the specification. I make specific reference to page > 13 > >of this standard. > > > >I gather it is the fundamental basis for the .e164.arpa addressing > structure. > > > >I had a number of conversations re: same at ETSI last week. > > > >DDI (Direct Dial Inwards) allocations are generally relevant to B/P - > ISDN > >services are generally the last 4 digits in a given E164 number within > the > >national number plan. > > > >Regards, > > > >Ronan Lupton > >MCI > > > >-----Original Message----- > >From: enum-bounces at ietf.org > >[mailto:enum-bounces at ietf.org] On Behalf Of > >Michael Haberler > >Sent: 08 June 2005 12:50 > >To: Richard Shockey; enum at ietf.org > >Subject: Re: [Enum] Fwd: I-D > >ACTION:draft-pfautz-lind-enum-carrier-user-00.txt > > > > > >at first glance, this looks like it could resolve the user/carrier > >discussion while subsuming both flavours under one tree, with the > >corresponding cost advantage, and simpler interfacing > > > >A potential issue I could think of - how does this work in a open number > >plan (variable number length, and variable length DDI *extension*) ? > > > >-Michael > > > >_______________________________________________ > >enum mailing list > >enum at ietf.org > >https://www1.ietf.org/mail ma > n/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 lendl@nic.at Thu, 09 Jun 2005 07:24:17 -0400 From: Otmar Lendl Date: Thu, 09 Jun 2005 07:24:17 -0400 To: enum at ietf.org Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <20050609111328.GL26386@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: RO On 2005/06/09 12:06, Stastny Richard wrote: > Additional thoughts to the handling of DDIs > > The need to enter for each single DDI number could > only be avoided if the following wild cards are possible > > If in the below example from the draft the number 1-497-867 > is considered the "pilot" number and 5309 the partial number: > > $Origin 7.6.8.7.9.4.1.e164.arpa. > > * IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com > > * IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net > > Question to the experts: is this allowed? Two remarks on this: * You need two more RRs as the wildcard does not cover the $origin itself, i.e.: @ IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com @ IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net * Similar setups are common in the wildcard MX record case, e.g. I just tried: *.test MX 10 mail *.test MX 20 other-mailhost and this works without any problems. I haven't looked at the regex and replacement part of the DDDS algorithm yet. Testing that is next on my agenda. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 09 Jun 2005 07:32:49 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 09 Jun 2005 07:32:49 -0400 To: Stastny Richard Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 9, 2005, at 06:15, Stastny Richard wrote: If in the below example from the draft the number 1-497-867 is considered the "pilot" number and 5309 the partial number: $Origin 7.6.8.7.9.4.1.e164.arpa. * IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com * IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net Question to the experts: is this allowed? Yes, but whether you get what you want out of this when querying is questionable. The problems with wildcards are the following: - When issuing a query for Owner FOO, Class IN and Type NAPTR, you will get a match ONLY if there is no other record with the same Owner, regardless of Type. This imply, if you have NS, or SOA, or DS or whatever with Owner FOO, you will get "no such record" even though the wildcard is there. - This is especially important when using NAPTR for "delegation"...how does this work with DNSSEC, and what chain of trust will you get? So, whether the above will work or not depends on what other records exists in the same zone, what the queries are etc. I would say "possible, but be very very careful". paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Thu, 09 Jun 2005 07:43:09 -0400 From: "Klaus Darilion" Date: Thu, 09 Jun 2005 07:43:09 -0400 To: "Stastny Richard" Subject: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <8BC845943058D844ABFC73D2220D466502778111@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi! > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > $Origin 7.6.8.7.9.4.1.e164.arpa. > > * IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com > > * IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net > > Question to the experts: is this allowed? yes. The problem occours on the second step of the DDDS algorithm: For each dialed extension, the replacement is the same, e.g. 7.6.8.7.9.4.1.joesenum.com. Thus, the second NAPTR is for example: $7.6.8.7.9.4.1.joesenum.com. @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+1497867(.*)$!sip:\\1 at sip.joe.com!" . Using this regexp, you can catch all extension, but it is nearly impossible the exclude some extensions from enum - for example fax extensions. You would have to do it this way: $7.6.8.7.9.4.1.joesenum.com. @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670001$!sip:0001 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670002$!sip:0002 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670004$!sip:0004 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670005$!sip:0005 at sip.joe.com!" . ... That does not scale. regards, klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 09 Jun 2005 08:21:43 -0400 From: lconroy Date: Thu, 09 Jun 2005 08:21:43 -0400 To: "'enum at ietf.org> Subject: [Enum] process questions arising from draft-pfautz-lind-enum-carrier-user-00.txt Message-ID: <4a54977120367aa2ae2d86b107c76256@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Folks, Discussion of the Principle behind this Enumservice registration (apparently to "move out" the squatters so that there is room for carriers as well) will have to wait. I can see that there are benefits for some to such a clearance, so I await *convincing* arguments from others with interest. Here I'm concerned purely with the Process issues:: RFC3761 defines the template for specification of Enumservices. One of the items required for an Enumservice registration document is the expected output/URI. See section 2.4.2.1, section 3. (introductory paragraph), section 3.1.1 (note the MUST). Considering : These Enumservices do not have a RegExp field (in accordance with RFC3403, section 4.1, subsection REPLACEMENT, 2nd paragraph). However, as there is no RegExp field in non-terminal NAPTRs, there is no place for "that very NAPTR" to hold text used to generate a URI. Whilst RFC3402 and 3403 do not specifically preclude a non-empty Service field in a non-terminal NAPTR, 3761 puts MUST-level requirements on registration of an Enumservice token to be used in a NAPTR used for the E2U (ENUM) DDDS Application. This registration document would appear not to meet these requirements. So... Process Questions:: Do we change 3761 to remove the requirement from 3761 section 3.1.1 paragraph 2 (and the other sections)? If not, then how can ANY Enumservice registration for use with non-terminal NAPTRs match the requirements of 3761? all the best, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Thu, 09 Jun 2005 08:50:03 -0400 From: "Clive D.W. Feather" Date: Thu, 09 Jun 2005 08:50:03 -0400 To: Patrik Fältström Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <20050609124848.GL84564@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: RO Patrik Fältström said: > The problems with wildcards are the following: [...] > So, whether the above will work or not depends on what other records > exists in the same zone, what the queries are etc. Isn't this what DNAME was invented for? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 09 Jun 2005 11:12:38 -0400 From: "Stastny Richard" Date: Thu, 09 Jun 2005 11:12:38 -0400 To: "Klaus Darilion" Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF38@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Thanks Otmar, Patrik and Klaus for the replies Klaus, with you reply I think I found now a major draw-back with this approach. in this case the normal way to to this, namely introduce subdomains is broken you cannot use $7.6.8.7.9.4.1.joesenum.com. 0.0.0.1 IN NAPTR 100 50 "" "E2U+sip" "!^*$!sip:0001 at sip.joe.com!" anymore. But your proposal means that ALL NAPTRS for all extensions will be returned in one response which I do not know is possible at for large PBX Help! Richard ________________________________ Von: Klaus Darilion [mailto:klaus.darilion at nic.at] Gesendet: Do 09.06.2005 13:42 An: Stastny Richard; Michael Haberler; Lupton, Ronan; enum at ietf.org Betreff: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Hi! > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > $Origin 7.6.8.7.9.4.1.e164.arpa. > > * IN NAPTR 100 50 "" "E2U+user" "" 7.6.8.7.9.4.1.joesenum.com > > * IN NAPTR 100 50 "" "E2U+carrier" "" 7.6.8.7.9.4.1.telco.net > > Question to the experts: is this allowed? yes. The problem occours on the second step of the DDDS algorithm: For each dialed extension, the replacement is the same, e.g. 7.6.8.7.9.4.1.joesenum.com. Thus, the second NAPTR is for example: $7.6.8.7.9.4.1.joesenum.com. @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+1497867(.*)$!sip:\\1 at sip.joe.com!" . Using this regexp, you can catch all extension, but it is nearly impossible the exclude some extensions from enum - for example fax extensions. You would have to do it this way: $7.6.8.7.9.4.1.joesenum.com. @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670001$!sip:0001 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670002$!sip:0002 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670004$!sip:0004 at sip.joe.com!" . @ IN NAPTR 100 50 "" "E2U+sip" "!^\\+14978670005$!sip:0005 at sip.joe.com!" . ... That does not scale. regards, klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Thu, 09 Jun 2005 12:07:31 -0400 From: "Klaus Darilion" Date: Thu, 09 Jun 2005 12:07:31 -0400 To: "Stastny Richard" Subject: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <8BC845943058D844ABFC73D2220D466502778135@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: RO > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > > But your proposal means that ALL NAPTRS > for all extensions will be returned in one response which I > do not know is possible at for large PBX This is just a dirty workaround and does not scale for lot of extensions. Consider the ENUM resolver has to fetch 1000 NAPTRs and perform 1000 regexp to find the one matching NAPTR :-( Maybe someone has a better approach how to handle this? regards, klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Thu, 09 Jun 2005 12:22:52 -0400 From: Jim Reid Date: Thu, 09 Jun 2005 12:22:52 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <387154845a53673928f374d759e34829@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 9, 2005, at 13:48, Clive D.W. Feather wrote: Patrik Fältström said: The problems with wildcards are the following: [...] So, whether the above will work or not depends on what other records exists in the same zone, what the queries are etc. Isn't this what DNAME was invented for? No, though I guess it all depends on your definition of "this". DNAME was originally invented for reverse lookups of IPv6 addresses that would have been "delegated" on arbitrary bit-boundaries with bit-string labels. [It helped with renumbering of IPv6 networks and multi-homed IPv6 nets.] Although that purpose has now gone away, the DNAME RRtype lives on. It can be (ab)used for many things such as kludging around some of the horrors of wildcarding. Though IMO DNAME records really shouldn't be used for that sort of thing. DNAME *might* be useful in ENUM for things like area code changes or renumbering a DDI block. However be very, very careful, just like Patrik said about wildcarding. CNAME synthesis can make life very exciting and not always in a good way.... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 09 Jun 2005 12:46:36 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 09 Jun 2005 12:46:36 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <48893298-0454-4553-BB46-D33ACACE9DF0@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 9, 2005, at 08:48, Clive D.W. Feather wrote: Patrik Fältström said: The problems with wildcards are the following: [...] So, whether the above will work or not depends on what other records exists in the same zone, what the queries are etc. Isn't this what DNAME was invented for? ....yes, and why DNAME is not recommended. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 09 Jun 2005 12:51:28 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 09 Jun 2005 12:51:28 -0400 To: Jim Reid Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <8D38776F-5DE9-45EF-8D49-BEEAF36B1991@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 9, 2005, at 12:19, Jim Reid wrote: No, though I guess it all depends on your definition of "this". DNAME was originally invented for reverse lookups of IPv6 addresses that would have been "delegated" on arbitrary bit-boundaries with bit-string labels. [It helped with renumbering of IPv6 networks and multi-homed IPv6 nets.] Although that purpose has now gone away, the DNAME RRtype lives on. I just want to extend this explanation by stating that DNAME was designed together with the bitstring label ideas... Those together create a tool that makes it INCREDIBLY hard to make sure the zone setup is correct, and given approximately 20% of the normal delegations are broken already today, that percentage would definitely increase given DNAME+bitstring labels. You WILL shoot yourself in your feet with tools like these. And, remember that they in all cases I have seen were designed to solve problems people had in their management / provisioning systems. Having humans by hand editing zone files using vi/emacs or whatever is over. We should not create hacks in the protocols because of "bad administration tools". I do know we have admin/delegation needs in ENUM, but let's stay with those issues, and try to keep management tool bugs out of the discussion. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 09 Jun 2005 13:26:15 -0400 From: "Stastny Richard" Date: Thu, 09 Jun 2005 13:26:15 -0400 To: Patrik Fältström Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF3B@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Dear all, CNAME, DNAME and non-terminal NAPTRs I am not a DNS expert and I do not understand DDDS I never understood what a non-terminal NAPTRs is really good for; So can anybody out there explain to me what the difference between a not-terminal NAPTR and a CNAME is in terms of DDDS In the draft-pfautz I-D the non-terminal NAPTR is used like a CNAME what I need for my DDI problem is a non-terminal NAPTR working similar to a DNAME I was alo wondering why the example in the draft is: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U+user" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2U+carrier" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net an not just $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U+user" "" joesenum.com IN NAPTR 100 50 "" "E2U+carrier" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net While it would make sense tu have a structure like 9.0.3.5.7.6.8.7.9.4.1.telco.net because the telco may host many numbers, it does not for a single user. It would make sense if there is a rule like: If you have something like $Origin 7.6.8.7.9.4.1.e164.arpa. * IN NAPTR 100 50 "" "E2U+user" "" joesenum.com * IN NAPTR 100 50 "" "E2U+carrier" ""7.6.8.7.9.4.1.telco.net you may contunue in $Origin joseenum.com with 9.0.3.5 IN NAPTR 100 10 "u" "E2U+sip" ""!^.*$!sip:info at example.com!" . or in other words, if the ENUM client makes a DNS query for for NAPTR for 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. and getting back IN NAPTR 100 50 "" "E2U+user" "" joesenum.com in 7.6.8.7.9.4.1.e164.arpa. he is attaching the rest of 9.0.3.5. (if there is one) to joseenum.com yielding 9.0.3.5.joseenum,com and makes a second query for this This is of course a hack, but is would be very helpful Richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Do 09.06.2005 18:50 An: Jim Reid Cc: Clive D.W. Feather; Stastny Richard; Michael Haberler; enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt On Jun 9, 2005, at 12:19, Jim Reid wrote: > No, though I guess it all depends on your definition of "this". > DNAME was originally invented for reverse lookups of IPv6 addresses > that would have been "delegated" on arbitrary bit-boundaries with > bit-string labels. [It helped with renumbering of IPv6 networks and > multi-homed IPv6 nets.] Although that purpose has now gone away, > the DNAME RRtype lives on. > I just want to extend this explanation by stating that DNAME was designed together with the bitstring label ideas... Those together create a tool that makes it INCREDIBLY hard to make sure the zone setup is correct, and given approximately 20% of the normal delegations are broken already today, that percentage would definitely increase given DNAME+bitstring labels. You WILL shoot yourself in your feet with tools like these. And, remember that they in all cases I have seen were designed to solve problems people had in their management / provisioning systems. Having humans by hand editing zone files using vi/emacs or whatever is over. We should not create hacks in the protocols because of "bad administration tools". I do know we have admin/delegation needs in ENUM, but let's stay with those issues, and try to keep management tool bugs out of the discussion. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Thu, 09 Jun 2005 15:18:40 -0400 From: Jim Reid Date: Thu, 09 Jun 2005 15:18:40 -0400 To: Patrik Fältström Subject: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2008@oefeg-s04.oefeg.loc> Message-ID: <21d8fa77a910c4ced0db81314add9554@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 9, 2005, at 17:50, Patrik Fältström wrote: I just want to extend this explanation by stating that DNAME was designed together with the bitstring label ideas... Those together create a tool that makes it INCREDIBLY hard to make sure the zone setup is correct, and given approximately 20% of the normal delegations are broken already today, that percentage would definitely increase given DNAME+bitstring labels. You WILL shoot yourself in your feet with tools like these. I could not agree more. Using DNAME or wildcards to kludge around deficiencies in a provisioning system or name server configuration is a recipe for trouble. This is particularly true for ENUM. It's even worse when the QNAME that matches a wildcard or gets rewritten on encountering a DNAME then gets to match against regexps in the NAPTR records. And, remember that they in all cases I have seen were designed to solve problems people had in their management / provisioning systems. Having humans by hand editing zone files using vi/emacs or whatever is over. We should not create hacks in the protocols because of "bad administration tools". I do know we have admin/delegation needs in ENUM, but let's stay with those issues, and try to keep management tool bugs out of the discussion. Indeed. Remember the saying "when the only tool you have is a hammer, every problem looks like a nail"? I fear some people are trying to solve the ENUM provisioning problem by using the DNAME and DNS wildcard hammers. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Mon, 13 Jun 2005 10:38:13 -0400 From: Bernie Hoeneisen Date: Mon, 13 Jun 2005 10:38:13 -0400 To: enum at ietf.org Subject: [Enum] Questions about EPP Poll and error definitions for draft-hoeneisen-enum-validation-epp-01 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi! After draft-hoeneisen-enum-validation-epp-01 has been accepted as an ENUM WG item in Minneapolis, I'd like to ask the Working Group for feedback concerning the following questions: 1) Do we need a standardized EPP poll message (or a similar mechanism) for informing the ENUM Registrar about a Validation which is going to expire? 2) Do we need standardized EPP error definitions for cases such as: a) validation method unknown b) validation method not allowed (for this number) c) validation expire date invalid / validation period too long ? 3) Do we need to add / change anything else? If the answer to all these questions is 'no', I guess we could start the RFC publication process... :-) cheers, Bernie PS: URLs to the current version of the draft * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.txt * http://ietf.hoeneisen.ch/draft-hoeneisen-enum-validation-epp-01.html _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Mon, 13 Jun 2005 15:40:43 -0400 From: Michael Haberler Date: Mon, 13 Jun 2005 15:40:43 -0400 To: enum at ietf.org Subject: [Enum] question about non-terminal NAPTR semantics and ENUM DDDS Message-ID: <6.2.1.2.2.20050613212428.04d01538@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO help me across the road.. Assume "E2U+foo" is defined as a non-terminal rule. we have: $Origin 5.4.3.2.1.e164.arpa. IN NAPTR 100 50 "" "E2U+foo" "" bar.com. we have application unique string '+12345' what will be the sequence of DNS lookups in the resolver - a) get_naptr(5.4.3.2.1.e164.arpa) followed by get_naptr(bar.com), or b) get_naptr(5.4.3.2.1.e164.arpa) followed by get_naptr(5.4.3.2.1.bar.com) reading 3402 section 2.2 leads me to believe it's a) thanks for the help -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Mon, 13 Jun 2005 17:58:15 -0400 From: lconroy Date: Mon, 13 Jun 2005 17:58:15 -0400 To: Michael Haberler Subject: Re: [Enum] question about non-terminal NAPTR semantics and ENUM DDDS In-Reply-To: <6.2.1.2.2.20050613212428.04d01538@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Michael, always pleased to help a poor man across the road... Yup - it's (A) [see RFC3403 section 4.1, sub-section with description of the REPLACEMENT field for the gory details]. The AUS is irrelevant for a non-terminal for a DDDS application that uses DNS as its rule base (i.e. uses NAPTRs), like E2U/ENUM. It is hard to match against an AUS when you don't have a RegExp to hold the matching pattern. This is a kind of "feature" in DDDS/NAPTR specs sent by God to keep consultants in business (and to keep implementers in Rest Homes). all the best, Lawrence On 13 Jun 2005, at 20:40, Michael Haberler wrote: help me across the road.. Assume "E2U+foo" is defined as a non-terminal rule. we have: $Origin 5.4.3.2.1.e164.arpa. IN NAPTR 100 50 "" "E2U+foo" "" bar.com. we have application unique string '+12345' what will be the sequence of DNS lookups in the resolver - a) get_naptr(5.4.3.2.1.e164.arpa) followed by get_naptr(bar.com), or b) get_naptr(5.4.3.2.1.e164.arpa) followed by get_naptr(5.4.3.2.1.bar.com) reading 3402 section 2.2 leads me to believe it's a) thanks for the help -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 13 Jun 2005 22:28:54 -0400 From: Richard Shockey Date: Mon, 13 Jun 2005 22:28:54 -0400 To: enum at ietf.org Subject: [Enum] Status of IRIS -EREG Message-ID: <6.2.1.2.2.20050613221650.042913d0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO I'd like to get some comments from the list ASAP as to the status of IRIS EREG. We agreed some time ago that this was a WG item and in fact one (1) rather large upcoming national ENUM administration is specifying IRIS-EREG as the Contact Info database of choice in its requirements documents. We've been kicking this around the list for some time without a great deal of discussion but IMHO this is important work and I'm a touch disappointed we haven't had more discussion of its applicability. http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt Personally I'd like to see this work move forward ASAP. Please post your comments. Richard Shockey, Director - Member of Technical Staff 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, 14 Jun 2005 11:37:49 -0400 From: Andrew Newton Date: Tue, 14 Jun 2005 11:37:49 -0400 To: Richard Shockey Subject: Re: [Enum] Status of IRIS -EREG In-Reply-To: <6.2.1.2.2.20050613221650.042913d0@sb7.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 13, 2005, at 10:26 PM, Richard Shockey wrote: I'd like to get some comments from the list ASAP as to the status of IRIS EREG. Richard, I've been waiting on some private comments that have yet to show up before revising this draft. But I agree, we should move forward with this sooner rather than later. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Wed, 15 Jun 2005 09:38:45 -0400 From: lconroy Date: Wed, 15 Jun 2005 09:38:45 -0400 To: "'enum at ietf.org> Subject: [Enum] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Message-ID: <30e5bff888ee593a196af6faa4b149bc@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Folks, For those of you not registered on the IETF-General list... If you are wondering why the message Enumservice registration(s) document is not an RFC yet... During IESG evaluation, we were asked to add a normative reference to this Lemonade document. We did. Now that referenced document is subject to an appeal against standardisation. As such, the Message RFC-to-be is stuck in the RFC-Editor queue waiting on the normative references to reach standardisation (or not). all the best, Lawrence Begin forwarded message: From: John C Klensin Date: 10 June 2005 19:49:17 BST To: Brian E Carpenter Cc: Randall Gellens , iesg at ietf.org, ietf at ietf.org Subject: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Brian, This is a formal appeal addressed to you as IETF Chair and, if necessary and appropriate, to the IESG, over the recent approval of draft-ietf-lemonade-mms-mapping-04.txt, "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" as a proposed standard. The appeal is self-contained and self-explanatory and proposes both specific and general remedies to the problems it identifies. It raises questions, not only of technical content, but of the procedures used to review documents within WGs as well as between WGs and other areas of expertise and the mechanisms used to determine adequacy of IETF consensus. The appeal necessarily takes no position on whether the problems demonstrated by this particular document and its approval are limited to it as an exceptional and deviant case or whether they have more general implications, but perhaps that is a topic to which the community should give some consideration in parallel with your, and the IESG's, evaluation of the specific issues raised. regards, john This is an appeal of the approval by the IESG of "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail (draft-ietf-lemonade-mms-mapping-04.txt) as a Proposed Standard. The appeal specifies that the document, as written, (i) violates an important and long-standing design principle for Internet applications protocols, does so without compelling justification, and puts existing deployed and conforming programs at risk by doing so (ii) represents a process violation in that substantive changes were made to earlier versions without review and approval by the relevant WG (iii) contains a number of other errors or probably- inappropriate specifications that strengthen the impression that the document was approved by the IESG without adequate evidence of review and consensus in the WG and cross-area review in the community It requests that the IESG suspend or withdraw the Protocol Action Notice, that it refer the document back to the relevant WG, that the conflict with existing norms either be eliminated or strong justification for retaining it be provided to the IETF community and consensus demonstrated that an exception be justified, and that the WG be asked to review the other changes suggested. ------------------------ Details: When the LEMONADE WG was formed, it was established on the basis of an agreement that it would make no substantive changes to the Internet mail fabric. That agreement was spelled out in the charter, which said: A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. That agreement may have led to less intensive review of LEMONADE products, at least including this one, by members of the community who were not particularly concerned by work the WG did within the boundaries of that agreement and the scope statements based on it. To the degree to which the WG reached conclusions that pushed the boundaries of that agreement, an unusually high burden should be placed on it, and the responsible AD(s), to ensure that any specifications that could impact the existing email fabric are carefully reviewed in the broader community. Consensus must be demonstrated that the changes are both necessary and that they will not cause harm. Discussion with working group participants and review of the WG's mailing list archives indicates that the number of comments on this document received during WG Last Call was zero. Rather than meeting that high burden of review, there is no evidence at all that this document was examined by any significant fraction of the participants in the WG. This specification violates that principle and agreement. The handling of the specification as it passed through the WG and the IESG did not demonstrate the exceptional standard of care and review that is required to avoid interfering with the Internet's email fabric. It was also procedurally irregular even within normal standards of WG and community review. In particular, substantive changes were made to the specification between the version that was Last Called (-02) and the version approved by the IESG (-04), but a review of the WG's mailing list archive does not show any indication of WG review or discussion of those changes or of the newer drafts. Indeed, a review of the WG's archives did not show evidence of any review or discussion of this document in the last year and a half. We believe that any post-Last-Call revisions to the substance of a WG-produced specification must be sent back to that working group for review and approval, especially if it is probable that the need for the changes resulted from lack of adequate WG consideration in the first place. The overall conclusion that led to this appeal was that the document is severely defective in several ways and that there is no evidence that it represents proper review or consensus in the WG or the IETF more generally. Some, but not all, of what the appeal considers to be defects might be acceptable in a Proposed Standard if they had been carefully considered as tradeoffs within relevant communities of experts, but there is no evidence --in the document or in the WG archives-- that has been done. Other defects violate important principles of Internet mail and should not be permitted except in the absence of plausible alternatives and evidence of overwhelming support. Some fractions of these issues, but by no means all of them are, at least individually and in the opinion of those lodging the appeal, consistent with the types of rough edges that can be tolerated, indeed expected, in a Proposed Standard and could be noted simply for future reference and attention if and when the specification is proposed for advancement to the next maturity level. They are included here, as noted above, largely to illustrate that review and consensus about this document has been inadequate. There appears to be significant risk of harm if this document goes forward as standards-track implementation guidance for the public Internet. On the assumption that they will be corrected by the RFC Editor's process, this appeal does not address instances of bad grammar that make the document harder to follow that is desirable. Each identified problem below is followed by a brief statement of "REMEDY", which is a recommendation about what should be done if that portion of the appeal is judged to be valid. Specifically: (1) In order to allow extensions by private agreements among interchanging parties, the original definitions of the file transfer protocol provided that commands starting in "X" would always be treated as for private use and that such commands would never be standardized. That model was carried forward into the email system as private-extension commands in SMTP and private-extension ("X-") headers in RFC 822. In each case, the principle has been that we do not standardize such headers or assign semantics to them in standards-track specifications. Not only do Email systems all over the net assume that such headers can be safely discarded, but we have, for years, told the designers of such systems that they cannot rely on the interpretation of any such header in the absence of specific bilateral agreements (and presumed authentication to at least some level) with the initiator. The requirement that X-headers be treated in a special way was relaxed with the adoption of RFC 2822, but remains controversial. At best, it is unwise to violate the principle in this document unless doing so is necessary or represents extremely well-established operational practice. This specification violates those principles. It provides, e.g., that an X-MMS-Message-ID arriving from the MMS side "SHOULD" be mapped into an identically-named header on the Internet side to facilitate interpretation and conversion of that header back into an MMS environment. The problem here is not that the MMS environment has an X-MMS-Message-ID header (their problem, not IETF's) or that a mapping is required (although that issue is discussed below), but that the recommended _Internet_ is "X-MMS-Message-ID" and not "Message-ID" or "MMS-Message-ID". While the risk of problems is probably low, the principle is important. More important, there is no justification for violating the principle: the guidance given in RFC 2822 (and 822 before it) makes it clear that the WG could simply define and register "MMS-Message-ID:", translate whatever relevant form appears in the MMS environment into it, and then translate back as needed, without violating the "X-" rule or incurring even a slight risk of conflicts or ambiguity. Similar comments apply to X-Priority. The specification indicates how the X-MMS-Priority header on the MMS side can be mapped to the widely-used "Importance:" header on the Internet side. But it then specifies that it is reasonable to map X-MMS-Priority to "X-Priority:" and then assigns specific field values to the latter. It isn't good to standardize two fields with similar semantics: doing so raises interoperability concerns as different implementations give different interpretations if both appear. Further confusion is caused by the fact that "X-Priority" appears to be, as the draft notes, a class-of-service indication rather than an end-to-end message importance indicator. But, if there is a need to standardize or recommend some sort of priority field in addition to "Importance:", the standard Internet form should not use an "X-". REMEDY: Either remove these proposed mappings or define real, standards-track, headers, presumably MMS-Message-ID and/or MMS-Priority, for use in this situation. If two Importance/Priority fields are to be recommended (or even not forbidden), specify the semantics when their values are different. (2) RFC 822 defined a syntax for use in address fields when it was desired to not enumerate the recipients, the so-called "Group syntax". That syntax was carried forward into RFC 2822. By contrast, we have generally been careful to avoid assigning semantics to information that appears in comments, or specifying the text or syntax that should appear in such comments, at least unless there are no other possibilities. This specification violates those rules: rather than using the group syntax specified in RFC 2822, it recommends (even if only as a "MAY") that a field containing a comment (but no data) be supplied instead of the group syntax. Interestingly, a reading the syntax productions of RFC 2822 (or RFC 822) indicates that To: (some comment) is equivalent to To: which is not permitted ("To:" requires an address-list) so this recommendation actually violates the standard and is hence not tolerable. In is interesting to note that, while what is done in the MMS environment does not bind what occurs on the Internet side of the gateway, the MMS specification (Section 3.2.1.2 of X.S0016-340-0) provides: In case there are only blind carbon-copy recipient(s) (Bcc:), the behavior shall be as recommended by [RFC2821], Appendix B, i.e. the originating MMS Relay/Server shall only insert an empty Bcc: header and no To: or Cc: headers. The recipient(s) shall then only be indicated in the SMTP command layer (RCPT TO:). So the 3GPP-produced specification conforming to the specifications of RFCs 2821 and 2822 while this proposed gateway specification does not. This is ironic at best. REMEDY: Preferred: Use the group syntax with an empty group. If the LEMONADE WG (or the IESG) are convinced that the "(undisclosed recipients)" comment is an appropriate substitute for the group syntax and should be permitted or encouraged, they should attempt to convince the community of that conclusion via an update to RFC 2822, not by (deliberately or accidentally) concealing the change in this type of document. Alternate 1: Use a "Bcc:" field that is empty or contains only a comment, a form that is permitted by both RFC 822 and RFC 2822. Alternate 2: Do not generate recipient fields. This is permitted by RFC 2822 but not by RFC 822 and is hence probably the least desirable valid option in terms of interoperability. While a case can be made for any of the three choices, the choice made in the document is violation of the existing standards (and their predecessors) and must not be specified without opening and updating those standards. (3) The "contemporary email systems" principle of RFC 2821 is violated. That principle suggests and requires that no new features or capabilities be added to unextended environments (i.e., environments conforming to RFC 821 rather than 2821). The current draft attempts to support the RFC 821 level of specification where possible, and the 2821 level elsewhere. This makes makes the specification far more complex and convoluted than it would be if the mapping that is specified simply required 2821-based gateways. This extra complexity, indeed any excess complexity, is undesirable in an Internet protocol unless it is required by some documented situation or constraint. This document does not contain any evidence of such constraints, nor does there appear to be any evidence of discussion of, much less consensus about, such constraints in the WG email archives. REMEDY: Remove all support for, and discussion of, RFC 821-only email. (4) Under "Sender address" in Section 2.1.3.2 of the specification, there is a fairly convoluted discussion of hidden senders and untrusted relays and receiving servers. Again, this violates a long-standing, although not specifically standardized, principle of Internet mail. Stated simply, if one doesn't trust a relay or any subsequent server in the path (with the understanding that this raises all of the complicated issues about what such "trust" actually means), one should not send the message. This section can be read as attempting to standardize a bad practice. More generally, it is not clear that this document is either a necessary or appropriate place to try to describe or resolve the complex trust issues involved in mail relaying, even though the gateway aspect further complicates those issues. The right solution, actually suggested elsewhere in the document, is to avoid all attempts to support or guarantee hidden senders. REMEDY: See (6), below. (5) Under "Content type" in Section 2.1.3.2 of the specification, reference is made to conversions being done without "significant loss of content". It is not at all clear what "loss of content" means, or how "significant" is to be interpreted. More broadly, there have been extended, and sometimes quite heated, discussions in the community during the last few years about midstream conversions and content alterations of various sorts (discussions about OPES, VPIM, the FAX WG's "CONNEG" features, and ongoing discussions about use of message submission come to mind). Given those discussions, it is quite surprising that the language in this document, which seems to suggest "do whatever you want based on your understanding of what the Internet supports and what you think isn't too damaging", could move through the WG and be accepted by the IESG without comment. At as minimum, this is more evidence that the document was never really reviewed. REMEDY: Perhaps the WG intends "...loss of information" rather than "...loss of content"? "Significant" would still be an issue, but the intent would be considerably more clear. The spirit of the language about gateways in RFC 2821 and general assumptions about desirable practice in the area suggests that this specification should permit no conversions that are not strictly necessary to make the message conform with standards on the side of the gateway to which it is being introduced and should make provision for documenting the conversions that are made. (6) In section 2.1.3.2.2, under "Sender visibility", the specification says "Support for sender address hiding is not included in this version of the mapping document". However, the discussion of "sender address" in 2.1.3.2 specifies how to hide a sender address. At best, this is inconsistent. More generally, invisible sender addresses are an opportunity for spammers, would add to the difficulties of some proposed anti-spam techniques, and are a fairly radical departure from the Internet mail architecture. Not supporting them seems appropriate but, if LEMONADE ever wants to open that door, it should be opened as part of an update to base Internet mail specifications, not through a discussion of syntax in this document. REMEDY: Remove all syntax for sender address hiding and all discussion of the topic other than the current "does not support" text or equivalent. This includes removing the much weaker recommendation, in the security considerations section, that sender identity hiding not be attempted across carrier networks. If it is desired to say anything beyond "does not support", it should be said as part of a clear explanation of why support for this type of option is not practical. (7) In Section 1.3 of the specification, a definition is given for "Gateway Function". With all respect to ongoing efforts to better-define the Internet's email model, there is a fairly extensive definition of gateways and gateway functions in RFC 2821 and the text here is inconsistent with this definition. Going beyond matters of the terminology in this document, the provisions of section 2.1.2 of the specification make use of the term "Relay/Server" inappropriate. If the relevant system does format, media, or transport conversion, it is a Gateway as defined in RFC 2821. REMEDY: As with the group syntax, if the LEMONADE WG believes that current, established, definitions are inadequate, the correct solution is to generate a proposal to update RFC 2821. The definition in this document should either refer to RFC 2821 (or, where applicable, RFC 2822) or be strictly consistent with them. (8) There is an assertion in section 2.1.1 of the specification about the requirements of SMTP with regard to return paths. The assertion in the example is incorrect: SMTP _requires_ null return paths only for error messages involving non-delivery. The extended requirement that null addresses be used for automatically-generated messages occurs elsewhere or are covered by MAY statements or the equivalent in RFC 2821. REMEDY: Correct this reference. (9) This specification provides, in the table of section 2.1.3.1, for a "Resent-Count:" header in Internet mail. This header is not defined in RFC 2822, which is usually assumed to be normative for all "Resent-" headers and their relationships. More important, it violates the important design principle that one should not provide both a list of things that can be counted and the count, lest the two counts disagree. If it is going to do so, text is needed as to what occurs when the number of Resent field sets and the Resent-count differ. Since Resent-count does not appear in 2822, it is reasonable to anticipate that some, probably many, systems will not notice its presence and hence will not update it when the add Resent- fields. It seems completely out of scope for this document unless it really is going to define a "Resent-count:" field (there is no definition at present), but it is not clear how a gateway might calculate such a field given the amount of flexibility in RFC 2822 about which of the Resent- fields may appear and in what combinations. In the general case, if any Resent- fields appear, the value of Resent-count could be reliably bounded only by 1 and the total number of such fields. REMEDY: Drop "Resent-count:" entirely in the absence of compelling need and explanation. If that explanation is provided, it should be explicit about the relationship between the count of Resent field sets and the counter if they happen to differ. It is unlikely that an adequate definition is possible in the absence of an update to RFC 2822 and mechanisms for changing existing deployed practice, so such definition is presumably well outside the scope of the LEMONADE WG. (10) In Section 2.1.3.2.2, there is a subsection titled "Resending/Forwarding" that discusses quoting of message sections and message encapsulation. The quoting mechanism that is discussed has never been standardized because, while there seems to have been some convergence in the last few years, the community has never been able to reach consensus on the subject. The section appears to be completely confused about the relationships among quoting or excerpting and embedding. More important, the encapsulation norm cited, RFC 934, has been generally considered obsolete (even though still widely used) since MIME and its encapsulation mechanisms came into general use. The discussion of that referenced document also appears normative although the reference is listed as informative (see item (14), below. There is also a fairly extensive discussion of forwarding and resending in RFC 2822 and the material in this section does not appear to be completely consistent with it. Similar comments apply to the discussion of Resent- and Received- headers in the next section. This document should cite RFC 2821 or 2822 as appropriate, not try to paraphrase their recommendations (or requirements) and get it even slightly wrong. REMEDY: This document should be rewritten to avoid general discussions and tutorials of aspects of Internet mail that are outside the scope of the specific conversions or mappings being specified. If it is necessary, in the opinion of the WG, to discuss these additional issues, the discussions should confine themselves to agreed-up best practices only or LEMONADE should extend its charter to include discussion and standardization of common, but currently non-standard, practices in Internet mail and then follow up with a document along those lines. (11) In section 2.1.3.3.1 (apparently), there is a discussion of "Sensitivity" that indicates that an "appropriate extended error response code" be used. If this is a protocol specification, it should specify the code(s) to be used or how the implementer should determine such code(s). Without that level of specification, this document is an invitation to interoperability problems. REMEDY: Where codes are intended, they should be specified. (12) In section 3, it is asserted that SMTP Authentication protects against misidentification of message source. SMTP Authentication protects only against misidentification of the most-recent sender and has little to do with message sources except through out of band (whether explicit or implicit) trust chains. REMEDY: Correct this text. (13) The IANA Considerations section, section 4, indicates that no actions are requested of IANA. However, this specification introduces several new headers into the Internet mail environment. Those headers should be registered in the registry specified in RFC 4021. REMEDY: Correctly specify the IANA actions and explicitly identify the new headers. (14) While this document specifies in its introduction that an understanding of the MMS specifications is required to read and understand it, the MMS specifications are all listed as informative, not normative. Even if that text did not appear, the notion of a gateway specification that did not require an understanding of the definitions of the systems on both sides would be, at best, very unusual. "You need to understand that in order to read and implement this" is the very essence of a normative reference. Apparently neither the WG nor the IESG did an adequate review to determine which references were actually normative and which were not. There are fairly well-defined procedures for normative references to the documents of other standards bodies in IETF standards-track specifications; there is no evidence that they have been followed here. The reference to RFC 934 raises an additional issue: that specification's maturity level is listed as "unknown". While RFC 3967 provides a mechanism for referring normatively to documents at a "lower level", it is not clear how, or if, one can refer to a document with status "unknown". Even if RFC 3967 is construed to treat "unknown" as equivalent to the lowest permitted reference level, there is no evidence in the WG archives or the Last Call for this document that the procedures it specifies have been followed here. REMEDY: Get rid of the reference to RFC 934 by cleaning up the material discussed under (10) or, if it is to be retained, clarify its status (presumably requiring an IETF Last Call and probably a new document). Move the MMS references to the "normative" section and make sure that all requirements for references to such documents have been met. (15) In Section 3 (Security Considerations), there is a paragraph that begins "Since MMS does not include a clear separation between in-transit envelope and message content, there are increased risks of unauthorized disclosure of information, and additional challenges in protecting data. For example, Bcc recipients do not normally appear in the message content, only in the envelope; care MUST be taken in...". This is at variance with the current (cited) version of the MMS specification, which appears to specify what should be done in this case very clearly, where it says: In case there are both To: / Cc: and Bcc: recipients, the Bcc: headers shall be removed by the originating MMS Relay/Server and the Bcc: recipients shall only be indicated in the SMTP command level (RCPT TO:). This is in accordance with the functionality recommended by [RFC2821], Appendix B. That statement is not only fairly clear, it is consistent with the specification in RFC 2821, which the document itself is not. Whether a MUST-level requirement should appropriately appear in an example embedded in the middle of the security considerations section is an issue we will leave for the editorial process, but, again, it suggests a lack of adequate review. REMEDY: Since the MMS specification is well-aligned with the requirements of RFC 2821 and 2822, this text and recommendation should be aligned with it. Gateways should make as few conversations, and do as little damage, as possible. (16) There are a number of mapping issues about which the document appears to hand-wave, indicating that something MAY be done but without any specification as to how to do it. The issue is somewhat similar to that of (11), above, but involves fundamental design principles that the document does not address. For example, the document indicates that, if a Message-ID is not present, "...the value of the 'X-Mms-Message-Id:' header MAY be used" to create one. But X-MMS-Message-ID doesn't obey the syntax rules for Message-IDs, so, if traceability is desired, this document needs to specify how the Message-ID mapping is accomplished. If traceability is not important, then the document should probably just indicate that a Message-ID MUST be made up (a requirement of RFC 2822) and that any handy information, including the contents of an X-MMS-Message-ID header if present MAY optionally be used to create it, but that the information will not be useful for tracing messages or their relationships. Similar issues arise with addresses. It is common in the MMS environment for addresses to be E.164-format telephone numbers, without domain names. The MMS specification makes a recommendation about how to handle this but it may or may not be appropriate in all cases. Following precedent in other areas, it may be appropriate is insert the domain of the gateway, thereby making the assumption (faulty in X.400 and faulty here) that forward and reverse paths for these messages across gateways are necessarily equivalent. Note that injecting an address without a fully-qualified domain name into the Internet violates RFC 2821 and RFC 2822. REMEDY: The document needs to be specific about mappings when it is intended that they be useful (e.g., for routing of messages or message tracing or linking) and to be explicit when the mappings are for informal documentation purposes or conformance on one side of the gateway only. If domain names are made up (e.g., by inserting a gateway domain), the document needs to discuss the security and operational implications of doing so. (17) Another paragraph of the Security Considerations section reads: It is possible to hide the sender's identity from non-recipients using anonymous remailers. It is hard to hide the sender's identity from recipients when the mail is cryptographically signed. In view of anti-spam measures it may be undesirable to hide the sender's identity. This borders on the silly, since one can eliminate the particular identity-revealing problem associated with signed mail by simply removing the signature. More important, it is not clear why a general discussion of anonymous remailers and similar tools belongs in this document unless the WG or editor are just trying to tell us how much they know (and the editor in this case knows a great deal more than this). The document repudiates sender-hiding (see (6) above); this is gateway specification should focus on issues associated with the gateway, leaving general issues of anonymity in Internet Mail to other specifications. REMEDY: Remove this text unless there is a substantive reason to include it. If there is, it is going to need significant reworking including, presumably, addressing the case of address hiding or exposure with encrypted message body parts that might contain full RFC 822/ 2822 headers. (18) The listed of bulleted "existing mechanisms" in the Security Considerations section is deeply flawed. As noted in (12) above, SMTP Authentication does not "protect against misidentification of message source", it merely protects against spoofing of the previous-hop server. Anything more requires trust assumptions or agreements about the behavior of that server that are not covered in this document (or in the SMTP AUTH one). The document is correct in stating that IPSEC and SSH or TLS are useful only in protecting against in-transit modification between adjacent servers, but, if it is going to make those statements, it should discuss the limitations of those techniques in an email environment and the particular difficulties associated with them on the two sides of a gateway. To do otherwise appears to be a pretense of security and completeness to pad out the document, one that can be misleading to readers (whether implementers or users). It also recommends use of PGP or S/MIME to protect message contents. This is normally a good recommendation for email, since the techniques work end to end rather than hop-by-hop. However, there is a long history of problems when PGP and S/MIME message privacy and message integrity mechanisms cross gateway boundaries between systems of a rather different character, and it is irresponsibile to recommend those techniques without discussing those potential problems or demonstrating an understanding of them and providing a pointer to the places where they have been discussed (such as RFC 2480). REMEDY: The Security Considerations generally, and this material in particular, should be updated to reflect operational realities and the actual applicability and utility of techniques in a gateway environment. (19) It is possible that this should be viewed as a primarily an editorial comment, but, at this point, we understand how to construct and write a mail gateway specification. RFC 2821 outlines the basic requirements and we have worked examples for even more complex cases than this one, e.g., in RFCs 2156 and 2157 and the documents leading up to them. We start with one protocol and definition as input, figure out which of its components can be mapped accurately to the other side in terms of their semantics, specify those mappings, and then examine the components that cannot be mapped exactly and figure out what should be done about them -- either dropping them or producing the nearest possible semantics on the receiving side while continuing to conform to all of the requirements of the receiving side. The process is then repeated with the sides reversed, and then both sides are reviewed to be sure that any traceability or "reply" considerations are satisfied. It is key to gateway specification models that the document make no assumption that the behavior of client or end systems that receive or send mail that will ultimately pass through the gateway change in any way. If such changes are desired, they must be pursued independently, explicitly, and with due consideration of the likelihood of effective deployment, with the organizations who have change control of the individual systems and protocols that feed into the gateway. Unless those other groups can somehow be expected to be able to instantly make and deply those changes, the gateway specification must be [still] written on the assumption that the changes will not occur or will not be ubiquitious. Obviously those constraints make the job of the gateway-specifier harder, but any other assumption is just not operationally plausible, especially --as is typically the case-- the end systems assume that they are communicating within their own environments rather than through a gateway. This document does not convey the impression that the above model was followed and all of the steps carefully taken. In particular, there are mismatches in semantics and mappings that impact traceability or replies that are not properly accounted for. Some of those are described above. Others involve skimming over serious semantic mismatches between the "Disposition-Notification-To:" header specified in [MDN] and the "X-MMS-Read-Reply" header. "Replacing" one field with the other requires pulling information from elsewhere, and the document provides no guidance as to how to do that. A more systematic analysis along the lines above would, presumably, have at least identified the problem and called for some discussion. Similarly, since the document is not written clearly as a gateway specification --with no assumption that it can change the downstream or upstream environments on either side-- it is muddled about whether the MDNs it describes are generated by the gateway or whether they are generated in the MMS (or Internet mail) environments respectively and then translated by the gateway. That muddle leads to, e.g., a situation in which the specification appears to call for mapping of a Disposition-Notification-To field in an MMS-generated MDN to an Internet message, but that field will not appear in an MMS-environment MDN. REMEDY: Revoke the Protocol Action notice and return this document to the WG, insisting that all of the substantive points above be addressed and that the document not be forwarded back to the IESG until there is evidence of adequate review and consensus about the results. ------------- In several, but certainly not all, of the cases listed above, there would be little basis for appeal if there were evidence that the WG had carefully considered the issues, the tradeoffs, and the possible impact, consulted as needed with others about them, and then arrived at informed conclusions. However, there is little or no evidence of such consideration and deliberation on the part of the WG, at least since version -02 of the relevant document was posted. In other cases, there has been a clear failure of adequate review and justification for changes to the Internet's email fabric and its definitions, changes that go well beyond the agreed-upon scope of the WG. In accepting this document for publication as a standards-track specification, especially after many of the above issues had been pointed out to it, the IESG either failed in its responsibility to determine the existence and adequacy of community consensus or chose to substitute its judgment for that of a largely-silent WG and broader community without making an attempt to raise these issues when them. In either case, the decision to accept this document, in its present form, as a Proposed Standard should be withdrawn and a review and revision process initiated. It is important to stress that this appeal, however lengthy and detailed, is not a comprehensive review of the document and, hence, that "fix the points listed in the appeal" is not an adequate or appropriate remedy. It would be especially inappropriate if that instruction were delivered to the document editor as a matter for negotiation with the IESG. Instead, the details above should be considered as nothing more than a set of examples whose cumulative impact should be to demonstrate that this document should be returned to the WG with instructions to perform the level of analysis, and guarantee the level of review, that should have preceeded submission to the IESG as a WG document._______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Wed, 15 Jun 2005 12:44:14 -0400 From: "Fullbrook Kim \(UK\)" Date: Wed, 15 Jun 2005 12:44:14 -0400 To: Subject: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624014D41BE@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: RO Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 15 Jun 2005 13:05:52 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 15 Jun 2005 13:05:52 -0400 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <34DA635B184A644DA4588E260EC0A25A0A6CB222@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Kim: I'm not sure I agree with your assessment of what gets broken. My belief is that clients compliant with RFC 3761 should process non-terminal NAPTRs. The matching on a service within E2U such as SIP should occur on terminal NAPTRs. There will be a need to support the new enum services of "user" and "carrier". As to the benefits to carriers, our motivator is NOT primarily privacy, it's effective interconnection. User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. Although the I-D did not go into it, there are techniques for controlling access to actual routing data or offering up different IP points of interface (e.g. different Session Border Controller point) to different carriers. How open interconnection will be to non-carrier parties is a business decision for individual carriers but we believe the proposed implementation can support whatever is decided. Some kind of ENUM will be used for interconnection as voice moves to being an application on IP networks. Our preference is that this implementation be synergistic with end user ENUM. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK) Sent: Wednesday, June 15, 2005 12:44 PM To: enum at ietf.org Subject: [Enum] Benefits of "Carrier" / "User" enumservices Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ 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 Jason_Livingood@cable.comcast.com Wed, 15 Jun 2005 14:19:33 -0400 From: "Livingood, Jason" Date: Wed, 15 Jun 2005 14:19:33 -0400 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <6EEEACD9D7F52940BEE26F5467C02C735EDCFF@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO I concur with Penn's entire response, and specifically on the reasoning / drive behind the use of so-called carrier ENUM. To add another data point... As a carrier, our interest is in using ENUM-related specifications and capitalizing on / co-existing with end-user, public ENUM. Part of that means easy, open interconnection, of which public ENUM can play a very important role. Access is only a concern for actual media & signaling traffic, and access priviliges can be addressed in SIP proxies, media gateways, softswitches, session border controllers, etc. depending upon a particular carrier's architecture and their business model. We are not too concerned with other carriers knowing what numbers we have for two reasons: (1) that is the entire objective - to share such information so that we can interconnect and (2) this information is already available to other carriers through shared PSTN-oriented routing databases, such as the NPAC (LNP) in North America. Jason Livingood > The second concern is how the "Carrier" enumservice meets the > needs of telcos. As I understand it, the major driver for > introduction of Carrier enum is to address privacy concerns. > Telcos don't want their enum data available for inspection > and attack by everyone on the Internet and the carrier enum > concept addresses this by making the data inaccessible except > to authorised queries. However, the use of the Carrier > enumservice only shifts the DNS query to a different DNS > domain on the Internet and makes no difference to the privacy > or access privileges. > It's not clear to me what the benefit of "Carrier" > enumservice is for data privacy compared to the case of not > having it. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 15 Jun 2005 15:05:25 -0400 From: "Stastny Richard" Date: Wed, 15 Jun 2005 15:05:25 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF5E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Penn, a minor correction: you are correct that according to RFC 3761 a client should be able to process non-terminal NAPTRs as defined, which means NAPTRs having only "E2U" in the enumservice field, without any additional enumservices defined. The original intention was that you query the domain given for NAPTRs and THEN decide which enumservice to use. The definitions of the enumservices "user" and "carrier" you draft is NOT according to the template in RFC 3761, because you MUST define the URIs valid for this enumservice (and not N/A), as Lawrence already pointed out. In addition, even if clients have implemented the capability to use non-terminal NAPTRs, up to now they need not to be able to understand and interpret any enumservice defined (only they ones they can handle) With your proposal any ENUM-client not understanding the enumservices "user" and "carrier" will not be able to retreive any enumservice at all. This is of course also true for the proposal I made using for this purpose terminal NAPTRs with enumservice "enum:tel" and carrier:tel", using the phone-context in tel: as apex for the new tree. but this proposal has other advantages. But one should be careful in saying any client in the MUST support this because this is already defined in RFC 3761. regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO Gesendet: Mi 15.06.2005 19:05 An: Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Kim: I'm not sure I agree with your assessment of what gets broken. My belief is that clients compliant with RFC 3761 should process non-terminal NAPTRs. The matching on a service within E2U such as SIP should occur on terminal NAPTRs. There will be a need to support the new enum services of "user" and "carrier". As to the benefits to carriers, our motivator is NOT primarily privacy, it's effective interconnection. User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. Although the I-D did not go into it, there are techniques for controlling access to actual routing data or offering up different IP points of interface (e.g. different Session Border Controller point) to different carriers. How open interconnection will be to non-carrier parties is a business decision for individual carriers but we believe the proposed implementation can support whatever is decided. Some kind of ENUM will be used for interconnection as voice moves to being an application on IP networks. Our preference is that this implementation be synergistic with end user ENUM. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK) Sent: Wednesday, June 15, 2005 12:44 PM To: enum at ietf.org Subject: [Enum] Benefits of "Carrier" / "User" enumservices Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ 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 ppfautz@att.com Wed, 15 Jun 2005 15:12:50 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 15 Jun 2005 15:12:50 -0400 To: "Stastny Richard" Subject: RE: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <34DA635B184A644DA4588E260EC0A25A0A6CB52B@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard. Fair enough. I confess to some uncertainty re how to populate the URI part of the template for non-terminals. I toyed with something like "all URI schemes registered under any other enumservice." Would that have been better? Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, June 15, 2005 3:08 PM To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Penn, a minor correction: you are correct that according to RFC 3761 a client should be able to process non-terminal NAPTRs as defined, which means NAPTRs having only "E2U" in the enumservice field, without any additional enumservices defined. The original intention was that you query the domain given for NAPTRs and THEN decide which enumservice to use. The definitions of the enumservices "user" and "carrier" you draft is NOT according to the template in RFC 3761, because you MUST define the URIs valid for this enumservice (and not N/A), as Lawrence already pointed out. In addition, even if clients have implemented the capability to use non-terminal NAPTRs, up to now they need not to be able to understand and interpret any enumservice defined (only they ones they can handle) With your proposal any ENUM-client not understanding the enumservices "user" and "carrier" will not be able to retreive any enumservice at all. This is of course also true for the proposal I made using for this purpose terminal NAPTRs with enumservice "enum:tel" and carrier:tel", using the phone-context in tel: as apex for the new tree. but this proposal has other advantages. But one should be careful in saying any client in the MUST support this because this is already defined in RFC 3761. regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO Gesendet: Mi 15.06.2005 19:05 An: Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Kim: I'm not sure I agree with your assessment of what gets broken. My belief is that clients compliant with RFC 3761 should process non-terminal NAPTRs. The matching on a service within E2U such as SIP should occur on terminal NAPTRs. There will be a need to support the new enum services of "user" and "carrier". As to the benefits to carriers, our motivator is NOT primarily privacy, it's effective interconnection. User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. Although the I-D did not go into it, there are techniques for controlling access to actual routing data or offering up different IP points of interface (e.g. different Session Border Controller point) to different carriers. How open interconnection will be to non-carrier parties is a business decision for individual carriers but we believe the proposed implementation can support whatever is decided. Some kind of ENUM will be used for interconnection as voice moves to being an application on IP networks. Our preference is that this implementation be synergistic with end user ENUM. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK) Sent: Wednesday, June 15, 2005 12:44 PM To: enum at ietf.org Subject: [Enum] Benefits of "Carrier" / "User" enumservices Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ 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 Richard.Stastny@oefeg.at Wed, 15 Jun 2005 15:29:01 -0400 From: "Stastny Richard" Date: Wed, 15 Jun 2005 15:29:01 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF5F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Penn, I am not the one to answer you THIS question ;-) but IMHO we have here a catch 22 because in the replacement field there cannot be an URI at all, the enumservice template is only valid for flag 'u' and not for non-terminal NAPTRs regards Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] Gesendet: Mi 15.06.2005 21:12 An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Richard. Fair enough. I confess to some uncertainty re how to populate the URI part of the template for non-terminals. I toyed with something like "all URI schemes registered under any other enumservice." Would that have been better? Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, June 15, 2005 3:08 PM To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Penn, a minor correction: you are correct that according to RFC 3761 a client should be able to process non-terminal NAPTRs as defined, which means NAPTRs having only "E2U" in the enumservice field, without any additional enumservices defined. The original intention was that you query the domain given for NAPTRs and THEN decide which enumservice to use. The definitions of the enumservices "user" and "carrier" you draft is NOT according to the template in RFC 3761, because you MUST define the URIs valid for this enumservice (and not N/A), as Lawrence already pointed out. In addition, even if clients have implemented the capability to use non-terminal NAPTRs, up to now they need not to be able to understand and interpret any enumservice defined (only they ones they can handle) With your proposal any ENUM-client not understanding the enumservices "user" and "carrier" will not be able to retreive any enumservice at all. This is of course also true for the proposal I made using for this purpose terminal NAPTRs with enumservice "enum:tel" and carrier:tel", using the phone-context in tel: as apex for the new tree. but this proposal has other advantages. But one should be careful in saying any client in the MUST support this because this is already defined in RFC 3761. regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO Gesendet: Mi 15.06.2005 19:05 An: Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Kim: I'm not sure I agree with your assessment of what gets broken. My belief is that clients compliant with RFC 3761 should process non-terminal NAPTRs. The matching on a service within E2U such as SIP should occur on terminal NAPTRs. There will be a need to support the new enum services of "user" and "carrier". As to the benefits to carriers, our motivator is NOT primarily privacy, it's effective interconnection. User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. Although the I-D did not go into it, there are techniques for controlling access to actual routing data or offering up different IP points of interface (e.g. different Session Border Controller point) to different carriers. How open interconnection will be to non-carrier parties is a business decision for individual carriers but we believe the proposed implementation can support whatever is decided. Some kind of ENUM will be used for interconnection as voice moves to being an application on IP networks. Our preference is that this implementation be synergistic with end user ENUM. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK) Sent: Wednesday, June 15, 2005 12:44 PM To: enum at ietf.org Subject: [Enum] Benefits of "Carrier" / "User" enumservices Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ 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 sdlind@att.com Wed, 15 Jun 2005 16:09:04 -0400 From: "Lind, Steven D, ALABS" Date: Wed, 15 Jun 2005 16:09:04 -0400 To: "Stastny Richard" Subject: RE: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO It seems to that if this is the case, the template does not cover all the cases described in RFC 3761. Do we need a second template for non-terminal NAPTRs or change the existing template (and associated instructions) to incorporate both types of NAPTRs. Steve Lind -------------------------------------------------------------------------------- Steven D. Lind Tel: 973-236-6787 180 Park Avenue Fax: 360-343-2875 Room A201 sdlind at att.com Florham Park, NJ 07932 -------------------------------------------------------------------------------- > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of > Stastny Richard > Sent: Wednesday, June 15, 2005 3:32 PM > To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org > Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices > > > Penn, > > I am not the one to answer you THIS question ;-) > but IMHO we have here a catch 22 > because in the replacement field there cannot be > an URI at all, the enumservice template is > only valid for flag 'u' and not for non-terminal NAPTRs > > regards > Richard > > ________________________________ > > Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] > Gesendet: Mi 15.06.2005 21:12 > An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org > Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices > > > > Richard. > Fair enough. I confess to some uncertainty re how to populate the URI > part of the template for non-terminals. I toyed with > something like "all > URI schemes registered under any other enumservice." Would that have > been better? > > Penn > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Wednesday, June 15, 2005 3:08 PM > To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org > Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices > > Penn, > > a minor correction: > you are correct that according to RFC 3761 a client should be able > to process non-terminal NAPTRs as defined, which means NAPTRs > having only "E2U" in the enumservice field, without any additional > enumservices defined. The original intention was that you query > the domain given for NAPTRs and THEN decide which enumservice > to use. > > The definitions of the enumservices "user" and "carrier" you draft > is NOT according to the template in RFC 3761, because you MUST define > the URIs valid for this enumservice (and not N/A), as Lawrence already > pointed out. > > In addition, even if clients have implemented the capability to use > non-terminal NAPTRs, up to now they need not to be able to understand > and interpret any enumservice defined (only they ones they can handle) > > With your proposal any ENUM-client not understanding the enumservices > "user" and "carrier" will not be able to retreive any enumservice at > all. > > This is of course also true for the proposal I made using for this > purpose > terminal NAPTRs with enumservice "enum:tel" and carrier:tel", > using the phone-context in tel: as apex for the new tree. > but this proposal has other advantages. > > But one should be careful in saying any client in the MUST > support this > because this is already defined in RFC 3761. > > regards > Richard > > > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO > Gesendet: Mi 15.06.2005 19:05 > An: Fullbrook Kim (UK); enum at ietf.org > Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices > > > > Kim: > > I'm not sure I agree with your assessment of what gets > broken. My belief > is that clients compliant with RFC 3761 should process non-terminal > NAPTRs. The matching on a service within E2U such as SIP > should occur on > terminal NAPTRs. There will be a need to support the new enum services > of "user" and "carrier". > > As to the benefits to carriers, our motivator is NOT > primarily privacy, > it's effective interconnection. User ENUM in many countries > requires end > user opt-in and may give the end user the right to select the Tier 2 > that hosts the terminal NAPTR records. These constraints are > problematic > for interconnection which requires registration for all served numbers > and carrier control of Tier 2 to ensure reliability. > > Although the I-D did not go into it, there are techniques for > controlling access to actual routing data or offering up different IP > points of interface (e.g. different Session Border Controller > point) to > different carriers. How open interconnection will be to non-carrier > parties is a business decision for individual carriers but we believe > the proposed implementation can support whatever is decided. > > Some kind of ENUM will be used for interconnection as voice moves to > being an application on IP networks. Our preference is that this > implementation be synergistic with end user ENUM. > > Penn Pfautz > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of > Fullbrook Kim (UK) > Sent: Wednesday, June 15, 2005 12:44 PM > To: enum at ietf.org > Subject: [Enum] Benefits of "Carrier" / "User" enumservices > > Having read the draft-pfautz-lind-enum-carrier-user-00.txt > and discussed > it with colleagues, I have some concerns about its drawbacks and am > struggling to see what benefits it offers. > > It may be that I've missed a key point or mis-understood > something so I > would be grateful if someone can assist with explanation and > clarification. > > The first concern is that if this registration and > accompanying data is > introduced, its implications about how DNS data is structured breaks > existing enum resolvers. For example, when a resolver queries the > e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all > the NAPTR records matching this number and then looks for a > match on the > enumservices "E2U" and "SIP". This matching will fail as only NAPTR > records with "Carrier" or "User" are present and the call fails. To > introduce these enumservices successfully requires all existing enum > resolvers to be re-implemented. The resolver has to first look for a > match on "Carrier" or "User" enumservice, retrieve more > NAPTRs and then > look for a match on "E2U" and "SIP". > > The second concern is how the "Carrier" enumservice meets the needs of > telcos. As I understand it, the major driver for introduction > of Carrier > enum is to address privacy concerns. Telcos don't want their enum data > available for inspection and attack by everyone on the > Internet and the > carrier enum concept addresses this by making the data inaccessible > except to authorised queries. However, the use of the Carrier > enumservice only shifts the DNS query to a different DNS domain on the > Internet and makes no difference to the privacy or access privileges. > It's not clear to me what the benefit of "Carrier" enumservice is for > data privacy compared to the case of not having it. > > Kim Fullbrook > > ===================================================== > This electronic message contains information from O2 which may be > privileged or confidential. The information is intended to be for the > use of the individual(s) or entity named above. If you are not the > intended recipient be aware that any disclosure, copying > distribution or > use of the contents of this information is prohibited. If you have > received this electronic message in error, please notify us > by telephone > or email (to the numbers or address above) immediately. > ===================================================== > > > _______________________________________________ > 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 Richard.Stastny@oefeg.at Wed, 15 Jun 2005 16:15:30 -0400 From: "Stastny Richard" Date: Wed, 15 Jun 2005 16:15:30 -0400 To: "Lind, Steven D, ALABS" Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF60@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Steve, This is one possibility and should be done anyway, but this will take time The other (easier and faster) possibility is to stick with terminal NAPTRs if this also solves your problem regards Richard ________________________________ Von: Lind, Steven D, ALABS [mailto:sdlind at att.com] Gesendet: Mi 15.06.2005 22:08 An: Stastny Richard; Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices It seems to that if this is the case, the template does not cover all the cases described in RFC 3761. Do we need a second template for non-terminal NAPTRs or change the existing template (and associated instructions) to incorporate both types of NAPTRs. Steve Lind -------------------------------------------------------------------------------- Steven D. Lind Tel: 973-236-6787 180 Park Avenue Fax: 360-343-2875 Room A201 sdlind at att.com Florham Park, NJ 07932 -------------------------------------------------------------------------------- > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of > Stastny Richard > Sent: Wednesday, June 15, 2005 3:32 PM > To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org > Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices > > > Penn, > > I am not the one to answer you THIS question ;-) > but IMHO we have here a catch 22 > because in the replacement field there cannot be > an URI at all, the enumservice template is > only valid for flag 'u' and not for non-terminal NAPTRs > > regards > Richard > > ________________________________ > > Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] > Gesendet: Mi 15.06.2005 21:12 > An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org > Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices > > > > Richard. > Fair enough. I confess to some uncertainty re how to populate the URI > part of the template for non-terminals. I toyed with > something like "all > URI schemes registered under any other enumservice." Would that have > been better? > > Penn > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Wednesday, June 15, 2005 3:08 PM > To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org > Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices > > Penn, > > a minor correction: > you are correct that according to RFC 3761 a client should be able > to process non-terminal NAPTRs as defined, which means NAPTRs > having only "E2U" in the enumservice field, without any additional > enumservices defined. The original intention was that you query > the domain given for NAPTRs and THEN decide which enumservice > to use. > > The definitions of the enumservices "user" and "carrier" you draft > is NOT according to the template in RFC 3761, because you MUST define > the URIs valid for this enumservice (and not N/A), as Lawrence already > pointed out. > > In addition, even if clients have implemented the capability to use > non-terminal NAPTRs, up to now they need not to be able to understand > and interpret any enumservice defined (only they ones they can handle) > > With your proposal any ENUM-client not understanding the enumservices > "user" and "carrier" will not be able to retreive any enumservice at > all. > > This is of course also true for the proposal I made using for this > purpose > terminal NAPTRs with enumservice "enum:tel" and carrier:tel", > using the phone-context in tel: as apex for the new tree. > but this proposal has other advantages. > > But one should be careful in saying any client in the MUST > support this > because this is already defined in RFC 3761. > > regards > Richard > > > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO > Gesendet: Mi 15.06.2005 19:05 > An: Fullbrook Kim (UK); enum at ietf.org > Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices > > > > Kim: > > I'm not sure I agree with your assessment of what gets > broken. My belief > is that clients compliant with RFC 3761 should process non-terminal > NAPTRs. The matching on a service within E2U such as SIP > should occur on > terminal NAPTRs. There will be a need to support the new enum services > of "user" and "carrier". > > As to the benefits to carriers, our motivator is NOT > primarily privacy, > it's effective interconnection. User ENUM in many countries > requires end > user opt-in and may give the end user the right to select the Tier 2 > that hosts the terminal NAPTR records. These constraints are > problematic > for interconnection which requires registration for all served numbers > and carrier control of Tier 2 to ensure reliability. > > Although the I-D did not go into it, there are techniques for > controlling access to actual routing data or offering up different IP > points of interface (e.g. different Session Border Controller > point) to > different carriers. How open interconnection will be to non-carrier > parties is a business decision for individual carriers but we believe > the proposed implementation can support whatever is decided. > > Some kind of ENUM will be used for interconnection as voice moves to > being an application on IP networks. Our preference is that this > implementation be synergistic with end user ENUM. > > Penn Pfautz > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of > Fullbrook Kim (UK) > Sent: Wednesday, June 15, 2005 12:44 PM > To: enum at ietf.org > Subject: [Enum] Benefits of "Carrier" / "User" enumservices > > Having read the draft-pfautz-lind-enum-carrier-user-00.txt > and discussed > it with colleagues, I have some concerns about its drawbacks and am > struggling to see what benefits it offers. > > It may be that I've missed a key point or mis-understood > something so I > would be grateful if someone can assist with explanation and > clarification. > > The first concern is that if this registration and > accompanying data is > introduced, its implications about how DNS data is structured breaks > existing enum resolvers. For example, when a resolver queries the > e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all > the NAPTR records matching this number and then looks for a > match on the > enumservices "E2U" and "SIP". This matching will fail as only NAPTR > records with "Carrier" or "User" are present and the call fails. To > introduce these enumservices successfully requires all existing enum > resolvers to be re-implemented. The resolver has to first look for a > match on "Carrier" or "User" enumservice, retrieve more > NAPTRs and then > look for a match on "E2U" and "SIP". > > The second concern is how the "Carrier" enumservice meets the needs of > telcos. As I understand it, the major driver for introduction > of Carrier > enum is to address privacy concerns. Telcos don't want their enum data > available for inspection and attack by everyone on the > Internet and the > carrier enum concept addresses this by making the data inaccessible > except to authorised queries. However, the use of the Carrier > enumservice only shifts the DNS query to a different DNS domain on the > Internet and makes no difference to the privacy or access privileges. > It's not clear to me what the benefit of "Carrier" enumservice is for > data privacy compared to the case of not having it. > > Kim Fullbrook > > ===================================================== > This electronic message contains information from O2 which may be > privileged or confidential. The information is intended to be for the > use of the individual(s) or entity named above. If you are not the > intended recipient be aware that any disclosure, copying > distribution or > use of the contents of this information is prohibited. If you have > received this electronic message in error, please notify us > by telephone > or email (to the numbers or address above) immediately. > ===================================================== > > > _______________________________________________ > 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 lconroy@insensate.co.uk Thu, 16 Jun 2005 05:36:16 -0400 From: lconroy Date: Thu, 16 Jun 2005 05:36:16 -0400 To: "Lind, Steven D, ALABS" Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Steve, folks, updating an RFC is a non-trivial matter where there is some question over a addition in functionality. Even RFC3966 (which, in practice, reduced options) took a loooonnnng time to complete. Do you mean that RFC3761 is inconsistent - i.e. is this what makes you think is a need for a second template for non-terminals? What cases in RFC3761 do you believe REQUIRE such a template, and in what section of that RFC do you believe this is implied? The initial section of the RFC does reflect a messy discussion with a definite AD position (as is reported in the meeting minutes). It is one of those "strong cup of tea and a quiet room" texts that occur in many RFCs. However... I have looked back through the ML archive (we were both involved in the discussions at the time) and even with this prompting do not recall a meeting discussion or posting that suggested this. all the best, Lawrence On 15 Jun 2005, at 21:08, Lind, Steven D, ALABS wrote: It seems to that if this is the case, the template does not cover all the cases described in RFC 3761. Do we need a second template for non-terminal NAPTRs or change the existing template (and associated instructions) to incorporate both types of NAPTRs. Steve Lind -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Wednesday, June 15, 2005 3:32 PM To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Penn, I am not the one to answer you THIS question ;-) but IMHO we have here a catch 22 because in the replacement field there cannot be an URI at all, the enumservice template is only valid for flag 'u' and not for non-terminal NAPTRs regards Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] Gesendet: Mi 15.06.2005 21:12 An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Richard. Fair enough. I confess to some uncertainty re how to populate the URI part of the template for non-terminals. I toyed with something like "all URI schemes registered under any other enumservice." Would that have been better? Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, June 15, 2005 3:08 PM To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices Penn, a minor correction: you are correct that according to RFC 3761 a client should be able to process non-terminal NAPTRs as defined, which means NAPTRs having only "E2U" in the enumservice field, without any additional enumservices defined. The original intention was that you query the domain given for NAPTRs and THEN decide which enumservice to use. The definitions of the enumservices "user" and "carrier" you draft is NOT according to the template in RFC 3761, because you MUST define the URIs valid for this enumservice (and not N/A), as Lawrence already pointed out. In addition, even if clients have implemented the capability to use non-terminal NAPTRs, up to now they need not to be able to understand and interpret any enumservice defined (only they ones they can handle) With your proposal any ENUM-client not understanding the enumservices "user" and "carrier" will not be able to retreive any enumservice at all. This is of course also true for the proposal I made using for this purpose terminal NAPTRs with enumservice "enum:tel" and carrier:tel", using the phone-context in tel: as apex for the new tree. but this proposal has other advantages. But one should be careful in saying any client in the MUST support this because this is already defined in RFC 3761. regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO Gesendet: Mi 15.06.2005 19:05 An: Fullbrook Kim (UK); enum at ietf.org Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices Kim: I'm not sure I agree with your assessment of what gets broken. My belief is that clients compliant with RFC 3761 should process non-terminal NAPTRs. The matching on a service within E2U such as SIP should occur on terminal NAPTRs. There will be a need to support the new enum services of "user" and "carrier". As to the benefits to carriers, our motivator is NOT primarily privacy, it's effective interconnection. User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. Although the I-D did not go into it, there are techniques for controlling access to actual routing data or offering up different IP points of interface (e.g. different Session Border Controller point) to different carriers. How open interconnection will be to non-carrier parties is a business decision for individual carriers but we believe the proposed implementation can support whatever is decided. Some kind of ENUM will be used for interconnection as voice moves to being an application on IP networks. Our preference is that this implementation be synergistic with end user ENUM. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK) Sent: Wednesday, June 15, 2005 12:44 PM To: enum at ietf.org Subject: [Enum] Benefits of "Carrier" / "User" enumservices Having read the draft-pfautz-lind-enum-carrier-user-00.txt and discussed it with colleagues, I have some concerns about its drawbacks and am struggling to see what benefits it offers. It may be that I've missed a key point or mis-understood something so I would be grateful if someone can assist with explanation and clarification. The first concern is that if this registration and accompanying data is introduced, its implications about how DNS data is structured breaks existing enum resolvers. For example, when a resolver queries the e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all the NAPTR records matching this number and then looks for a match on the enumservices "E2U" and "SIP". This matching will fail as only NAPTR records with "Carrier" or "User" are present and the call fails. To introduce these enumservices successfully requires all existing enum resolvers to be re-implemented. The resolver has to first look for a match on "Carrier" or "User" enumservice, retrieve more NAPTRs and then look for a match on "E2U" and "SIP". The second concern is how the "Carrier" enumservice meets the needs of telcos. As I understand it, the major driver for introduction of Carrier enum is to address privacy concerns. Telcos don't want their enum data available for inspection and attack by everyone on the Internet and the carrier enum concept addresses this by making the data inaccessible except to authorised queries. However, the use of the Carrier enumservice only shifts the DNS query to a different DNS domain on the Internet and makes no difference to the privacy or access privileges. It's not clear to me what the benefit of "Carrier" enumservice is for data privacy compared to the case of not having it. Kim Fullbrook --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 17 Jun 2005 13:36:55 -0400 From: Richard Shockey Date: Fri, 17 Jun 2005 13:36:55 -0400 To: enum at ietf.org Subject: [Enum] Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Message-ID: <6.2.1.2.2.20050617133556.03fb8c40@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Reminder.. To: ietf-announce at ietf.org From: ietf-secretariat at ietf.org Date: Fri, 17 Jun 2005 00:00:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ietf-announce at ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: ietf-announce-bounces at ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France X-Keywords: There are two (2) Internet-Draft cutoff dates for the 63rd IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, July 11th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Tuesday, July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, August 1st at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or revised Internet-Draft after their respective cutoff deadlines, then your document will be retained and posted when Internet-Draft processing resumes. You will no longer be required to resubmit the document. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff 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.Stastny@oefeg.at Sat, 18 Jun 2005 09:08:59 -0400 From: "Stastny Richard" Date: Sat, 18 Jun 2005 09:08:59 -0400 To: Subject: [Enum] ETSI TISPAN WG4 on Carrier ENUM draft Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF6F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Dear all, ETSI TISPAN WG4 discussed I-D draft-pfautz-lind-enum-carrier-user-00 circulated via the IETF ENUM mailing list (and also the related document from the US ENUM Forum GEN129R0_Lind_Infrastructure_ENUM_Requirements) during the meeting held this week (14-17 June 2005) in Stockholm. A document was produced (WG4TD13r1) as a "Response on ENUM recent infrastructure developments from ETSI TISPAN WG4" and endorsed by WG4 stating the current position of WG4 on this issue. I include here the full text of WG4TD13r1 for your information: "With the move towards all IP networks applications, interworking must be addressed in order to facilitate global interoperability. NGN networks should interwork with each other through secure interfaces that provide a high level of trust, particularly with regard to any routeing information obtained from an ENUM database. Consideration must be given to how an NGN will interwork with other NGNs, and with other VoIP providers which are not part of the NGN cloud. Until now ENUM according to RFC3761 in e164.arpa (User ENUM) has not been seen as useful to an NGN/Telco/VoIP provider as it is reliant on user action in terms of registration, insertion of data and management of that data. Additionally, there is also controversy regarding the inclusion of data within the NAPTR records which is publicly exposed in User ENUM. Both ETSI TISPAN and 3GPP have discovered that ENUM promises to be a useful technology for interworking and facilitating interoperability. Given that NGNs will require interworking with other IP networks, ENUM is a favoured tool, but not in the form of User ENUM. Within TISPAN and 3GPP, Infrastructure ENUM ("carrier ENUM") which meets this need has, until now, been proposed to be hosted in a separate tree from User ENUM. The following points summarise the current views held within ETSI TISPAN. 1) ETSI TISPAN is still convinced that a separate tree ENUM for Infrastructure ENUM that is available to NGN networks would allow for ultimate flexibility, especially when different NGN operators want to introduce interconnection of their networks on an IP peering basis. It can be argued that using e164.arpa for Infrastructure ENUM would not require a new policy framework as the existing arrangements between the IAB and the ITU apply to the administration of that name space. However because of the way these rules apply, carrier routeing information would fall under the national regulatory framework in a different manner to the way this has worked in the past. Carriers should be aware that action by governmental authorities is required, according to present IAB/ITU-T rules, if the ".e164.arpa" domain is used, irrespective of whether the domain would be used for User or Infrastructure ENUM. In most cases a governmental authority is the domain name holder of ".e164.arpa" and therefore responsible for the rules. Consequently, carriers would not be able to operate unless governmental authorities take this positive action. 2) ETSI TISPAN is also aware that some other groups such as the GSM-A have already decided to use a separate domain of their own for infrastructure ENUM purposes; e.g. "e164enum.net". The envisaged solution should also include these ENUM domains within a global ENUM infrastructure or at least to allow and facilitate interworking between these different domains. 3) If the cohabitation of User ENUM and Infrastructure ENUM in the same domain as proposed in I-D draft-pfautz-lind-enum-carrier-user-00 is to be progressed, the impact on existing implementations of User ENUM should be kept to a minimum. This implies that modifications to existing RFCs e.g. 3761, 3401-4 should be avoided. 4) For any proposed solution it is a requirement that any impact caused by that implementation at a global level is considered. Therefore it has to be applicable for use with all national numbering plans; particular challenges may be to ensure that a global implementation is compatible with the use of variable length numbering (e.g. as used in Germany and Austria) and DDI blocks. 5) Infrastructure ENUM as proposed in I-D draft-pfautz-lind-enum-carrier-user-00 must be subject to appropriate measures for control and management of the data contained in the NAPTRs. This information must be current and reliable for routing purposes. Infrastructure ENUM does not remove the need for authentication that the party inserting, modifying or removing data in NAPTR records has a right to the corresponding number. Authentication is still required and an appropriate authentication procedure needs to be in place between the ENUM Tier 1 Registry and the carrier serving the number. Apart from control and management of data, the issues of security and trust, mentioned in the first paragraph, are also important. Ensuring trust in the data accessible by means of Infrastructure ENUM may involve having rules dealing with: * the accuracy of data; * who has access to data; * the allowable purposes for which data may be used. With the proposed approach set out in I-D draft-pfautz-lind-enum-carrier-user-00, these rules would normally be made by or subject to governmental authorities." best regards Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 06:52:29 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 06:52:29 -0400 To: Subject: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Dear all, The proposal brought forward in draft-pfautz-lind-enum-carrier-user-00 raises two issues: 1) Should (user) ENUM and Infrastructure (Carrier) ENUM implementations be mixed within e.164.arpa? 2) If yes, how should this be done technically? Regarding 1) I have submitted to the list the position of ETSI TISPAN WG4 in a previous post, containing the pro and cons. So I want to concentrate here on issue 2) only: draft-pfautz-lind-enum-carrier-user-00 proposes the usage of non-terminal NAPTRs to separate between user and carrier entries in Tier 1 of e164.arpa The usage of non-terminals creates many problems, (see below), so I consider this harmful. It is therefore proposed to consider the usage of terminal NAPTRs to solve the problem at hand, a technical proposal is also contained below. This proposal does not solve all problems raised with non-terminals below, but most of them. Problems with non-terminal NAPTRs: The first problem with non-terminals is non-conformant with RFC3761: Although RFC3761 allows the usage of non-terminals (section 1.3 and 2.4), the intrinsic assumption is that in this case there is no Enumservice used in the service field (beside E2U). Basically the template in RFC3671 to register a Enumservice cannot be used as is, because in section 3.1.1 is stated: "A registered Enumservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it. Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, ..." So a URI definition such as "N/A" or "Any" is not allowed. Additional problems: -existing users are forced to move out of e164.arpa -Non-Terminals are not supported in existing clients -Non-Terminals involve multiple DNS queries -No Glue Records in Non-Terminals -Prone to "Error in User" -Automatically checking the domain is not easy -Pre-existing targets only (the privacy/control problem) -Going in Circles, by accident or design -Time To Live across domains -Etc. I think Lawrence is here better suited to explain these problems more in detail, if required or requested. Proposal to use terminal NAPTRs It is therefore proposed to use terminal NAPTRs for this purpose: I propose to reuse the Enumservice "enum" as specified in ETSI TS 102 172 for redirection: This Enumservice uses the "tel:" URI to instruct the ENUM client to launch another ENUM query for the E.164 number given in the "tel:" URI. The purpose is to allow a user who has say three different E.164 numbers registered in ENUM to point two of this numbers to the third and maintain the real NAPTRs only in the domain of the third. The default assumption with the tel: URI as given is that the domain to query is e164.arpa (ENUM) If now an additional parameter is defined for the tel: URI e.g. ";enum-context=foo.bar", the behaviour could be exactly the same, except that in step 4. of section 2.4 in RFC3761 instead of e164.arpa the domain given in enum-context is appended. This causes not much changes to existing ENUM-clients, some of them already allow a different apex from e164.arpa to be used or query two different trees subsequently. If no enum-context is given, the ENUMservice "enum" works as defined in TS 102 172 for e164.arpa The advantage of this proposal is: minimum change to the user enum clients and all solutions for variable length number plans and DDI work as usual. For the carrier part a new Enumservice "carrier" is proposed which works in exactly the same way with a "tel:" and in this case with a mandatory enum-context parameter. Using the "tel: URI in this context provides an additional bonus: the "tel:" URI may be used with additional parameters, e.g. the ones defined in draft-ietf-iptel-tel-np-05, especially ";rn=" and ";cic=". This would allow carriers also to enter data for numbers existing on the PSTN only and providing national routing numbers or Carrier Identification Codes, if required. Carriers may retrieve e.g a routing number already in ENUM an save an additional IN-dip on the PSTN. User ENUM clients do not need to be able to process NAPTRs with Enumservice "carrier", they may ignore it. To implement this solution, an additional measure is necessary: If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR cannot be stored in e164.arpa any longer (this is also true for the non-terminal proposal). So the user MUST move out to another domain e.g. as proposed to joesenum.com. Since there is no reason normally for a user in e164.arpa suddenly to go and look for an own domain if a carrier decides to opt-in, there should be a default domain available also under e614.arpa, where the Registrar or Nameserver provider can move the user in this case. It is proposed to use user.e164.arpa for this purpose. This requires a slight modification in the agreements between IAB, RIPE and ITU-T insofar that 1. this domain is created 2. the delegation of this domain is always performed in parallel and according the rules as defined in the Interim Procedures for the delegation of e164.arpa 3. Any existing delegation in e164.arpa gets an automatic delegation to the same conditions e.g nameservers as stated in the original request If carrier ENUM is implemented within e164.arpa and what the national specific rules are is a national matter and has to be added to the existing framework for User ENUM. Best regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Wed, 22 Jun 2005 07:40:23 -0400 From: lconroy Date: Wed, 22 Jun 2005 07:40:23 -0400 To: "Stastny Richard" Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Richard, Richard, folks, This proposal should work, albeit it will take effort and => time to analyse and get the specifications in place - at least it doesn't directly conflict with 3761. N-Ts are, as you spell out, evil (and the existing specs are, at best, complex in this area). However... As an alternative: Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers aren't, why not just have a sub-domain (for example carrier.e164.arpa.) specifically for Carriers to populate and query, and leave the Users where they are? Basically, if the carriers are looking somewhere else, then ALL of the problems go away. The carriers and their suppliers have much better "connections" to ITU (and, arguably, to the IAB and IETF - see current discussion on WG chair commitments on the IETF-general list). If the agreements need to be changed at all, then the carriers/suppliers will have to do this policy (re-)development work anyway. I am still waiting for convincing arguments justifying the clearance of users from the space allocated for user ENUM. So far, we seem to have missed that completely. all the best, Lawrence On 22 Jun 2005, at 11:50, Stastny Richard wrote: Dear all, The proposal brought forward in draft-pfautz-lind-enum-carrier-user-00 raises two issues: 1) Should (user) ENUM and Infrastructure (Carrier) ENUM implementations be mixed within e.164.arpa? 2) If yes, how should this be done technically? Regarding 1) I have submitted to the list the position of ETSI TISPAN WG4 in a previous post, containing the pro and cons. So I want to concentrate here on issue 2) only: draft-pfautz-lind-enum-carrier-user-00 proposes the usage of non-terminal NAPTRs to separate between user and carrier entries in Tier 1 of e164.arpa The usage of non-terminals creates many problems, (see below), so I consider this harmful. It is therefore proposed to consider the usage of terminal NAPTRs to solve the problem at hand, a technical proposal is also contained below. This proposal does not solve all problems raised with non-terminals below, but most of them. Problems with non-terminal NAPTRs: The first problem with non-terminals is non-conformant with RFC3761: Although RFC3761 allows the usage of non-terminals (section 1.3 and 2.4), the intrinsic assumption is that in this case there is no Enumservice used in the service field (beside E2U). Basically the template in RFC3671 to register a Enumservice cannot be used as is, because in section 3.1.1 is stated: "A registered Enumservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it. Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, ..." So a URI definition such as "N/A" or "Any" is not allowed. Additional problems: -existing users are forced to move out of e164.arpa -Non-Terminals are not supported in existing clients -Non-Terminals involve multiple DNS queries -No Glue Records in Non-Terminals -Prone to "Error in User" -Automatically checking the domain is not easy -Pre-existing targets only (the privacy/control problem) -Going in Circles, by accident or design -Time To Live across domains -Etc. I think Lawrence is here better suited to explain these problems more in detail, if required or requested. Proposal to use terminal NAPTRs It is therefore proposed to use terminal NAPTRs for this purpose: I propose to reuse the Enumservice "enum" as specified in ETSI TS 102 172 for redirection: This Enumservice uses the "tel:" URI to instruct the ENUM client to launch another ENUM query for the E.164 number given in the "tel:" URI. The purpose is to allow a user who has say three different E.164 numbers registered in ENUM to point two of this numbers to the third and maintain the real NAPTRs only in the domain of the third. The default assumption with the tel: URI as given is that the domain to query is e164.arpa (ENUM) If now an additional parameter is defined for the tel: URI e.g. ";enum-context=foo.bar", the behaviour could be exactly the same, except that in step 4. of section 2.4 in RFC3761 instead of e164.arpa the domain given in enum-context is appended. This causes not much changes to existing ENUM-clients, some of them already allow a different apex from e164.arpa to be used or query two different trees subsequently. If no enum-context is given, the ENUMservice "enum" works as defined in TS 102 172 for e164.arpa The advantage of this proposal is: minimum change to the user enum clients and all solutions for variable length number plans and DDI work as usual. For the carrier part a new Enumservice "carrier" is proposed which works in exactly the same way with a "tel:" and in this case with a mandatory enum-context parameter. Using the "tel: URI in this context provides an additional bonus: the "tel:" URI may be used with additional parameters, e.g. the ones defined in draft-ietf-iptel-tel-np-05, especially ";rn=" and ";cic=". This would allow carriers also to enter data for numbers existing on the PSTN only and providing national routing numbers or Carrier Identification Codes, if required. Carriers may retrieve e.g a routing number already in ENUM an save an additional IN-dip on the PSTN. User ENUM clients do not need to be able to process NAPTRs with Enumservice "carrier", they may ignore it. To implement this solution, an additional measure is necessary: If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR cannot be stored in e164.arpa any longer (this is also true for the non-terminal proposal). So the user MUST move out to another domain e.g. as proposed to joesenum.com. Since there is no reason normally for a user in e164.arpa suddenly to go and look for an own domain if a carrier decides to opt-in, there should be a default domain available also under e614.arpa, where the Registrar or Nameserver provider can move the user in this case. It is proposed to use user.e164.arpa for this purpose. This requires a slight modification in the agreements between IAB, RIPE and ITU-T insofar that 1. this domain is created 2. the delegation of this domain is always performed in parallel and according the rules as defined in the Interim Procedures for the delegation of e164.arpa 3. Any existing delegation in e164.arpa gets an automatic delegation to the same conditions e.g nameservers as stated in the original request If carrier ENUM is implemented within e164.arpa and what the national specific rules are is a national matter and has to be added to the existing framework for User ENUM. Best regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 07:57:41 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 07:57:41 -0400 To: "lconroy" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Lawrence said: > Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers > aren't, why > not just have a sub-domain (for example carrier.e164.arpa.) > specifically for Carriers > to populate and query, and leave the Users where they are? This is basically the TISPAN WG4 proposal and my issue 1 The following options exists: Put the Carriers in: a. e164carrier.arpa - this requires only the IAB and does not involve ITU-T BUT requires a policy framework to be set up by whom? This may take some time even to create a body. -> Restart at square -1 b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the national regulators. BUT involves for policy mainly the ITU-T. So the body is known, but since even the interim procedures are not places in a Rec. yet ... -> restart at square 1 c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T only on the side, but definitely the national regulators. The international policy framework may be taken basically as is, but national policy needs to be amended. So the time taken is a national matter, but it may be easier and faster to set-up (less involved parties) The other benefit: National regulators may be forced by the carriers to opt-in to e164.arpa, which may be of benefit also for User ENUM. -> Continue where we are. Conclusion: option c may not be the optimal solution, but it will be definitely the fastest for the carriers and also be of some benefit for User ENUM. Additional remark: Other trees may and will co-exist, but any tree in e164.arpa may serve as a glue. GSMA operators just need to put a pointer in to ;enum-context=e164.enum.net Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: lconroy [mailto:lconroy at insensate.co.uk] > Sent: Wednesday, June 22, 2005 1:40 PM > To: Stastny Richard > Cc: 'enum at ietf.org' ENUM; Richard Shockey > Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > Hi Richard, Richard, folks, > This proposal should work, albeit it will take effort and => time to > analyse and > get the specifications in place - at least it doesn't directly conflict > with 3761. > > N-Ts are, as you spell out, evil (and the existing specs are, at best, > complex in > this area). > > However... As an alternative: > > Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers > aren't, why > not just have a sub-domain (for example carrier.e164.arpa.) > specifically for Carriers > to populate and query, and leave the Users where they are? > > Basically, if the carriers are looking somewhere else, then ALL of the > problems go away. > > The carriers and their suppliers have much better "connections" to ITU > (and, arguably, to > the IAB and IETF - see current discussion on WG chair commitments on > the IETF-general list). > If the agreements need to be changed at all, then the > carriers/suppliers will have to do > this policy (re-)development work anyway. > > I am still waiting for convincing arguments justifying the clearance of > users from the > space allocated for user ENUM. > > So far, we seem to have missed that completely. > > all the best, > Lawrence > > On 22 Jun 2005, at 11:50, Stastny Richard wrote: > > Dear all, > > > > The proposal brought forward in > > draft-pfautz-lind-enum-carrier-user-00 > > raises two issues: > > > > 1) Should (user) ENUM and Infrastructure (Carrier) ENUM > > implementations be mixed within e.164.arpa? > > > > 2) If yes, how should this be done technically? > > > > Regarding 1) I have submitted to the list the position of > > ETSI TISPAN WG4 in a previous post, containing the pro and cons. > > > > So I want to concentrate here on issue 2) only: > > > > draft-pfautz-lind-enum-carrier-user-00 proposes > > the usage of non-terminal NAPTRs to separate > > between user and carrier entries in Tier 1 of > > e164.arpa > > > > The usage of non-terminals creates many problems, > > (see below), so I consider this harmful. > > > > It is therefore proposed to consider the usage > > of terminal NAPTRs to solve the problem at hand, > > a technical proposal is also contained below. > > This proposal does not solve all problems raised > > with non-terminals below, but most of them. > > > > Problems with non-terminal NAPTRs: > > > > The first problem with non-terminals is non-conformant > > with RFC3761: > > > > Although RFC3761 allows the usage of non-terminals > > (section 1.3 and 2.4), the intrinsic assumption is > > that in this case there is no Enumservice used > > in the service field (beside E2U). > > > > Basically the template in RFC3671 to register a > > Enumservice cannot be used as is, because in section > > 3.1.1 is stated: > > "A registered Enumservice must be able to function as > > a selection mechanism when choosing one NAPTR resource > > record from another. That means that the registration > > MUST specify what is expected when using that very NAPTR > > record, and the URI which is the outcome of the use of it. > > > > Specifically, a registered Enumservice MUST specify the > > URI scheme(s) that may be used for the Enumservice, ..." > > > > So a URI definition such as "N/A" or "Any" is not allowed. > > > > Additional problems: > > > > -existing users are forced to move out of e164.arpa > > -Non-Terminals are not supported in existing clients > > -Non-Terminals involve multiple DNS queries > > -No Glue Records in Non-Terminals > > -Prone to "Error in User" > > -Automatically checking the domain is not easy > > -Pre-existing targets only (the privacy/control problem) > > -Going in Circles, by accident or design > > -Time To Live across domains > > -Etc. > > I think Lawrence is here better suited to explain these > > problems more in detail, if required or requested. > > > > Proposal to use terminal NAPTRs > > > > It is therefore proposed to use terminal NAPTRs > > for this purpose: > > > > I propose to reuse the Enumservice "enum" as specified > > in ETSI TS 102 172 for redirection: > > > > This Enumservice uses the "tel:" URI to instruct the > > ENUM client to launch another ENUM query for the > > E.164 number given in the "tel:" URI. The purpose is > > to allow a user who has say three different E.164 numbers > > registered in ENUM to point two of this numbers to the > > third and maintain the real NAPTRs only in the domain > > of the third. > > > > The default assumption with the tel: URI as given is > > that the domain to query is e164.arpa (ENUM) > > > > If now an additional parameter is defined for the tel: URI > > e.g. ";enum-context=foo.bar", the behaviour could be > > exactly the same, except that in step 4. of section 2.4 > > in RFC3761 instead of e164.arpa the domain given in > > enum-context is appended. This causes not much changes > > to existing ENUM-clients, some of them already allow > > a different apex from e164.arpa to be used or query two > > different trees subsequently. > > > > If no enum-context is given, the ENUMservice "enum" works > > as defined in TS 102 172 for e164.arpa > > > > The advantage of this proposal is: minimum change > > to the user enum clients and all solutions for > > variable length number plans and DDI work as usual. > > > > For the carrier part a new Enumservice "carrier" > > is proposed which works in exactly the same way with > > a "tel:" and in this case with a mandatory enum-context > > parameter. > > > > Using the "tel: URI in this context provides an > > additional bonus: the "tel:" URI may be used with > > additional parameters, e.g. the ones defined > > in draft-ietf-iptel-tel-np-05, especially ";rn=" and > > ";cic=". This would allow carriers also to enter > > data for numbers existing on the PSTN only and > > providing national routing numbers or Carrier Identification > > Codes, if required. Carriers may retrieve e.g a routing > > number already in ENUM an save an additional IN-dip on the > > PSTN. > > > > User ENUM clients do not need to be able to process NAPTRs > > with Enumservice "carrier", they may ignore it. > > > > To implement this solution, an additional measure is necessary: > > > > If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR > > cannot be stored in e164.arpa any longer (this is also true > > for the non-terminal proposal). So the user MUST move out to > > another domain e.g. as proposed to joesenum.com. Since there > > is no reason normally for a user in e164.arpa suddenly to > > go and look for an own domain if a carrier decides to opt-in, > > there should be a default domain available also under e614.arpa, > > where the Registrar or Nameserver provider can move the user > > in this case. It is proposed to use user.e164.arpa for this > > purpose. > > > > This requires a slight modification in the agreements between > > IAB, RIPE and ITU-T insofar that > > 1. this domain is created > > 2. the delegation of this domain is always performed in > > parallel and according the rules as defined in > > the Interim Procedures for the delegation of e164.arpa > > 3. Any existing delegation in e164.arpa gets an automatic > > delegation to the same conditions e.g nameservers as stated > > in the original request > > > > If carrier ENUM is implemented within e164.arpa and what the > > national specific rules are is a national matter and has > > to be added to the existing framework for User ENUM. > > > > Best regards > > > > Richard > > > > > > Richard Stastny > > OeFEG > > tel:+43 664 420 4100 > > enum:+43 780 203 211 > > callto://fordprefect > > http://voipandenum.blogspot.com > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > --------------------------------------- > lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Wed, 22 Jun 2005 08:24:14 -0400 From: lconroy Date: Wed, 22 Jun 2005 08:24:14 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: <411b3bb9e70c0456a5cd40ea057e03cf@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Folks, for precision/clarity, Kim has registered: e164enum.net, NOT e164.enum.net. Thus it would be ;enum-context=e164enum.net. atb, L On 22 Jun 2005, at 12:56, Stastny Richard wrote: Other trees may and will co-exist, but any tree in e164.arpa may serve as a glue. GSMA operators just need to put a pointer in to ;enum-context=e164.enum.net --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 22 Jun 2005 09:01:26 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 22 Jun 2005 09:01:26 -0400 To: "Stastny Richard" Subject: [Enum] Carrier ENUM alternatives Message-ID: <34DA635B184A644DA4588E260EC0A25A0A7C17A8@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard: Thanks for nicely laying out the alternatives and their implications. I want to stress to Lawrence that the non-terminal NAPTR proposal was not about trying to push out users but trying to bring *in* carriers. We are moving to IP interconnection and ENUM technology is the right way to do it, so the question is not whether but where/how. We (the I-D authors) feel it's preferable to try to do this together with user ENUM, not only to avoid restart at square 1, but also to jump start the infrastructure. Given the meager success of public user ENUM so far, one might think that would be seen in a positive light. The separate domain approach remains an alternative and, if necessary, I expect we'll go down that path. But if we do there'll be much less incentive for carriers to devote resources to the support of user ENUM. I sense ETSI has already nearly thrown in the towel. Not giving up on non-Terminals but thinking about the terminal NAPTR proposal.... Penn -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: Wednesday, June 22, 2005 7:56 AM To: lconroy Cc: enum at ietf.org; Richard Shockey Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Lawrence said: > Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers > aren't, why > not just have a sub-domain (for example carrier.e164.arpa.) > specifically for Carriers > to populate and query, and leave the Users where they are? This is basically the TISPAN WG4 proposal and my issue 1 The following options exists: Put the Carriers in: a. e164carrier.arpa - this requires only the IAB and does not involve ITU-T BUT requires a policy framework to be set up by whom? This may take some time even to create a body. -> Restart at square -1 b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the national regulators. BUT involves for policy mainly the ITU-T. So the body is known, but since even the interim procedures are not places in a Rec. yet ... -> restart at square 1 c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T only on the side, but definitely the national regulators. The international policy framework may be taken basically as is, but national policy needs to be amended. So the time taken is a national matter, but it may be easier and faster to set-up (less involved parties) The other benefit: National regulators may be forced by the carriers to opt-in to e164.arpa, which may be of benefit also for User ENUM. -> Continue where we are. Conclusion: option c may not be the optimal solution, but it will be definitely the fastest for the carriers and also be of some benefit for User ENUM. Additional remark: Other trees may and will co-exist, but any tree in e164.arpa may serve as a glue. GSMA operators just need to put a pointer in to ;enum-context=e164.enum.net Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: lconroy [mailto:lconroy at insensate.co.uk] > Sent: Wednesday, June 22, 2005 1:40 PM > To: Stastny Richard > Cc: 'enum at ietf.org' ENUM; Richard Shockey > Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > Hi Richard, Richard, folks, > This proposal should work, albeit it will take effort and => time to > analyse and > get the specifications in place - at least it doesn't directly conflict > with 3761. > > N-Ts are, as you spell out, evil (and the existing specs are, at best, > complex in > this area). > > However... As an alternative: > > Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers > aren't, why > not just have a sub-domain (for example carrier.e164.arpa.) > specifically for Carriers > to populate and query, and leave the Users where they are? > > Basically, if the carriers are looking somewhere else, then ALL of the > problems go away. > > The carriers and their suppliers have much better "connections" to ITU > (and, arguably, to > the IAB and IETF - see current discussion on WG chair commitments on > the IETF-general list). > If the agreements need to be changed at all, then the > carriers/suppliers will have to do > this policy (re-)development work anyway. > > I am still waiting for convincing arguments justifying the clearance of > users from the > space allocated for user ENUM. > > So far, we seem to have missed that completely. > > all the best, > Lawrence > > On 22 Jun 2005, at 11:50, Stastny Richard wrote: > > Dear all, > > > > The proposal brought forward in > > draft-pfautz-lind-enum-carrier-user-00 > > raises two issues: > > > > 1) Should (user) ENUM and Infrastructure (Carrier) ENUM > > implementations be mixed within e.164.arpa? > > > > 2) If yes, how should this be done technically? > > > > Regarding 1) I have submitted to the list the position of > > ETSI TISPAN WG4 in a previous post, containing the pro and cons. > > > > So I want to concentrate here on issue 2) only: > > > > draft-pfautz-lind-enum-carrier-user-00 proposes > > the usage of non-terminal NAPTRs to separate > > between user and carrier entries in Tier 1 of > > e164.arpa > > > > The usage of non-terminals creates many problems, > > (see below), so I consider this harmful. > > > > It is therefore proposed to consider the usage > > of terminal NAPTRs to solve the problem at hand, > > a technical proposal is also contained below. > > This proposal does not solve all problems raised > > with non-terminals below, but most of them. > > > > Problems with non-terminal NAPTRs: > > > > The first problem with non-terminals is non-conformant > > with RFC3761: > > > > Although RFC3761 allows the usage of non-terminals > > (section 1.3 and 2.4), the intrinsic assumption is > > that in this case there is no Enumservice used > > in the service field (beside E2U). > > > > Basically the template in RFC3671 to register a > > Enumservice cannot be used as is, because in section > > 3.1.1 is stated: > > "A registered Enumservice must be able to function as > > a selection mechanism when choosing one NAPTR resource > > record from another. That means that the registration > > MUST specify what is expected when using that very NAPTR > > record, and the URI which is the outcome of the use of it. > > > > Specifically, a registered Enumservice MUST specify the > > URI scheme(s) that may be used for the Enumservice, ..." > > > > So a URI definition such as "N/A" or "Any" is not allowed. > > > > Additional problems: > > > > -existing users are forced to move out of e164.arpa > > -Non-Terminals are not supported in existing clients > > -Non-Terminals involve multiple DNS queries > > -No Glue Records in Non-Terminals > > -Prone to "Error in User" > > -Automatically checking the domain is not easy > > -Pre-existing targets only (the privacy/control problem) > > -Going in Circles, by accident or design > > -Time To Live across domains > > -Etc. > > I think Lawrence is here better suited to explain these > > problems more in detail, if required or requested. > > > > Proposal to use terminal NAPTRs > > > > It is therefore proposed to use terminal NAPTRs > > for this purpose: > > > > I propose to reuse the Enumservice "enum" as specified > > in ETSI TS 102 172 for redirection: > > > > This Enumservice uses the "tel:" URI to instruct the > > ENUM client to launch another ENUM query for the > > E.164 number given in the "tel:" URI. The purpose is > > to allow a user who has say three different E.164 numbers > > registered in ENUM to point two of this numbers to the > > third and maintain the real NAPTRs only in the domain > > of the third. > > > > The default assumption with the tel: URI as given is > > that the domain to query is e164.arpa (ENUM) > > > > If now an additional parameter is defined for the tel: URI > > e.g. ";enum-context=foo.bar", the behaviour could be > > exactly the same, except that in step 4. of section 2.4 > > in RFC3761 instead of e164.arpa the domain given in > > enum-context is appended. This causes not much changes > > to existing ENUM-clients, some of them already allow > > a different apex from e164.arpa to be used or query two > > different trees subsequently. > > > > If no enum-context is given, the ENUMservice "enum" works > > as defined in TS 102 172 for e164.arpa > > > > The advantage of this proposal is: minimum change > > to the user enum clients and all solutions for > > variable length number plans and DDI work as usual. > > > > For the carrier part a new Enumservice "carrier" > > is proposed which works in exactly the same way with > > a "tel:" and in this case with a mandatory enum-context > > parameter. > > > > Using the "tel: URI in this context provides an > > additional bonus: the "tel:" URI may be used with > > additional parameters, e.g. the ones defined > > in draft-ietf-iptel-tel-np-05, especially ";rn=" and > > ";cic=". This would allow carriers also to enter > > data for numbers existing on the PSTN only and > > providing national routing numbers or Carrier Identification > > Codes, if required. Carriers may retrieve e.g a routing > > number already in ENUM an save an additional IN-dip on the > > PSTN. > > > > User ENUM clients do not need to be able to process NAPTRs > > with Enumservice "carrier", they may ignore it. > > > > To implement this solution, an additional measure is necessary: > > > > If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR > > cannot be stored in e164.arpa any longer (this is also true > > for the non-terminal proposal). So the user MUST move out to > > another domain e.g. as proposed to joesenum.com. Since there > > is no reason normally for a user in e164.arpa suddenly to > > go and look for an own domain if a carrier decides to opt-in, > > there should be a default domain available also under e614.arpa, > > where the Registrar or Nameserver provider can move the user > > in this case. It is proposed to use user.e164.arpa for this > > purpose. > > > > This requires a slight modification in the agreements between > > IAB, RIPE and ITU-T insofar that > > 1. this domain is created > > 2. the delegation of this domain is always performed in > > parallel and according the rules as defined in > > the Interim Procedures for the delegation of e164.arpa > > 3. Any existing delegation in e164.arpa gets an automatic > > delegation to the same conditions e.g nameservers as stated > > in the original request > > > > If carrier ENUM is implemented within e164.arpa and what the > > national specific rules are is a national matter and has > > to be added to the existing framework for User ENUM. > > > > Best regards > > > > Richard > > > > > > Richard Stastny > > OeFEG > > tel:+43 664 420 4100 > > enum:+43 780 203 211 > > callto://fordprefect > > http://voipandenum.blogspot.com > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > --------------------------------------- > lawrence conroy |tel:+44-1794-833666 _______________________________________________ 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 Wed, 22 Jun 2005 09:23:54 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 22 Jun 2005 09:23:54 -0400 To: Stastny Richard Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 04:56, Stastny Richard wrote: The following options exists: Put the Carriers in: a. e164carrier.arpa - this requires only the IAB and does not involve ITU-T BUT requires a policy framework to be set up by whom? This may take some time even to create a body. -> Restart at square -1 Having two domains in the DNS not technically bound to each other (i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions regarding policy for who runs the (two) domains. Having them synchronized in any way will be a nightmare, and, it forces the local regulative bodies that already have had headache over "who will run cc.e164.arpa" to wake up again. b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the national regulators. BUT involves for policy mainly the ITU-T. So the body is known, but since even the interim procedures are not places in a Rec. yet ... -> restart at square 1 See earlier bullet. Similar problems, as you point out. c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T only on the side, but definitely the national regulators. The international policy framework may be taken basically as is, but national policy needs to be amended. So the time taken is a national matter, but it may be easier and faster to set-up (less involved parties) Correct. The policy have to be adjusted in some cases, but the policy work is, I claim, not at all as heavy as the previous suggestions. The other benefit: National regulators may be forced by the carriers to opt-in to e164.arpa, which may be of benefit also for User ENUM. -> Continue where we are. Conclusion: option c may not be the optimal solution, but it will be definitely the fastest for the carriers and also be of some benefit for User ENUM. I agree. paf Additional remark: Other trees may and will co-exist, but any tree in e164.arpa may serve as a glue. GSMA operators just need to put a pointer in to ;enum-context=e164.enum.net Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com -----Original Message----- From: lconroy [mailto:lconroy at insensate.co.uk] Sent: Wednesday, June 22, 2005 1:40 PM To: Stastny Richard Cc: 'enum at ietf.org' ENUM; Richard Shockey Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Hi Richard, Richard, folks, This proposal should work, albeit it will take effort and => time to analyse and get the specifications in place - at least it doesn't directly conflict with 3761. N-Ts are, as you spell out, evil (and the existing specs are, at best, complex in this area). However... As an alternative: Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers aren't, why not just have a sub-domain (for example carrier.e164.arpa.) specifically for Carriers to populate and query, and leave the Users where they are? Basically, if the carriers are looking somewhere else, then ALL of the problems go away. The carriers and their suppliers have much better "connections" to ITU (and, arguably, to the IAB and IETF - see current discussion on WG chair commitments on the IETF-general list). If the agreements need to be changed at all, then the carriers/suppliers will have to do this policy (re-)development work anyway. I am still waiting for convincing arguments justifying the clearance of users from the space allocated for user ENUM. So far, we seem to have missed that completely. all the best, Lawrence On 22 Jun 2005, at 11:50, Stastny Richard wrote: Dear all, The proposal brought forward in draft-pfautz-lind-enum-carrier-user-00 raises two issues: 1) Should (user) ENUM and Infrastructure (Carrier) ENUM implementations be mixed within e.164.arpa? 2) If yes, how should this be done technically? Regarding 1) I have submitted to the list the position of ETSI TISPAN WG4 in a previous post, containing the pro and cons. So I want to concentrate here on issue 2) only: draft-pfautz-lind-enum-carrier-user-00 proposes the usage of non-terminal NAPTRs to separate between user and carrier entries in Tier 1 of e164.arpa The usage of non-terminals creates many problems, (see below), so I consider this harmful. It is therefore proposed to consider the usage of terminal NAPTRs to solve the problem at hand, a technical proposal is also contained below. This proposal does not solve all problems raised with non-terminals below, but most of them. Problems with non-terminal NAPTRs: The first problem with non-terminals is non-conformant with RFC3761: Although RFC3761 allows the usage of non-terminals (section 1.3 and 2.4), the intrinsic assumption is that in this case there is no Enumservice used in the service field (beside E2U). Basically the template in RFC3671 to register a Enumservice cannot be used as is, because in section 3.1.1 is stated: "A registered Enumservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it. Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, ..." So a URI definition such as "N/A" or "Any" is not allowed. Additional problems: -existing users are forced to move out of e164.arpa -Non-Terminals are not supported in existing clients -Non-Terminals involve multiple DNS queries -No Glue Records in Non-Terminals -Prone to "Error in User" -Automatically checking the domain is not easy -Pre-existing targets only (the privacy/control problem) -Going in Circles, by accident or design -Time To Live across domains -Etc. I think Lawrence is here better suited to explain these problems more in detail, if required or requested. Proposal to use terminal NAPTRs It is therefore proposed to use terminal NAPTRs for this purpose: I propose to reuse the Enumservice "enum" as specified in ETSI TS 102 172 for redirection: This Enumservice uses the "tel:" URI to instruct the ENUM client to launch another ENUM query for the E.164 number given in the "tel:" URI. The purpose is to allow a user who has say three different E.164 numbers registered in ENUM to point two of this numbers to the third and maintain the real NAPTRs only in the domain of the third. The default assumption with the tel: URI as given is that the domain to query is e164.arpa (ENUM) If now an additional parameter is defined for the tel: URI e.g. ";enum-context=foo.bar", the behaviour could be exactly the same, except that in step 4. of section 2.4 in RFC3761 instead of e164.arpa the domain given in enum-context is appended. This causes not much changes to existing ENUM-clients, some of them already allow a different apex from e164.arpa to be used or query two different trees subsequently. If no enum-context is given, the ENUMservice "enum" works as defined in TS 102 172 for e164.arpa The advantage of this proposal is: minimum change to the user enum clients and all solutions for variable length number plans and DDI work as usual. For the carrier part a new Enumservice "carrier" is proposed which works in exactly the same way with a "tel:" and in this case with a mandatory enum-context parameter. Using the "tel: URI in this context provides an additional bonus: the "tel:" URI may be used with additional parameters, e.g. the ones defined in draft-ietf-iptel-tel-np-05, especially ";rn=" and ";cic=". This would allow carriers also to enter data for numbers existing on the PSTN only and providing national routing numbers or Carrier Identification Codes, if required. Carriers may retrieve e.g a routing number already in ENUM an save an additional IN-dip on the PSTN. User ENUM clients do not need to be able to process NAPTRs with Enumservice "carrier", they may ignore it. To implement this solution, an additional measure is necessary: If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR cannot be stored in e164.arpa any longer (this is also true for the non-terminal proposal). So the user MUST move out to another domain e.g. as proposed to joesenum.com. Since there is no reason normally for a user in e164.arpa suddenly to go and look for an own domain if a carrier decides to opt-in, there should be a default domain available also under e614.arpa, where the Registrar or Nameserver provider can move the user in this case. It is proposed to use user.e164.arpa for this purpose. This requires a slight modification in the agreements between IAB, RIPE and ITU-T insofar that 1. this domain is created 2. the delegation of this domain is always performed in parallel and according the rules as defined in the Interim Procedures for the delegation of e164.arpa 3. Any existing delegation in e164.arpa gets an automatic delegation to the same conditions e.g nameservers as stated in the original request If carrier ENUM is implemented within e164.arpa and what the national specific rules are is a national matter and has to be added to the existing framework for User ENUM. Best regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ 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 Wed, 22 Jun 2005 09:25:15 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 22 Jun 2005 09:25:15 -0400 To: lconroy Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: <317001E5-5577-4D64-A56A-95BB41CF350C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 04:39, lconroy wrote: This proposal should work, albeit it will take effort and => time to analyse and get the specifications in place - at least it doesn't directly conflict with 3761. FWIW, I am not nervous (as editor and co-chair of the wg) to update 3761 based on this discussion as well as the excellent document that already talk about things that are unclear in 3761. So, please ignore "unclear" issues in 3761 when discussing. Concentrate on "architecture". paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Wed, 22 Jun 2005 10:00:34 -0400 From: lconroy Date: Wed, 22 Jun 2005 10:00:34 -0400 To: Patrik Fältström Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Patrik, folks, Thanks for the kind words - Fujiwara-san and I will at least up-issue the experiences draft with typo fixes, but it doesn't look like the next version will be able to capture the results of this discussion yet. Re. update to 3761: RFC3761 doesn't stand alone. I fear that we *may* need to update 3402 (and definitely should update 3403). For example, 3403 section 4.1 has text in the description of the REGEXP field that is (at least), "not transparent". For DDDS Applications like ENUM/E2U that generate URIs, it does not help - is this field used for a domain name or for a URI (and how do you tell)? That particular section needs to be clear as clients NEED to know what is allowed and what is not (and how to interpret the field contents). This is, IMHO, an architectural rather than just a syntax issue. A "DDDS/ENUM - The Missing Manual" book is definitely needed. all the best, Lawrence On 22 Jun 2005, at 14:24, Patrik Fältström wrote: On Jun 22, 2005, at 04:39, lconroy wrote: This proposal should work, albeit it will take effort and => time to analyse and get the specifications in place - at least it doesn't directly conflict with 3761. FWIW, I am not nervous (as editor and co-chair of the wg) to update 3761 based on this discussion as well as the excellent document that already talk about things that are unclear in 3761. So, please ignore "unclear" issues in 3761 when discussing. Concentrate on "architecture". paf --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 10:38:11 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 10:38:11 -0400 To: Patrik Fältström Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF8F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Thank you Patrik for this clarification. I also agree that option c is preferable During the discussion a third alternative showed up: c1: using non-terminals c2. using terminal NAPTRs both options having these NAPTRs side-by-side in tier 1. c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa I considered this option as ugly and requiering special clients, to derieve the domain to query from the E.164 number and knowing the CC structure, but as Lawrence pointed out, carriers should know this anyway ;-) The advantage of this solution would be that User ENUM in e164.arpa remains completely untouched. User Clients would normally never see these domains The second advantage is that in case c1 and c2 ALWAYS two or three queries are necessary, in case c3 only one, both for user and carrier. The "ugly part" remains with the carriers, and they may deserve this anyway ;-) Richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Mi 22.06.2005 15:23 An: Stastny Richard Cc: lconroy; enum at ietf.org; Richard Shockey Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful On Jun 22, 2005, at 04:56, Stastny Richard wrote: > The following options exists: > Put the Carriers in: > a. e164carrier.arpa - this requires only the IAB and does not involve > ITU-T > BUT requires a policy framework to be set up by whom? This may take > some time even to create a body. -> Restart at square -1 Having two domains in the DNS not technically bound to each other (i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions regarding policy for who runs the (two) domains. Having them synchronized in any way will be a nightmare, and, it forces the local regulative bodies that already have had headache over "who will run cc.e164.arpa" to wake up again. > b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the > national regulators. > BUT involves for policy mainly the ITU-T. So the body is known, but > since even the interim procedures are not places in a Rec. yet ... > -> restart at square 1 See earlier bullet. Similar problems, as you point out. > c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd > ITU-T > only on the side, but definitely the national regulators. > The international policy framework may be taken basically as is, but > national policy needs to be amended. So the time taken is a national > matter, but it may be easier and faster to set-up (less involved > parties) Correct. The policy have to be adjusted in some cases, but the policy work is, I claim, not at all as heavy as the previous suggestions. > The other benefit: National regulators may be forced by the carriers > to opt-in to e164.arpa, which may be of benefit also for User ENUM. > -> Continue where we are. > > Conclusion: option c may not be the optimal solution, but it will > be definitely the fastest for the carriers and also be of some > benefit for User ENUM. I agree. paf > Additional remark: > Other trees may and will co-exist, but any tree in e164.arpa may > serve as a glue. GSMA operators just need to put a pointer in to > ;enum-context=e164.enum.net > > Regards > Richard > > > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > > > >> -----Original Message----- >> From: lconroy [mailto:lconroy at insensate.co.uk] >> Sent: Wednesday, June 22, 2005 1:40 PM >> To: Stastny Richard >> Cc: 'enum at ietf.org' ENUM; Richard Shockey >> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful >> >> Hi Richard, Richard, folks, >> This proposal should work, albeit it will take effort and => time to >> analyse and >> get the specifications in place - at least it doesn't directly >> > conflict > >> with 3761. >> >> N-Ts are, as you spell out, evil (and the existing specs are, at >> best, >> complex in >> this area). >> >> However... As an alternative: >> >> Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers >> aren't, why >> not just have a sub-domain (for example carrier.e164.arpa.) >> specifically for Carriers >> to populate and query, and leave the Users where they are? >> >> Basically, if the carriers are looking somewhere else, then ALL of >> the >> problems go away. >> >> The carriers and their suppliers have much better "connections" to >> ITU >> (and, arguably, to >> the IAB and IETF - see current discussion on WG chair commitments on >> the IETF-general list). >> If the agreements need to be changed at all, then the >> carriers/suppliers will have to do >> this policy (re-)development work anyway. >> >> I am still waiting for convincing arguments justifying the clearance >> > of > >> users from the >> space allocated for user ENUM. >> >> So far, we seem to have missed that completely. >> >> all the best, >> Lawrence >> >> On 22 Jun 2005, at 11:50, Stastny Richard wrote: >> >>> Dear all, >>> >>> The proposal brought forward in >>> draft-pfautz-lind-enum-carrier-user-00 >>> raises two issues: >>> >>> 1) Should (user) ENUM and Infrastructure (Carrier) ENUM >>> implementations be mixed within e.164.arpa? >>> >>> 2) If yes, how should this be done technically? >>> >>> Regarding 1) I have submitted to the list the position of >>> ETSI TISPAN WG4 in a previous post, containing the pro and cons. >>> >>> So I want to concentrate here on issue 2) only: >>> >>> draft-pfautz-lind-enum-carrier-user-00 proposes >>> the usage of non-terminal NAPTRs to separate >>> between user and carrier entries in Tier 1 of >>> e164.arpa >>> >>> The usage of non-terminals creates many problems, >>> (see below), so I consider this harmful. >>> >>> It is therefore proposed to consider the usage >>> of terminal NAPTRs to solve the problem at hand, >>> a technical proposal is also contained below. >>> This proposal does not solve all problems raised >>> with non-terminals below, but most of them. >>> >>> Problems with non-terminal NAPTRs: >>> >>> The first problem with non-terminals is non-conformant >>> with RFC3761: >>> >>> Although RFC3761 allows the usage of non-terminals >>> (section 1.3 and 2.4), the intrinsic assumption is >>> that in this case there is no Enumservice used >>> in the service field (beside E2U). >>> >>> Basically the template in RFC3671 to register a >>> Enumservice cannot be used as is, because in section >>> 3.1.1 is stated: >>> "A registered Enumservice must be able to function as >>> a selection mechanism when choosing one NAPTR resource >>> record from another. That means that the registration >>> MUST specify what is expected when using that very NAPTR >>> record, and the URI which is the outcome of the use of it. >>> >>> Specifically, a registered Enumservice MUST specify the >>> URI scheme(s) that may be used for the Enumservice, ..." >>> >>> So a URI definition such as "N/A" or "Any" is not allowed. >>> >>> Additional problems: >>> >>> -existing users are forced to move out of e164.arpa >>> -Non-Terminals are not supported in existing clients >>> -Non-Terminals involve multiple DNS queries >>> -No Glue Records in Non-Terminals >>> -Prone to "Error in User" >>> -Automatically checking the domain is not easy >>> -Pre-existing targets only (the privacy/control problem) >>> -Going in Circles, by accident or design >>> -Time To Live across domains >>> -Etc. >>> I think Lawrence is here better suited to explain these >>> problems more in detail, if required or requested. >>> >>> Proposal to use terminal NAPTRs >>> >>> It is therefore proposed to use terminal NAPTRs >>> for this purpose: >>> >>> I propose to reuse the Enumservice "enum" as specified >>> in ETSI TS 102 172 for redirection: >>> >>> This Enumservice uses the "tel:" URI to instruct the >>> ENUM client to launch another ENUM query for the >>> E.164 number given in the "tel:" URI. The purpose is >>> to allow a user who has say three different E.164 numbers >>> registered in ENUM to point two of this numbers to the >>> third and maintain the real NAPTRs only in the domain >>> of the third. >>> >>> The default assumption with the tel: URI as given is >>> that the domain to query is e164.arpa (ENUM) >>> >>> If now an additional parameter is defined for the tel: URI >>> e.g. ";enum-context=foo.bar", the behaviour could be >>> exactly the same, except that in step 4. of section 2.4 >>> in RFC3761 instead of e164.arpa the domain given in >>> enum-context is appended. This causes not much changes >>> to existing ENUM-clients, some of them already allow >>> a different apex from e164.arpa to be used or query two >>> different trees subsequently. >>> >>> If no enum-context is given, the ENUMservice "enum" works >>> as defined in TS 102 172 for e164.arpa >>> >>> The advantage of this proposal is: minimum change >>> to the user enum clients and all solutions for >>> variable length number plans and DDI work as usual. >>> >>> For the carrier part a new Enumservice "carrier" >>> is proposed which works in exactly the same way with >>> a "tel:" and in this case with a mandatory enum-context >>> parameter. >>> >>> Using the "tel: URI in this context provides an >>> additional bonus: the "tel:" URI may be used with >>> additional parameters, e.g. the ones defined >>> in draft-ietf-iptel-tel-np-05, especially ";rn=" and >>> ";cic=". This would allow carriers also to enter >>> data for numbers existing on the PSTN only and >>> providing national routing numbers or Carrier Identification >>> Codes, if required. Carriers may retrieve e.g a routing >>> number already in ENUM an save an additional IN-dip on the >>> PSTN. >>> >>> User ENUM clients do not need to be able to process NAPTRs >>> with Enumservice "carrier", they may ignore it. >>> >>> To implement this solution, an additional measure is necessary: >>> >>> If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR >>> cannot be stored in e164.arpa any longer (this is also true >>> for the non-terminal proposal). So the user MUST move out to >>> another domain e.g. as proposed to joesenum.com. Since there >>> is no reason normally for a user in e164.arpa suddenly to >>> go and look for an own domain if a carrier decides to opt-in, >>> there should be a default domain available also under e614.arpa, >>> where the Registrar or Nameserver provider can move the user >>> in this case. It is proposed to use user.e164.arpa for this >>> purpose. >>> >>> This requires a slight modification in the agreements between >>> IAB, RIPE and ITU-T insofar that >>> 1. this domain is created >>> 2. the delegation of this domain is always performed in >>> parallel and according the rules as defined in >>> the Interim Procedures for the delegation of e164.arpa >>> 3. Any existing delegation in e164.arpa gets an automatic >>> delegation to the same conditions e.g nameservers as stated >>> in the original request >>> >>> If carrier ENUM is implemented within e164.arpa and what the >>> national specific rules are is a national matter and has >>> to be added to the existing framework for User ENUM. >>> >>> Best regards >>> >>> Richard >>> >>> >>> Richard Stastny >>> OeFEG >>> tel:+43 664 420 4100 >>> enum:+43 780 203 211 >>> callto://fordprefect >>> http://voipandenum.blogspot.com >>> >>> >>> _______________________________________________ >>> enum mailing list >>> enum at ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >>> >>> >> --------------------------------------- >> lawrence conroy |tel:+44-1794-833666 >> > > > _______________________________________________ > 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 mstjohns@mindspring.com Wed, 22 Jun 2005 11:19:19 -0400 From: Michael StJohns Date: Wed, 22 Jun 2005 11:19:19 -0400 To: "Stastny Richard" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050622111630.04f08360@pop.mindspring.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. At 07:56 AM 6/22/2005, Stastny Richard wrote: c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T only on the side, but definitely the national regulators. The international policy framework may be taken basically as is, but national policy needs to be amended. So the time taken is a national matter, but it may be easier and faster to set-up (less involved parties) The other benefit: National regulators may be forced by the carriers to opt-in to e164.arpa, which may be of benefit also for User ENUM. -> Continue where we are. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Wed, 22 Jun 2005 11:27:32 -0400 From: "Clive D.W. Feather" Date: Wed, 22 Jun 2005 11:27:32 -0400 To: Michael StJohns Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: <20050622152723.GZ1813@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: RO Michael StJohns said: > One other point - assuming I understand what you want (- e.g. > carrier.1.e164.arpa for CC 1). I believe this will require the end > resolver to know where the country code ends for all given country > codes. And that makes this option pretty much a non-starter. Not so. * It's only an issue for carriers, who can maintain a table. * It's not much data to maintain, since there's a fixed set of 1- and 2-digit codes and all others are 3 digit. * Given that, it's not actually impractical to always do it at the 3-digit level and have the 1- and 2-digit countries have multiple entries. * Or, if you don't have the lengths stored, simply try each length in turn until it works, so for +234 you look up: carrier.2.e164.arpa carrier.3.2.e164.arpa carrier.4.3.2.e164.arpa in turn. * Or even use the DNS to store the length information so that relevant (specialised) clients can look it up. In summary, it's not a big deal for those doing carrier enum. Though I would prefer using carrier.e164.arpa anyway. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 11:31:32 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 11:31:32 -0400 To: "Michael StJohns" Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF90@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO As I said I the other reply I did originally not mean this but this is an valid option. To know the apprx 200 Country codes is a non-starter for user ENUM and clients, but not for carriers, they have to know this anyway (they currently have to know nuch more) You just have to maintain the table provided regularly at http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html Richard ________________________________ Von: Michael StJohns [mailto:mstjohns at mindspring.com] Gesendet: Mi 22.06.2005 17:18 An: Stastny Richard; lconroy Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. At 07:56 AM 6/22/2005, Stastny Richard wrote: >c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T >only on the side, but definitely the national regulators. >The international policy framework may be taken basically as is, but >national policy needs to be amended. So the time taken is a national >matter, but it may be easier and faster to set-up (less involved >parties) >The other benefit: National regulators may be forced by the carriers >to opt-in to e164.arpa, which may be of benefit also for User ENUM. >-> Continue where we are. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 22 Jun 2005 12:29:21 -0400 From: Jim Reid Date: Wed, 22 Jun 2005 12:29:21 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 16:27, Clive D.W. Feather wrote: Michael StJohns said: One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. Not so. * It's only an issue for carriers, who can maintain a table. This assumes carriers will always keep this table up to date, which is debatable. The general lack of DNS clue in the world suggests that maintaining this hypothetical table is unlikely to happen at every carrier. In fact I believe some carriers are not particularly diligent about reprogramming their SS7 switches whenever a new "country code" is announced in the ITU Operational Bulletin. If that is the case, then there's no hope of carriers maintaining this table and preserving a consistent name space in the DNS. * It's not much data to maintain, since there's a fixed set of 1- and 2-digit codes and all others are 3 digit. I'm not sure that's true -- prefixes for satellite operators and the like -- and anyway it presumes the current E.164 numbering scheme isn't ever going to change. It's highly unlikely the numbering scheme will change, but if it did... * Given that, it's not actually impractical to always do it at the 3-digit level and have the 1- and 2-digit countries have multiple entries. I don't understand this. And what would you do for NANP where a carrier wants to have a discrete entry for an area code under +1 that happened to be for one of the Carribean states? Or if one of those states gets an extra 3 digit area code? * Or, if you don't have the lengths stored, simply try each length in turn until it works, so for +234 you look up: carrier.2.e164.arpa carrier.3.2.e164.arpa carrier.4.3.2.e164.arpa in turn. This is a remarkably bad idea. Playing the game of "hunt the domain name" by walking up or down the tree is asking for trouble. It will create lots of operational problems, like unpredictable results. It will have serious performance impact too. For example, suppose an application wants to dial 1234567890. A lookup of carrier.1.e164.arpa returns NXDOMAIN. That could mean 1.e164.arpa does not exist, so the application would try carrier.2.1.e164.arpa and so on, getting an NXDOMAIN every time all the way to carrier.0.9.8.7.6.5.4.3.2.1.e164.arpa before giving up and reporting a failure. Bad. Bad. Bad. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mstjohns@mindspring.com Wed, 22 Jun 2005 14:51:17 -0400 From: Michael StJohns Date: Wed, 22 Jun 2005 14:51:17 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203F@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050622144017.04f1fa10@pop.mindspring.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 11:27 AM 6/22/2005, Clive D.W. Feather wrote: It's only an issue for carriers, who can maintain a table. You're much more optimistic than I am in that you think you know who will actually end up needing to use this data. For example, will the non-carrier billing people need access? Will the emergency services folks (911, 999) need access? Etc. Given the number of people who have glommed onto the DNS as their solution to some pretty weird problems you should expect a lot of glomming onto ENUM of both the carrier and user sort going forward. * It's not much data to maintain, since there's a fixed set of 1- and 2-digit codes and all others are 3 digit. The key word here is "fixed". NOTHING is fixed in the digital world - it just looks like it from a pov of only a few years wide. Let's say that in 10 years the whole CC mess goes by the wayside because it doesn't fit well with VOIP - but that it can't go by the wayside because the design has locked in certain assumptions on how the data is formatted. The argument that you can go out and get the new mappings is interesting, but without merit unless those mappings are maintained within the DNS itself and the updates are part of the DNS protocol. E.g. how do you ensure that you've contacted everyone that needs to know about a change? How do you coordinate a change? * Given that, it's not actually impractical to always do it at the 3-digit level and have the 1- and 2-digit countries have multiple entries. Hmm... you mean carrier.0.3.1.e164.arpa to represent area codes 300-309? I don't think that's practical and I'm pretty sure that any scheme for +1 that doesn't break delegation points at the CC and area code boundaries won't fly. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Wed, 22 Jun 2005 15:14:13 -0400 From: Michael Haberler Date: Wed, 22 Jun 2005 15:14:13 -0400 To: enum at ietf.org Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <6.2.1.2.2.20050622211330.04116c10@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 17:31 22.06.2005, Stastny Richard wrote: As I said I the other reply I did originally not mean this but this is an valid option. To know the apprx 200 Country codes is a non-starter for Actually, this is a "starter". The country code and its length can be trivially extracted from a given number. See the code here: http://mah.priv.at/enum/cc_code.c . As long as ITU sticks to its allocation rules, that piece of code does the job fine. As a safety net for the non-believers, an appropriate "marker" record could be inserted at the cc boundary and cached at the client. -Michael user ENUM and clients, but not for carriers, they have to know this anyway (they currently have to know nuch more) You just have to maintain the table provided regularly at http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html Richard ________________________________ Von: Michael StJohns [mailto:mstjohns at mindspring.com] Gesendet: Mi 22.06.2005 17:18 An: Stastny Richard; lconroy Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. At 07:56 AM 6/22/2005, Stastny Richard wrote: >c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T >only on the side, but definitely the national regulators. >The international policy framework may be taken basically as is, but >national policy needs to be amended. So the time taken is a national >matter, but it may be easier and faster to set-up (less involved >parties) >The other benefit: National regulators may be forced by the carriers >to opt-in to e164.arpa, which may be of benefit also for User ENUM. >-> Continue where we are. _______________________________________________ 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 Paul.Rosbotham@cwmsg.cwplc.com Wed, 22 Jun 2005 15:19:45 -0400 From: "Rosbotham, Paul" Date: Wed, 22 Jun 2005 15:19:45 -0400 To: Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <9322B78036E1534A99B0BC51DEB0F9D60101BC0D@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Indeed. Typically we have to maintain data at 7-9 digits (inc country code), depending on the destination. However, approaching this as a potential customer of infrastructure-ENUM (being a competitive carrier in some countries and the "incumbent" in many more), the approach of carrier.c.c.e164.arpa doesn't overcome the concerns that I have about sharing the top level domain. The world has moved on, and a series of delegations have already been made in the .e164.arpa domain. Typically, for the delegations already made, telcos have played little or no part...it has not been seen as part of their core telephony business, though potentially of interest for the ISP side of the house. For example, a series of countries where Cable & Wirelss is the incumbent have made such delegations, and that's not something that's overly concerned us so long as the companies concerned are known to be legitimate. Now, if infrastructure-ENUM is going to be used for routeing of the public telephone service, the landscape dramatically changes. Certainly, where carriers in a given country are entering their routeing data, they would wish to give consideration to whether the administration/operation of the Tier-1 registry for infrastructure-ENUM in their country should be an entity jointly owned by the stakeholders (ie the carriers). I'd go as far as to predict that many carriers would simply not load their data into a Tier-1 over which they have no direct or indirect control. Without data an infrastructure-ENUM would be of limited use... Unfortunately, in a series of locations (user) ENUM has already moved on sufficiently far that such considerations would be too late if an attempt was made to shoe-horn user- and infrastructure- ENUM into the same domain : the Tier-1 has already or will be imminently awarded. Now, following carrier.c.c.e164.arpa logic, the carrier queries would still go via the (already selected) Tier-1, albeit only for a single entry rather than one per number. If it had to be in .e164.arpa, the other way around (c.c.carrier.e164.arpa) would seem to be the way to avoid the issues I raise. Regards Paul -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Wednesday, June 22, 2005 4:31 PM To: Michael StJohns; lconroy Cc: enum at ietf.org; Richard Shockey Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful As I said I the other reply I did originally not mean this but this is an valid option. To know the apprx 200 Country codes is a non-starter for user ENUM and clients, but not for carriers, they have to know this anyway (they currently have to know nuch more) You just have to maintain the table provided regularly at http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html Richard ________________________________ Von: Michael StJohns [mailto:mstjohns at mindspring.com] Gesendet: Mi 22.06.2005 17:18 An: Stastny Richard; lconroy Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. At 07:56 AM 6/22/2005, Stastny Richard wrote: >c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T >only on the side, but definitely the national regulators. >The international policy framework may be taken basically as is, but >national policy needs to be amended. So the time taken is a national >matter, but it may be easier and faster to set-up (less involved >parties) >The other benefit: National regulators may be forced by the carriers >to opt-in to e164.arpa, which may be of benefit also for User ENUM. >-> Continue where we are. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Wed, 22 Jun 2005 15:21:08 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 22 Jun 2005 15:21:08 -0400 To: lconroy Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: <003F1AF1-C70E-484B-9211-C1B7DC13E237@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 07:00, lconroy wrote: Re. update to 3761: RFC3761 doesn't stand alone. I fear that we *may* need to update 3402 (and definitely should update 3403). For example, 3403 section 4.1 has text in the description of the REGEXP field that is (at least), "not transparent". For DDDS Applications like ENUM/E2U that generate URIs, it does not help - is this field used for a domain name or for a URI (and how do you tell)? That particular section needs to be clear as clients NEED to know what is allowed and what is not (and how to interpret the field contents). Point taken. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 15:41:00 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 15:41:00 -0400 To: "Rosbotham, Paul" Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF92@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Paul, I see your point, but I think you are a bit overoptimistic on the capability of the carriers to agree on an entity "jointly owned by the stakeholders" ;-) Take UK (or Austria) as an example, where the "stakeholders" where not able to agree on a j"ointly owned" datebase for NP, even if they loose money with this decision. On the other hand, the current Tier 1 Registries are in most counties selected by the Regulator as the domain name holder and also in most cases the ccTLDs or other companier within this business. These enties know how to do their jobs and a lot of business of the telcos is dependant on their operations anyway. Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Rosbotham, Paul Gesendet: Mi 22.06.2005 21:19 An: enum at ietf.org Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Indeed. Typically we have to maintain data at 7-9 digits (inc country code), depending on the destination. However, approaching this as a potential customer of infrastructure-ENUM (being a competitive carrier in some countries and the "incumbent" in many more), the approach of carrier.c.c.e164.arpa doesn't overcome the concerns that I have about sharing the top level domain. The world has moved on, and a series of delegations have already been made in the .e164.arpa domain. Typically, for the delegations already made, telcos have played little or no part...it has not been seen as part of their core telephony business, though potentially of interest for the ISP side of the house. For example, a series of countries where Cable & Wirelss is the incumbent have made such delegations, and that's not something that's overly concerned us so long as the companies concerned are known to be legitimate. Now, if infrastructure-ENUM is going to be used for routeing of the public telephone service, the landscape dramatically changes. Certainly, where carriers in a given country are entering their routeing data, they would wish to give consideration to whether the administration/operation of the Tier-1 registry for infrastructure-ENUM in their country should be an entity jointly owned by the stakeholders (ie the carriers). I'd go as far as to predict that many carriers would simply not load their data into a Tier-1 over which they have no direct or indirect control. Without data an infrastructure-ENUM would be of limited use... Unfortunately, in a series of locations (user) ENUM has already moved on sufficiently far that such considerations would be too late if an attempt was made to shoe-horn user- and infrastructure- ENUM into the same domain : the Tier-1 has already or will be imminently awarded. Now, following carrier.c.c.e164.arpa logic, the carrier queries would still go via the (already selected) Tier-1, albeit only for a single entry rather than one per number. If it had to be in .e164.arpa, the other way around (c.c.carrier.e164.arpa) would seem to be the way to avoid the issues I raise. Regards Paul -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Wednesday, June 22, 2005 4:31 PM To: Michael StJohns; lconroy Cc: enum at ietf.org; Richard Shockey Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful As I said I the other reply I did originally not mean this but this is an valid option. To know the apprx 200 Country codes is a non-starter for user ENUM and clients, but not for carriers, they have to know this anyway (they currently have to know nuch more) You just have to maintain the table provided regularly at http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html Richard ________________________________ Von: Michael StJohns [mailto:mstjohns at mindspring.com] Gesendet: Mi 22.06.2005 17:18 An: Stastny Richard; lconroy Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful One other point - assuming I understand what you want (- e.g. carrier.1.e164.arpa for CC 1). I believe this will require the end resolver to know where the country code ends for all given country codes. And that makes this option pretty much a non-starter. At 07:56 AM 6/22/2005, Stastny Richard wrote: >c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd ITU-T >only on the side, but definitely the national regulators. >The international policy framework may be taken basically as is, but >national policy needs to be amended. So the time taken is a national >matter, but it may be easier and faster to set-up (less involved >parties) >The other benefit: National regulators may be forced by the carriers >to opt-in to e164.arpa, which may be of benefit also for User ENUM. >-> Continue where we are. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ 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 mah@inode.at Wed, 22 Jun 2005 15:43:22 -0400 From: Michael Haberler Date: Wed, 22 Jun 2005 15:43:22 -0400 To: enum at ietf.org Subject: [Enum] CC length computation from number Message-ID: <6.2.1.2.2.20050622213757.05172480@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO here's a test on the current table from http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html, massaged into http://mah.priv.at/enum/cc_code_test.c the test program to check all these cc's is in http://mah.priv.at/enum/cc_code_test.c mah at www:~$ gcc -DTEST cc_code_test.c .. mah at www:~$ ./a.out Date: Wed, 22 Jun 2005 15:45:58 -0400 To: Stastny Richard Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF8F@oefeg-s04.oefeg.loc> Message-ID: <9DC44BF8-4A65-4ED2-8136-9A7B532D26A0@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 07:41, Stastny Richard wrote: c1: using non-terminals c2. using terminal NAPTRs both options having these NAPTRs side-by-side in tier 1. c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa I considered this option as ugly and requiering special clients, to derieve the domain to query from the E.164 number and knowing the CC structure, but as Lawrence pointed out, carriers should know this anyway ;-) Carriers, yes, but think of the poor stupid device that want to use the information the carriers have put in dns? I.e. only carriers might store things there, everyone might do lookups. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 22 Jun 2005 15:51:11 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 15:51:11 -0400 To: "Michael Haberler" Subject: Re: [Enum] CC length computation from number Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF93@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >I've forgotten where the reference to the CC construction algorithm is. ITU >weenies to the front please... ITU-T Rec. 164 ? Richard PS: Since the number space is not exhausted yet, there is no significant change expected mid-term. (And in the long term we are all dead - Schumpeter) In any case there is not change to be expected to make the CC longer then 3 digits What is changing all the time is the assignment to countries, but this is basically a UNO problem and not an ITU-T problem ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Mi 22.06.2005 21:43 An: enum at ietf.org Betreff: [Enum] CC length computation from number here's a test on the current table from http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html, massaged into http://mah.priv.at/enum/cc_code_test.c the test program to check all these cc's is in http://mah.priv.at/enum/cc_code_test.c mah at www:~$ gcc -DTEST cc_code_test.c .. mah at www:~$ ./a.out Date: Wed, 22 Jun 2005 15:51:27 -0400 To: enum at ietf.org Subject: Re: [Enum] CC length computation from number In-Reply-To: <6.2.1.2.2.20050622213757.05172480@localhost> Message-ID: <6.2.1.2.2.20050622215056.046eb1c8@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 21:43 22.06.2005, Michael Haberler wrote: here's a test on the current table from http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164.html, massaged into http://mah.priv.at/enum/cc_code_test.c sorry - my mistake: the test list is: http://mah.priv.at/enum/countrycodes.csv -Michael the test program to check all these cc's is in http://mah.priv.at/enum/cc_code_test.c mah at www:~$ gcc -DTEST cc_code_test.c .. mah at www:~$ ./a.out Date: Wed, 22 Jun 2005 15:59:34 -0400 To: Patrik Fältström Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO This has been a very interesting discussion of various technical options, but they may not fit everyone's' needs as we found out with the pfautz-lind I-D. One needs to be cognizant of the fact that in the US, we are in a regulatory environment where competition and end-user choice is very important. In the ENUM sense, that means for end-user ENUM, end-users should have their choice of Registrar and DNS provider to host their terminal NAPTR records. Putting those records in the Tier 1 has been, at least to date, not an option. And trying to accommodate the needs of carriers without tromping on the needs (or choices) of end users led us in a specific direction (i.e., the pfautz-lind I-D). The other factor in that choice of pathways was the desire for whatever was doing the ENUM query to get back as many of the records, user & carrier, as possible, and to apply whatever business model made sense for that entity to select the appropriate record to complete the communication. Some of your proposed alternatives, while not making such a direction impossible, will make looking for both sets of records less attractive. Steve Lind -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Patrik Fältström Sent: Wednesday, June 22, 2005 3:46 PM To: Stastny Richard Cc: enum at ietf.org; lconroy; Richard Shockey Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful On Jun 22, 2005, at 07:41, Stastny Richard wrote: > c1: using non-terminals > c2. using terminal NAPTRs > both options having these NAPTRs side-by-side > in tier 1. > > c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa > I considered this option as ugly and requiering special clients, > to derieve the domain to query from the E.164 number and > knowing the CC structure, but as Lawrence pointed out, > carriers should know this anyway ;-) > Carriers, yes, but think of the poor stupid device that want to use the information the carriers have put in dns? I.e. only carriers might store things there, everyone might do lookups. 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 Richard.Stastny@oefeg.at Wed, 22 Jun 2005 16:21:03 -0400 From: "Stastny Richard" Date: Wed, 22 Jun 2005 16:21:03 -0400 To: Patrik Fältström Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF94@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO >Carriers, yes, but think of the poor stupid device that want to use >the information the carriers have put in dns? I.e. only carriers >might store things there, everyone might do lookups. No stupid device will ever look at this information; the carrier tree is onyl for carrier use and will in most case point to servers not accessible by end-users anyway Richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Mi 22.06.2005 21:45 An: Stastny Richard Cc: lconroy; enum at ietf.org; Richard Shockey Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful On Jun 22, 2005, at 07:41, Stastny Richard wrote: > c1: using non-terminals > c2. using terminal NAPTRs > both options having these NAPTRs side-by-side > in tier 1. > > c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa > I considered this option as ugly and requiering special clients, > to derieve the domain to query from the E.164 number and > knowing the CC structure, but as Lawrence pointed out, > carriers should know this anyway ;-) > Carriers, yes, but think of the poor stupid device that want to use the information the carriers have put in dns? I.e. only carriers might store things there, everyone might do lookups. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Paul.Rosbotham@cwmsg.cwplc.com Wed, 22 Jun 2005 16:27:35 -0400 From: "Rosbotham, Paul" Date: Wed, 22 Jun 2005 16:27:35 -0400 To: "Stastny Richard" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <9322B78036E1534A99B0BC51DEB0F9D60101BC0F@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO You know me, Richard, ever the optimist ;-) The reason the UK couldn't agree on a jointly owned database for NP is that we didn't want to as we never accepted the need for said database....on the contrary to what you say, for the volumes of numbers currently ported and our particular network inventory, it would have been less efficient than the solution we have in place - as has been proven by independent consultants....but that's a different discussion. I don't think an argument of "you guys will never agree so we've made the decision for you, and the choice we've made is a good one, so take it or leave it" will be particularly successful. The response from some parties will certainly be "OK, we'll leave it then and not bother populating" - which will seriously devalue the proposition. (BTW, my concern isn't specifically with the UK...I could reel off a list of other countries where I'd have similar issues) Cheers Paul -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, June 22, 2005 8:44 PM To: Rosbotham, Paul; enum at ietf.org Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Hi Paul, I see your point, but I think you are a bit overoptimistic on the capability of the carriers to agree on an entity "jointly owned by the stakeholders" ;-) Take UK (or Austria) as an example, where the "stakeholders" where not able to agree on a j"ointly owned" datebase for NP, even if they loose money with this decision. On the other hand, the current Tier 1 Registries are in most counties selected by the Regulator as the domain name holder and also in most cases the ccTLDs or other companier within this business. These enties know how to do their jobs and a lot of business of the telcos is dependant on their operations anyway. Richard This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Wed, 22 Jun 2005 17:47:42 -0400 From: Michael Haberler Date: Wed, 22 Jun 2005 17:47:42 -0400 To: "Rosbotham, Paul" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <9322B78036E1534A99B0BC51DEB0F9D60101BC0F@GBCWSWIEM002.ad.plc.cwintra.com> Message-ID: <6.2.1.2.2.20050622225502.05503070@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 22:07 22.06.2005, Rosbotham, Paul wrote: The reason the UK couldn't agree on a jointly owned database for NP is that we didn't want to as we never accepted the need for said database....on the contrary to [not strictly protocol related] the NP dog clearly hunts with varying success per country, yes - BUT if porting rates in +43 were as they were elsewhere local telcos would just die to have a NP DB here next week ( can I say "porting by fax exchange" ) . Process design is a matter of scale - but then asymptotically NP rates will be like registrar change on a TLD, assuming numbers live as long. speaking of dogs - in business terms: the user ENUM dog doesnt hunt adaequately (authoritative report from the blind) - enlightened service provider & business acceptance is there, significant end user acceptance is way out - all while per-country opt in kills resolution rates. This is a horizontal standard rollout with the vertical per-country brake put on - it's like "no, we dont do HTTP over here in France". IP interconnect happens, but carrier ENUM as of today might cannibalize itself into X different trees, each one with a little twist a combined approach might save the day for user ENUM long run while giving carriers what they want now, with the upside of better resolution rates - and helpfully turn on the second burner under your regulator's back to improve footprint. the e164.arpa carrier space could well work as an umbrella for all those e164.* efforts - and and eventual migration tool - while keeping the end user vision alive. That warrants a bit of enlightened decision making. Still, then everybody is free to establish e164.foo.tld - this is the Internet. Minitel-over-IP does indeed work, too, as long as somebody pays for it. -Michael what you say, for the volumes of numbers currently ported and our particular network inventory, it would have been less efficient than the solution we have in place - as has been proven by independent consultants....but that's a different discussion. I don't think an argument of "you guys will never agree so we've made the decision for you, and the choice we've made is a good one, so take it or leave it" will be particularly successful. The response from some parties will certainly be "OK, we'll leave it then and not bother populating" - which will seriously devalue the proposition. (BTW, my concern isn't specifically with the UK...I could reel off a list of other countries where I'd have similar issues) Cheers Paul -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, June 22, 2005 8:44 PM To: Rosbotham, Paul; enum at ietf.org Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Hi Paul, I see your point, but I think you are a bit overoptimistic on the capability of the carriers to agree on an entity "jointly owned by the stakeholders" ;-) Take UK (or Austria) as an example, where the "stakeholders" where not able to agree on a j"ointly owned" datebase for NP, even if they loose money with this decision. On the other hand, the current Tier 1 Registries are in most counties selected by the Regulator as the domain name holder and also in most cases the ccTLDs or other companier within this business. These enties know how to do their jobs and a lot of business of the telcos is dependant on their operations anyway. Richard This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ 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 Wed, 22 Jun 2005 21:42:13 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Wed, 22 Jun 2005 21:42:13 -0400 To: Stastny Richard Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF94@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 13:10, Stastny Richard wrote: Carriers, yes, but think of the poor stupid device that want to use the information the carriers have put in dns? I.e. only carriers might store things there, everyone might do lookups. No stupid device will ever look at this information; the carrier tree is onyl for carrier use and will in most case point to servers not accessible by end-users anyway Wait a bit...if the data is not accessible for anyone (publicly available), it should be in a part of the namespace that is not known to others than the ones that have to know. Else you will get errors that is only possible to detect by waiting for a timeout in the DNS lookup, and that is not good enough. That will definitely slow down the ENUM lookup too much. So, what should be stored under e164.arpa is only data that is publicly available. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Thu, 23 Jun 2005 03:01:40 -0400 From: Michael Haberler Date: Thu, 23 Jun 2005 03:01:40 -0400 To: Patrik Fältström Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF94@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050623084116.04c1b310@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 03:41 23.06.2005, Patrik Fältström wrote: On Jun 22, 2005, at 13:10, Stastny Richard wrote: ... No stupid device will ever look at this information; the carrier tree is onyl for carrier use and will in most case point to servers not accessible by end-users anyway ... So, what should be stored under e164.arpa is only data that is publicly available. "publicly available" doesnt necessarily translate into "openly reachable for everybody" - we have that situation already now in the public ENUM tree over here: people make an ENUM entry for their number (eg +43 780 123456) pointing to sip:foo at provider.at - which drives the Generic Gateway for +43 780 * (virtual number access service) however, some qualifiy INVITES to their proxy on the originating IP address range - if it comes from the gateway, fine - if somebody else sends an INVITE, he gets a '407 Proxy Authentication Required' as a response so that entry is public and conformant but not openly reachable or is "openly reachable" a requirement posed on all URI's under e164.arpa ? It might be an implicit assumption but I havent seen such a requirement -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 23 Jun 2005 03:14:31 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 03:14:31 -0400 To: "Lind, Steven D, ALABS" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2044@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Steve, > > This has been a very interesting discussion of various technical options, > but they may not fit everyone's' needs as we found out with the pfautz- > lind I-D. Could you please elaborate which of the discussed options do NOT fit "everyone's" needs? > One needs to be cognizant of the fact that in the US, we are in > a regulatory environment where competition and end-user choice is very > important. Agreed. But I as an end-user want to have the choice to STAY in e164.arpa And to not want to be thrown out because a carrier decided to opt-in. > In the ENUM sense, that means for end-user ENUM, end-users > should have their choice of Registrar and DNS provider to host their > terminal NAPTR records. Exactly, and my choice is e.g. 1.1.2.2.0.3.0.2.7.3.4.e164.arpa, where I put my sip URI > Putting those records in the Tier 1 has been, at > least to date, not an option. Nobody proposed to put e.g. a NAPTR pointing to a SIP URI in Tier 1. Maybe you did not completely understood the options. > And trying to accommodate the needs of > carriers without tromping on the needs (or choices) of end users led us in > a specific direction (i.e., the pfautz-lind I-D). But with your proposal you are tromping all existing ENUM implementations worldwide. I understand an US centric view, but you should consider that CC+1 is not even delegated yet in e164.arpa, whereas over 30 countries already are. They all would have to change. > > The other factor in that choice of pathways was the desire for whatever > was doing the ENUM query to get back as many of the records, user & > carrier, as possible, and to apply whatever business model made sense for > that entity to select the appropriate record to complete the > communication. Again, please elaborate which of the other options is not allowing this > Some of your proposed alternatives, while not making such a > direction impossible, will make looking for both sets of records less > attractive. Huh? Please elaborate why? Only in the carrier.c.c.164.arpa proposal, where you need two queries. In your proposal to get the data of all alternatives you need at least 4 queries. To be precise, in this regard your proposal is the worst. Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > > Steve Lind > > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Patrik Fältström > Sent: Wednesday, June 22, 2005 3:46 PM > To: Stastny Richard > Cc: enum at ietf.org; lconroy; Richard Shockey > Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > > On Jun 22, 2005, at 07:41, Stastny Richard wrote: > > > c1: using non-terminals > > c2. using terminal NAPTRs > > both options having these NAPTRs side-by-side > > in tier 1. > > > > c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa > > I considered this option as ugly and requiering special clients, > > to derieve the domain to query from the E.164 number and > > knowing the CC structure, but as Lawrence pointed out, > > carriers should know this anyway ;-) > > > > Carriers, yes, but think of the poor stupid device that want to use > the information the carriers have put in dns? I.e. only carriers > might store things there, everyone might do lookups. > > 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 hannsjuergen.schwarzbauer@siemens.com Thu, 23 Jun 2005 03:43:27 -0400 From: Schwarzbauer Hanns Juergen Date: Thu, 23 Jun 2005 03:43:27 -0400 To: "'Stastny Richard'" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard, just one question: in 1.2.3.4.carrier.cc.e164.arpa, the field named "carrier" is NOT assumed to be replaced by the "name of the operator servicing that very number". It is only used to separate the carrier part of the tree. Otherwise it would impact the way ported numbers are handled greetings HannsJuergen -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: Wednesday, June 22, 2005 4:41 PM To: Patrik Fältström Cc: enum at ietf.org; lconroy; Richard Shockey Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful Thank you Patrik for this clarification. I also agree that option c is preferable During the discussion a third alternative showed up: c1: using non-terminals c2. using terminal NAPTRs both options having these NAPTRs side-by-side in tier 1. c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa I considered this option as ugly and requiering special clients, to derieve the domain to query from the E.164 number and knowing the CC structure, but as Lawrence pointed out, carriers should know this anyway ;-) The advantage of this solution would be that User ENUM in e164.arpa remains completely untouched. User Clients would normally never see these domains The second advantage is that in case c1 and c2 ALWAYS two or three queries are necessary, in case c3 only one, both for user and carrier. The "ugly part" remains with the carriers, and they may deserve this anyway ;-) Richard ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Mi 22.06.2005 15:23 An: Stastny Richard Cc: lconroy; enum at ietf.org; Richard Shockey Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful On Jun 22, 2005, at 04:56, Stastny Richard wrote: > The following options exists: > Put the Carriers in: > a. e164carrier.arpa - this requires only the IAB and does not involve > ITU-T > BUT requires a policy framework to be set up by whom? This may take > some time even to create a body. -> Restart at square -1 Having two domains in the DNS not technically bound to each other (i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions regarding policy for who runs the (two) domains. Having them synchronized in any way will be a nightmare, and, it forces the local regulative bodies that already have had headache over "who will run cc.e164.arpa" to wake up again. > b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the > national regulators. > BUT involves for policy mainly the ITU-T. So the body is known, but > since even the interim procedures are not places in a Rec. yet ... > -> restart at square 1 See earlier bullet. Similar problems, as you point out. > c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd > ITU-T > only on the side, but definitely the national regulators. > The international policy framework may be taken basically as is, but > national policy needs to be amended. So the time taken is a national > matter, but it may be easier and faster to set-up (less involved > parties) Correct. The policy have to be adjusted in some cases, but the policy work is, I claim, not at all as heavy as the previous suggestions. > The other benefit: National regulators may be forced by the carriers > to opt-in to e164.arpa, which may be of benefit also for User ENUM. > -> Continue where we are. > > Conclusion: option c may not be the optimal solution, but it will > be definitely the fastest for the carriers and also be of some > benefit for User ENUM. I agree. paf > Additional remark: > Other trees may and will co-exist, but any tree in e164.arpa may > serve as a glue. GSMA operators just need to put a pointer in to > ;enum-context=e164.enum.net > > Regards > Richard > > > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > > > >> -----Original Message----- >> From: lconroy [mailto:lconroy at insensate.co.uk] >> Sent: Wednesday, June 22, 2005 1:40 PM >> To: Stastny Richard >> Cc: 'enum at ietf.org' ENUM; Richard Shockey >> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful >> >> Hi Richard, Richard, folks, >> This proposal should work, albeit it will take effort and => time to >> analyse and >> get the specifications in place - at least it doesn't directly >> > conflict > >> with 3761. >> >> N-Ts are, as you spell out, evil (and the existing specs are, at >> best, >> complex in >> this area). >> >> However... As an alternative: >> >> Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers >> aren't, why >> not just have a sub-domain (for example carrier.e164.arpa.) >> specifically for Carriers >> to populate and query, and leave the Users where they are? >> >> Basically, if the carriers are looking somewhere else, then ALL of >> the >> problems go away. >> >> The carriers and their suppliers have much better "connections" to >> ITU >> (and, arguably, to >> the IAB and IETF - see current discussion on WG chair commitments on >> the IETF-general list). >> If the agreements need to be changed at all, then the >> carriers/suppliers will have to do >> this policy (re-)development work anyway. >> >> I am still waiting for convincing arguments justifying the clearance >> > of > >> users from the >> space allocated for user ENUM. >> >> So far, we seem to have missed that completely. >> >> all the best, >> Lawrence >> >> On 22 Jun 2005, at 11:50, Stastny Richard wrote: >> >>> Dear all, >>> >>> The proposal brought forward in >>> draft-pfautz-lind-enum-carrier-user-00 >>> raises two issues: >>> >>> 1) Should (user) ENUM and Infrastructure (Carrier) ENUM >>> implementations be mixed within e.164.arpa? >>> >>> 2) If yes, how should this be done technically? >>> >>> Regarding 1) I have submitted to the list the position of >>> ETSI TISPAN WG4 in a previous post, containing the pro and cons. >>> >>> So I want to concentrate here on issue 2) only: >>> >>> draft-pfautz-lind-enum-carrier-user-00 proposes >>> the usage of non-terminal NAPTRs to separate >>> between user and carrier entries in Tier 1 of >>> e164.arpa >>> >>> The usage of non-terminals creates many problems, >>> (see below), so I consider this harmful. >>> >>> It is therefore proposed to consider the usage >>> of terminal NAPTRs to solve the problem at hand, >>> a technical proposal is also contained below. >>> This proposal does not solve all problems raised >>> with non-terminals below, but most of them. >>> >>> Problems with non-terminal NAPTRs: >>> >>> The first problem with non-terminals is non-conformant >>> with RFC3761: >>> >>> Although RFC3761 allows the usage of non-terminals >>> (section 1.3 and 2.4), the intrinsic assumption is >>> that in this case there is no Enumservice used >>> in the service field (beside E2U). >>> >>> Basically the template in RFC3671 to register a >>> Enumservice cannot be used as is, because in section >>> 3.1.1 is stated: >>> "A registered Enumservice must be able to function as >>> a selection mechanism when choosing one NAPTR resource >>> record from another. That means that the registration >>> MUST specify what is expected when using that very NAPTR >>> record, and the URI which is the outcome of the use of it. >>> >>> Specifically, a registered Enumservice MUST specify the >>> URI scheme(s) that may be used for the Enumservice, ..." >>> >>> So a URI definition such as "N/A" or "Any" is not allowed. >>> >>> Additional problems: >>> >>> -existing users are forced to move out of e164.arpa >>> -Non-Terminals are not supported in existing clients >>> -Non-Terminals involve multiple DNS queries >>> -No Glue Records in Non-Terminals >>> -Prone to "Error in User" >>> -Automatically checking the domain is not easy >>> -Pre-existing targets only (the privacy/control problem) >>> -Going in Circles, by accident or design >>> -Time To Live across domains >>> -Etc. >>> I think Lawrence is here better suited to explain these >>> problems more in detail, if required or requested. >>> >>> Proposal to use terminal NAPTRs >>> >>> It is therefore proposed to use terminal NAPTRs >>> for this purpose: >>> >>> I propose to reuse the Enumservice "enum" as specified >>> in ETSI TS 102 172 for redirection: >>> >>> This Enumservice uses the "tel:" URI to instruct the >>> ENUM client to launch another ENUM query for the >>> E.164 number given in the "tel:" URI. The purpose is >>> to allow a user who has say three different E.164 numbers >>> registered in ENUM to point two of this numbers to the >>> third and maintain the real NAPTRs only in the domain >>> of the third. >>> >>> The default assumption with the tel: URI as given is >>> that the domain to query is e164.arpa (ENUM) >>> >>> If now an additional parameter is defined for the tel: URI >>> e.g. ";enum-context=foo.bar", the behaviour could be >>> exactly the same, except that in step 4. of section 2.4 >>> in RFC3761 instead of e164.arpa the domain given in >>> enum-context is appended. This causes not much changes >>> to existing ENUM-clients, some of them already allow >>> a different apex from e164.arpa to be used or query two >>> different trees subsequently. >>> >>> If no enum-context is given, the ENUMservice "enum" works >>> as defined in TS 102 172 for e164.arpa >>> >>> The advantage of this proposal is: minimum change >>> to the user enum clients and all solutions for >>> variable length number plans and DDI work as usual. >>> >>> For the carrier part a new Enumservice "carrier" >>> is proposed which works in exactly the same way with >>> a "tel:" and in this case with a mandatory enum-context >>> parameter. >>> >>> Using the "tel: URI in this context provides an >>> additional bonus: the "tel:" URI may be used with >>> additional parameters, e.g. the ones defined >>> in draft-ietf-iptel-tel-np-05, especially ";rn=" and >>> ";cic=". This would allow carriers also to enter >>> data for numbers existing on the PSTN only and >>> providing national routing numbers or Carrier Identification >>> Codes, if required. Carriers may retrieve e.g a routing >>> number already in ENUM an save an additional IN-dip on the >>> PSTN. >>> >>> User ENUM clients do not need to be able to process NAPTRs >>> with Enumservice "carrier", they may ignore it. >>> >>> To implement this solution, an additional measure is necessary: >>> >>> If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR >>> cannot be stored in e164.arpa any longer (this is also true >>> for the non-terminal proposal). So the user MUST move out to >>> another domain e.g. as proposed to joesenum.com. Since there >>> is no reason normally for a user in e164.arpa suddenly to >>> go and look for an own domain if a carrier decides to opt-in, >>> there should be a default domain available also under e614.arpa, >>> where the Registrar or Nameserver provider can move the user >>> in this case. It is proposed to use user.e164.arpa for this >>> purpose. >>> >>> This requires a slight modification in the agreements between >>> IAB, RIPE and ITU-T insofar that >>> 1. this domain is created >>> 2. the delegation of this domain is always performed in >>> parallel and according the rules as defined in >>> the Interim Procedures for the delegation of e164.arpa >>> 3. Any existing delegation in e164.arpa gets an automatic >>> delegation to the same conditions e.g nameservers as stated >>> in the original request >>> >>> If carrier ENUM is implemented within e164.arpa and what the >>> national specific rules are is a national matter and has >>> to be added to the existing framework for User ENUM. >>> >>> Best regards >>> >>> Richard >>> >>> >>> Richard Stastny >>> OeFEG >>> tel:+43 664 420 4100 >>> enum:+43 780 203 211 >>> callto://fordprefect >>> http://voipandenum.blogspot.com >>> >>> >>> _______________________________________________ >>> enum mailing list >>> enum at ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >>> >>> >> --------------------------------------- >> lawrence conroy |tel:+44-1794-833666 >> > > > _______________________________________________ > 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 Richard.Stastny@oefeg.at Thu, 23 Jun 2005 04:10:20 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 04:10:20 -0400 To: "Schwarzbauer Hanns Juergen" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2045@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO HansJürgen, in the 1.2.3.4.carrier.cc.e164.arpa option, no additional Enumservices etc. are needed, this is plain ENUM. In carrier.cc.e164.arpa domain (the carrier Tier 1) NS records point to tier 2 domains e.g. 1.2.3.4.carrier.cc.e164.arpa, containing "normal" NAPTR records, e.g. with Enumservice "sip". The only "ugly" issue here is that the carriers will need to know the country codes to find the carrier Tier 1 e.g. carrier.9.4.e164.arpa and the Tier 1 label "carrier" has to be agreed upon. The doubts by some netheads that the carriers may not be able to find out the country codes sheds some light on the opinion some netheads have about the intelligence of the bellheads ;-) Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: Schwarzbauer Hanns Juergen > [mailto:hannsjuergen.schwarzbauer at siemens.com] > Sent: Thursday, June 23, 2005 9:43 AM > To: Stastny Richard; Patrik Fältström > Cc: enum at ietf.org; lconroy; Richard Shockey > Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful > > Richard, > > just one question: > in 1.2.3.4.carrier.cc.e164.arpa, the field named "carrier" is NOT assumed > to be replaced by the "name of the operator servicing that very number". > It is only used to separate the carrier part of the tree. > Otherwise it would impact the way ported numbers are handled > > greetings > > HannsJuergen > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Stastny Richard > Sent: Wednesday, June 22, 2005 4:41 PM > To: Patrik Fältström > Cc: enum at ietf.org; lconroy; Richard Shockey > Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > Thank you Patrik for this clarification. > > I also agree that option c is preferable > > During the discussion a third alternative showed up: > > c1: using non-terminals > c2. using terminal NAPTRs > both options having these NAPTRs side-by-side > in tier 1. > > c3: moving the carriers to e.g 1.2.3.4.carrier.c.c.e164.arpa > I considered this option as ugly and requiering special clients, > to derieve the domain to query from the E.164 number and > knowing the CC structure, but as Lawrence pointed out, > carriers should know this anyway ;-) > > The advantage of this solution would be that User ENUM > in e164.arpa remains completely untouched. User Clients > would normally never see these domains > > The second advantage is that in case c1 and c2 ALWAYS > two or three queries are necessary, in case c3 only one, > both for user and carrier. > > The "ugly part" remains with the carriers, and they may deserve this > anyway ;-) > > Richard > > > > ________________________________ > > Von: Patrik Fältström [mailto:paf at cisco.com] > Gesendet: Mi 22.06.2005 15:23 > An: Stastny Richard > Cc: lconroy; enum at ietf.org; Richard Shockey > Betreff: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > > > On Jun 22, 2005, at 04:56, Stastny Richard wrote: > > > The following options exists: > > Put the Carriers in: > > a. e164carrier.arpa - this requires only the IAB and does not involve > > ITU-T > > BUT requires a policy framework to be set up by whom? This may take > > some time even to create a body. -> Restart at square -1 > > Having two domains in the DNS not technically bound to each other > (i.e. 6.4.e164.arpa and 6.4.e164carrier.arpa) will create discussions > regarding policy for who runs the (two) domains. Having them > synchronized in any way will be a nightmare, and, it forces the local > regulative bodies that already have had headache over "who will run > cc.e164.arpa" to wake up again. > > > b. carrier.e164.arpa - involves IAB and ITU-T but may not involve the > > national regulators. > > BUT involves for policy mainly the ITU-T. So the body is known, but > > since even the interim procedures are not places in a Rec. yet ... > > -> restart at square 1 > > See earlier bullet. Similar problems, as you point out. > > > c. carrier in c.c.e164.arpa (tier 1 as proposed) involves IAB amd > > ITU-T > > only on the side, but definitely the national regulators. > > The international policy framework may be taken basically as is, but > > national policy needs to be amended. So the time taken is a national > > matter, but it may be easier and faster to set-up (less involved > > parties) > > Correct. The policy have to be adjusted in some cases, but the policy > work is, I claim, not at all as heavy as the previous suggestions. > > > The other benefit: National regulators may be forced by the carriers > > to opt-in to e164.arpa, which may be of benefit also for User ENUM. > > -> Continue where we are. > > > > Conclusion: option c may not be the optimal solution, but it will > > be definitely the fastest for the carriers and also be of some > > benefit for User ENUM. > > I agree. > > paf > > > Additional remark: > > Other trees may and will co-exist, but any tree in e164.arpa may > > serve as a glue. GSMA operators just need to put a pointer in to > > ;enum-context=e164.enum.net > > > > Regards > > Richard > > > > > > > > Richard Stastny > > OeFEG > > tel:+43 664 420 4100 > > enum:+43 780 203 211 > > callto://fordprefect > > http://voipandenum.blogspot.com > > > > > > > >> -----Original Message----- > >> From: lconroy [mailto:lconroy at insensate.co.uk] > >> Sent: Wednesday, June 22, 2005 1:40 PM > >> To: Stastny Richard > >> Cc: 'enum at ietf.org' ENUM; Richard Shockey > >> Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > >> > >> Hi Richard, Richard, folks, > >> This proposal should work, albeit it will take effort and => time to > >> analyse and > >> get the specifications in place - at least it doesn't directly > >> > > conflict > > > >> with 3761. > >> > >> N-Ts are, as you spell out, evil (and the existing specs are, at > >> best, > >> complex in > >> this area). > >> > >> However... As an alternative: > >> > >> Given that Users are in x..x.c..c.e164.arpa. already, whilst Carriers > >> aren't, why > >> not just have a sub-domain (for example carrier.e164.arpa.) > >> specifically for Carriers > >> to populate and query, and leave the Users where they are? > >> > >> Basically, if the carriers are looking somewhere else, then ALL of > >> the > >> problems go away. > >> > >> The carriers and their suppliers have much better "connections" to > >> ITU > >> (and, arguably, to > >> the IAB and IETF - see current discussion on WG chair commitments on > >> the IETF-general list). > >> If the agreements need to be changed at all, then the > >> carriers/suppliers will have to do > >> this policy (re-)development work anyway. > >> > >> I am still waiting for convincing arguments justifying the clearance > >> > > of > > > >> users from the > >> space allocated for user ENUM. > >> > >> So far, we seem to have missed that completely. > >> > >> all the best, > >> Lawrence > >> > >> On 22 Jun 2005, at 11:50, Stastny Richard wrote: > >> > >>> Dear all, > >>> > >>> The proposal brought forward in > >>> draft-pfautz-lind-enum-carrier-user-00 > >>> raises two issues: > >>> > >>> 1) Should (user) ENUM and Infrastructure (Carrier) ENUM > >>> implementations be mixed within e.164.arpa? > >>> > >>> 2) If yes, how should this be done technically? > >>> > >>> Regarding 1) I have submitted to the list the position of > >>> ETSI TISPAN WG4 in a previous post, containing the pro and cons. > >>> > >>> So I want to concentrate here on issue 2) only: > >>> > >>> draft-pfautz-lind-enum-carrier-user-00 proposes > >>> the usage of non-terminal NAPTRs to separate > >>> between user and carrier entries in Tier 1 of > >>> e164.arpa > >>> > >>> The usage of non-terminals creates many problems, > >>> (see below), so I consider this harmful. > >>> > >>> It is therefore proposed to consider the usage > >>> of terminal NAPTRs to solve the problem at hand, > >>> a technical proposal is also contained below. > >>> This proposal does not solve all problems raised > >>> with non-terminals below, but most of them. > >>> > >>> Problems with non-terminal NAPTRs: > >>> > >>> The first problem with non-terminals is non-conformant > >>> with RFC3761: > >>> > >>> Although RFC3761 allows the usage of non-terminals > >>> (section 1.3 and 2.4), the intrinsic assumption is > >>> that in this case there is no Enumservice used > >>> in the service field (beside E2U). > >>> > >>> Basically the template in RFC3671 to register a > >>> Enumservice cannot be used as is, because in section > >>> 3.1.1 is stated: > >>> "A registered Enumservice must be able to function as > >>> a selection mechanism when choosing one NAPTR resource > >>> record from another. That means that the registration > >>> MUST specify what is expected when using that very NAPTR > >>> record, and the URI which is the outcome of the use of it. > >>> > >>> Specifically, a registered Enumservice MUST specify the > >>> URI scheme(s) that may be used for the Enumservice, ..." > >>> > >>> So a URI definition such as "N/A" or "Any" is not allowed. > >>> > >>> Additional problems: > >>> > >>> -existing users are forced to move out of e164.arpa > >>> -Non-Terminals are not supported in existing clients > >>> -Non-Terminals involve multiple DNS queries > >>> -No Glue Records in Non-Terminals > >>> -Prone to "Error in User" > >>> -Automatically checking the domain is not easy > >>> -Pre-existing targets only (the privacy/control problem) > >>> -Going in Circles, by accident or design > >>> -Time To Live across domains > >>> -Etc. > >>> I think Lawrence is here better suited to explain these > >>> problems more in detail, if required or requested. > >>> > >>> Proposal to use terminal NAPTRs > >>> > >>> It is therefore proposed to use terminal NAPTRs > >>> for this purpose: > >>> > >>> I propose to reuse the Enumservice "enum" as specified > >>> in ETSI TS 102 172 for redirection: > >>> > >>> This Enumservice uses the "tel:" URI to instruct the > >>> ENUM client to launch another ENUM query for the > >>> E.164 number given in the "tel:" URI. The purpose is > >>> to allow a user who has say three different E.164 numbers > >>> registered in ENUM to point two of this numbers to the > >>> third and maintain the real NAPTRs only in the domain > >>> of the third. > >>> > >>> The default assumption with the tel: URI as given is > >>> that the domain to query is e164.arpa (ENUM) > >>> > >>> If now an additional parameter is defined for the tel: URI > >>> e.g. ";enum-context=foo.bar", the behaviour could be > >>> exactly the same, except that in step 4. of section 2.4 > >>> in RFC3761 instead of e164.arpa the domain given in > >>> enum-context is appended. This causes not much changes > >>> to existing ENUM-clients, some of them already allow > >>> a different apex from e164.arpa to be used or query two > >>> different trees subsequently. > >>> > >>> If no enum-context is given, the ENUMservice "enum" works > >>> as defined in TS 102 172 for e164.arpa > >>> > >>> The advantage of this proposal is: minimum change > >>> to the user enum clients and all solutions for > >>> variable length number plans and DDI work as usual. > >>> > >>> For the carrier part a new Enumservice "carrier" > >>> is proposed which works in exactly the same way with > >>> a "tel:" and in this case with a mandatory enum-context > >>> parameter. > >>> > >>> Using the "tel: URI in this context provides an > >>> additional bonus: the "tel:" URI may be used with > >>> additional parameters, e.g. the ones defined > >>> in draft-ietf-iptel-tel-np-05, especially ";rn=" and > >>> ";cic=". This would allow carriers also to enter > >>> data for numbers existing on the PSTN only and > >>> providing national routing numbers or Carrier Identification > >>> Codes, if required. Carriers may retrieve e.g a routing > >>> number already in ENUM an save an additional IN-dip on the > >>> PSTN. > >>> > >>> User ENUM clients do not need to be able to process NAPTRs > >>> with Enumservice "carrier", they may ignore it. > >>> > >>> To implement this solution, an additional measure is necessary: > >>> > >>> If Tier 1 contains both User and Carrier NAPTRs, the User NAPTR > >>> cannot be stored in e164.arpa any longer (this is also true > >>> for the non-terminal proposal). So the user MUST move out to > >>> another domain e.g. as proposed to joesenum.com. Since there > >>> is no reason normally for a user in e164.arpa suddenly to > >>> go and look for an own domain if a carrier decides to opt-in, > >>> there should be a default domain available also under e614.arpa, > >>> where the Registrar or Nameserver provider can move the user > >>> in this case. It is proposed to use user.e164.arpa for this > >>> purpose. > >>> > >>> This requires a slight modification in the agreements between > >>> IAB, RIPE and ITU-T insofar that > >>> 1. this domain is created > >>> 2. the delegation of this domain is always performed in > >>> parallel and according the rules as defined in > >>> the Interim Procedures for the delegation of e164.arpa > >>> 3. Any existing delegation in e164.arpa gets an automatic > >>> delegation to the same conditions e.g nameservers as stated > >>> in the original request > >>> > >>> If carrier ENUM is implemented within e164.arpa and what the > >>> national specific rules are is a national matter and has > >>> to be added to the existing framework for User ENUM. > >>> > >>> Best regards > >>> > >>> Richard > >>> > >>> > >>> Richard Stastny > >>> OeFEG > >>> tel:+43 664 420 4100 > >>> enum:+43 780 203 211 > >>> callto://fordprefect > >>> http://voipandenum.blogspot.com > >>> > >>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum at ietf.org > >>> https://www1.ietf.org/mailman/listinfo/enum > >>> > >>> > >>> > >> --------------------------------------- > >> lawrence conroy |tel:+44-1794-833666 > >> > > > > > > _______________________________________________ > > 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 jim@rfc1035.com Thu, 23 Jun 2005 05:19:56 -0400 From: Jim Reid Date: Thu, 23 Jun 2005 05:19:56 -0400 To: Michael Haberler Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF94@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 08:01, Michael Haberler wrote: "publicly available" doesnt necessarily translate into "openly reachable for everybody" Indeed. The DNS is just a way to make information publicly available. It makes no judgements about the content that's stored there. That said, advertising information in the public DNS about end-points that are not openly reachable is pointless. or is "openly reachable" a requirement posed on all URI's under e164.arpa ? It might be an implicit assumption but I havent seen such a requirement No. And I'm not sure this is an implicit assumption either. Perhaps it should be an explicit assumption. Maybe there should be an ENUM WG I-D along the lines of Philip Hazel's draft-ietf-dnsop-dontpublish-unreachable-03.txt which was about IP addresses that should never appear in the public DNS. The ENUM version would of course be concerned with unreachable URIs. Or URI end points that have access control filters in front of them. Technically, these are generally reachable: they're just not accessible to everyone. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 23 Jun 2005 06:09:40 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 06:09:40 -0400 To: "Jim Reid" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2047@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim, > The ENUM version > would of course be concerned with unreachable URIs. Or URI end points > that have access control filters in front of them. Technically, these > are generally reachable: they're just not accessible to everyone. Pls read RFC3764 Enumservice SIP 6. Security Considerations: (from our esteemed AD) ... Unlike a traditional telephone number, the resource identified by a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. ... Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Thu, 23 Jun 2005 06:32:18 -0400 From: Jim Reid Date: Thu, 23 Jun 2005 06:32:18 -0400 To: "Stastny Richard" Subject: [Enum] Access controls on URI end points (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2047@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 11:08, Stastny Richard wrote: The ENUM version would of course be concerned with unreachable URIs. Or URI end points that have access control filters in front of them. Technically, these are generally reachable: they're just not accessible to everyone. Pls read RFC3764 Enumservice SIP 6. Security Considerations: (from our esteemed AD) ... Unlike a traditional telephone number, the resource identified by a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. Richard, I have read RFC3764. What you've quoted above is different from what I was talking about. It is of course right and proper for SIP servers (or whatever) to insist on authenticating and validating their clients by whatever means they choose: secret handshakes, certificates, SSH keys, etc. etc. Access filters typically block incoming traffic based on the source address. This was what Michael was (indirectly) referring to. In these cases the filters prevent clients from speaking to the servers so the clients don't get the opportunity to authenticate themselves to those servers. BTW, I've trimmed the address list since everyone named is already on enum at ietf.org. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 23 Jun 2005 09:42:04 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 09:42:04 -0400 To: "Jim Reid" Subject: [Enum] Re: Access controls on URI end points Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF9D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Jim (and Patrik), >Richard, I have read RFC3764. What you've quoted above is different >from what I was talking about. It is of course right and proper for SIP >servers (or whatever) to insist on authenticating and validating their >clients by whatever means they choose: secret handshakes, certificates, >SSH keys, etc. etc. Access filters typically block incoming traffic >based on the source address. This was what Michael was (indirectly) >referring to. In these cases the filters prevent clients from speaking >to the servers so the clients don't get the opportunity to authenticate >themselves to those servers. The problem you are talking about goes much further then ENUM. It is the general problem of the NGN to use IETF protocols and also part of the Internet Infrastructure on one side, but basically do not want to be connected really. So what we have is: - SIP Proxy not allowing you to connect - SIP proxy filtering addresses - Domain names reserved but not resolving (e.g. ims.3gppnetwork.org) - "Public" IP not reachable from the Internet etc. I strongly recommend to read the publicly available GSMA document IR.65 IMS Roaming and Interworking Guidelines, especially section 8, to understand the problem they have: http://uk.sitestat.com/gsm/gsmworld/s?IR65_ims_roaming&ns_type=pdf&ns_url=[http://www.gsmworld.com/documents/ireg/ir65.pdf] first and then the text I posted this week on the TISPAN WG4 mailing list: ------snip----- Dear all, Coming back from Stockholm, I re-read the public GSM-A document IR.65 "IMS Roaming & Interworking Guidelines" and here especially Section 8 "Addressing and Routing" So I would like to get some questions answered from GSMA and also how TISPAN is dealing with these issues? In Section 8.1 "User addressing" is clearly stated: >In addition to private used identity, every IMS user has one or >more public user identities. The public user identity is used in >e.g. user-to-user communication. For example, it might be >included on a business card." If I can include a PUI sip:richard.stastny at sonera.fi on my business card, I expect it to stand there alone and not with a footnote stating: *) to be used only in A1/Vodafone/mobile IMS/TISPAN NGN/etc. I expect it to be usable in PUBLIC like an e-mail address. Q1, This implies that access from the Internet TO IMS is needed, how is this achieved? Q2. How is the public DNS accessed from within an IMS network? This two questions should be added to the issues in WG4TD18. >Public user identities can be used to identify the user's >information within the HSS. Format of public user identity >is either SIP URI (RFC 3261& RFC 2396) or the "tel:"-URI format (RFC 2806), for example sip:clint.eastwood at acme.org or tel: +358405344455." >From the example given and other text one may come to the conclusion that IMS networks may host two types of Public User Identities: A non-portable PUI in the form sip:user at sonera.fi A portable PUI in the form sip:clint.eastwood at acme.org The latter option is very interesting because it requires a hosting of a user provided domain name with the operator This could be achieved by providing SRV records in the users domain pointing to a X-CSCF? On the public Internet. There is only a BIG problem here, not only for acme.org type PUI, but even for sonera.fi type PUI as stated later in Section 8.4 "Interworking Specific Issues": >IMS interworking needs additional support regarding used domains, >since recipient belonging to another operator is addressed with user->friendly public user identity such as mickey.mouse at sonera.fi instead >of mickey.mouse at mnc123.mcc456.3gppnetwork.org. >Originating operator needs to be able to route INVITE SIP request towards >recipient's I-CSCF based on only this sonera.fi domain. Therefore there >has to some method mapping sonera.fi domain and the corresponding I-CSCF >IP address. Logically this method would be DNS, but this is a bit >problematic. A BIT problematic? Is it? Now it comes: >Public DNS likely cannot be used in this, since I-CSCF >IP addresses should not be available in public Internet. GRX DNS can >neither be used, since GRX DNS should not be used to resolve public >domains such as sonera.fi. Again a Catch 22 ;-) So if this even does not work for sonera.fi, how can one expect this to work for acme.org? You cannot use public DNS, and you cannot use GRX either. The proposed ways out of this problem are problematic even for sonera.fi, they are impossible for acme.org: >There are some ways to solve this DNS usage issue; all of these require >the originating operator maintaining some kind of system by itself to >support IMS interworking. Back to de-centralized management of all domain names? >This kind of distributed functionality is needed, since GRX DNS itself >should not handle .com type of domain names. Logically, because this would just shift the problem of maintaining a separate complete DNS system >Main issue is to route all IMS inter-operator related queries to >stay within the operator community (i.e. use only inter-operator DNS >hierarchy), thus Internet DNS should be queried only in the case >of traffic destined to external networks. Ok, that means a split horizon in GRX for all sonera.fi's, and nice to hear that THERE IS a way to query the Internet DNS. The question is only how this is done, because above this is excluded. >Three ways to solve this issue: >* Use operator's internal DNS (or other database) to store >statically configured information mapping domain to I-CSCF IP >address (not recommended due to amount of manual labour needed >in configuring this static information) Good that this is not recommended. >* Better solution would be to use a dynamic query, where each >operator would deploy a "private operator DNS server", that replies >with correct I-CSCF IP address when another "private operator DNS server" >queries it. Addresses of these operator DNS servers itself >would be stored in e.g. IR.21 database >Implementing this does not necessarily require additional equipment, >for example the existing operator DNS server that is needed anyway >due to e.g. GPRS roaming, can be reused for this purpose. Benefit of >using this is reducing the number of static mappings to just one thus >reducing management efforts and also handling of domain names becomes >easier I do not understand this, can anybody please explain. I only have the impression that this does not solve the acme.com problem either >* Third possible solution uses domain name rewriting by adding >"mncXXX.mccYYY.gprs" to the domains that need to be resolved >(e.g. operator.com => operator.com.mnc123.mcc456.gprs), therefore >making these public domains resolvable for the GRX DNS. Rewriting >can be done by the CSCF using internal rewrite lists mapping used >public domain name and the corresponding MNC & MCC. But a better >solution is to utilize NAPTR (Naming Authority Pointer Resource Record of >DNS, RFC 3401-4) domain rewrite rules in the local operator DNS >If DNS solution is used, then CSCF sends a query for DNS concerning >the public domain to be resolved. DNS reply contains the rewritten >domain name, fetched from the domain specific NAPTR field. Supporting >this kind of functionality means that each operator would maintain a >list of its IMS partners in its local DNS >Note: The operator should register the domain used in public user >identity in order to prevent any problems. >Also, it might be beneficial if operators could agree on the used >domain model for IMS public user addressing, e.g. ims.operator.com. >However, various different domains can be handled, as long as everybody is >aware of which domain belongs to which operator. For example, these >domains could be listed in IR.21 database. I also do not understand this proposal in detail, but it also works only for known operator names such as sonera.fi and not for acme.com >Since operator.com type of domains can exist also in public Internet, >care is needed with domain queries in order to avoid mixing these two >separate issues. For example it might be possible for IMS user to connect >also to fixed line SIP clients, therefore this fixed line recipient >(such as elvis.presley at graceland.com) needs to be discovered by utilizing >normal public internet DNS queries. One solution could be to first check >every outgoing domain with internal mapping mechanism and if no I-CSCF is >found, then query this domain from public internet DNS and route it there. Now this is an interesting one, because here at least outbound calls to other "operator domains" such as "sip:elvis.presley at graceland.com" are mentioned, so 1. Again you need to access the public Internet DNS and 2. you also need to interconnect with the public Internet outbound. This raises the minor question how to "call back" into the IMS, This loops back to my first question raise This implies that access from the Internet TO IMS is needed, how is this achieved? Best regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Thu, 23 Jun 2005 09:57:19 -0400 From: Jim Reid Date: Thu, 23 Jun 2005 09:57:19 -0400 To: "Stastny Richard" Subject: [Enum] Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 22, 2005, at 11:50, Stastny Richard wrote: 1) Should (user) ENUM and Infrastructure (Carrier) ENUM implementations be mixed within e.164.arpa? Probably not though it depends on your definitions of "mixed" and "Carrier ENUM" and "User ENUM". 2) If yes, how should this be done technically? Split DNS. Though I can hear Rich Shockey screaming "No!" as I type this... :-) This discussion seems to be doing around in circles and never gets anywhere. It also seems to get hung up about the choice of domain name, which is beside the point quite frankly. The focus should be on requirements and name spaces IMO, not the domain name. Once the requirements are clear, the proper DNS architecture will suggest itself. And after that's clear, then it's time to consider what the domain name should be. Let's try to refocus the discussion. User ENUM is inherently an opt-in process. The user of a number gets the delegation and populates it with whatever they want. Carrier or Infrastructure ENUM is not opt-in as a telco will want to provision that for all the numbers they provide service for. Consent by the users of those numbers will not be required. To all intents and purposes this means Infrastructure ENUM can't be in the public DNS. Carriers wouldn't want that anyway since this could disclose data they'd prefer to keep secret: location of their border gateways, internal network topology, which numbers are in use or have been ported, where and how they interconnect with other carriers, etc, etc. So a telco implementing Infrastructure ENUM wouldn't want to use the public User ENUM infrastructure. Besides, they won't want that for operational reasons. They would not be in control of the public infrastructure: placement and performance of DNS servers, choice of hardware and DNS software, monitoring, (D)DoS protection, choice of TTL values, propagation of updates, support, etc, etc. It's very unlikely any telco would choose to depend on anyone else's infrastructure for their most critical network operations: routing phone calls. This means that a telco will almost certainly operate their own Carrier ENUM infrastructure according to their own operational requirements. Notice I've not yet said anything about the domain name that they'd use for Infrastructure ENUM. Therefore each telco will want to set up and run their own Carrier ENUM infrastructure according to their own rules and populate that with whatever they want. Which is fine. This infrastructure probably shouldn't be visible to the public internet anyway. The question is then which domain name is used. Well, the first thing to agree is that there should be exactly one domain name for Infrastructure/Carrier ENUM. This means that there's a common standard that can be followed by telcos, vendors, developers and solution suppliers. The same domain name will work inside every telco's network. Secondly, it makes it a whole lot easier to merge or split these name spaces whenever telcos merge their operations or divest something. [If say Verizon and BT merge, combining their two private Infrastructure ENUM trees would be far simpler if they both use enum.foo (say) instead of one using something like enum.us and the other using e164.bt.net.] So the telcos need to agree a standard or a convention for the domain name that anchors these name spaces. Now what should be the name of the zone apex that would be at the top of this forest of trees, one tree per telco? IMO this should be e164.arpa. That's the IETF standard for mapping E.164 numbers to domain names after all. So we now have N+1 name spaces for this domain. There's the public one on the internet. And there's a private one operated and controlled by each telco for its own internal purposes. Why choose e164.arpa? Well the chances are that the appications used on the public internet are very likely to be very similar or identical to those used by telcos inside their own networks. On the internet, end users are likely to publish details of which SIP server to use to terminate VoIP traffic for their telephone number. Unless I've missed something, a telco is likely (amongst other things) to use Infrastructure ENUM to figure out which SIP server to use for terminating VoIP traffic for a given telephone number. So it makes sense to be able to use the same software in both places. Though obviously, telcos will prefer "carrier class" software from their approved suppliers rather than an open source SIP server that has no support. The only real difference is that inside the telco's network, resolvers are configured to query internal name servers that know about the internal DNS infrastructure for e164.arpa instead of the public one. Now telcos could probably share a single, private tree for Infrastructure ENUM. This would be a lot cleaner, more efficient and very much cheaper to operate. However I think this is an unrealistic goal. It would be very difficult to get all the telcos to agree a common set of requirements, far less figure out a way to pay for the setup and operation of that shared infrastructure. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Thu, 23 Jun 2005 10:15:30 -0400 From: Marian Durkovic Date: Thu, 23 Jun 2005 10:15:30 -0400 To: Jim Reid Subject: Re: [Enum] Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B203D@oefeg-s04.oefeg.loc> Message-ID: <20050623141447.GA93948@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Thu, Jun 23, 2005 at 02:57:07PM +0100, Jim Reid wrote: > Now what should be the name of the zone apex that would be at the top > of this forest of trees, one tree per telco? IMO this should be > e164.arpa. That's the IETF standard for mapping E.164 numbers to domain > names after all. So we now have N+1 name spaces for this domain. > There's the public one on the internet. And there's a private one > operated and controlled by each telco for its own internal purposes. Jim, if the internal DNS is using the same domain as public DNS, the end result is, that public DNS is invisible. How would a telco route calls to e.g. ENUM-only ranges in different countries, when it has overlayed the public e164.arpa with its private data? Supporting queries into other domains is no problem, require typically one line of configuration. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 23 Jun 2005 10:17:51 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 10:17:51 -0400 To: "Jim Reid" Subject: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF9E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim, you are completely missing the point: First you say >Therefore each telco will want to set up and run their own Carrier ENUM >infrastructure according to their own rules and populate that with >whatever they want. Which is fine. Agreed, they may do this any time, but it does not help to INTERCONNECT as you say: yourself a bit later: >Now telcos could probably share a single, private tree for >Infrastructure ENUM. emphasis on SHARE and you say: >Unless I've missed >something, a telco is likely (amongst other things) to use >Infrastructure ENUM to figure out which SIP server to use for >terminating VoIP traffic for a given telephone number. Not only for telephone numbers: Now we are at the point: How are the SIP URIs resolved:? And how are the PUBLIC User Identities in IMS resolved? How is sonera.fi resolved, not to speak about sip:richard at stastny.com, which I may have according to IR.65 ? Again, please read IR.65 and come up with a workable solution for their problem. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Thu, 23 Jun 2005 10:29:11 -0400 From: "Pfautz, Penn L, NEO" Date: Thu, 23 Jun 2005 10:29:11 -0400 To: "Jim Reid" Subject: [Enum] Carrier ENUM Message-ID: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim: To be clear, the aspect of carrier ENUM that is the focus of the original I-D is carrier ENUM for interconnection between carriers. Whether carriers use infrastructure ENUM internally for routing is (mostly) orthogonal. Since we see interconnection via IP eventually replacing TDM interconnection, we would like ENUM to be able to make pointers that *may* be eventually resolved to the carrier's border function element generally available. Things may start off with just a group of carriers that agree to interconnect but then expand. We believe that split DNS may indeed provide ways for interconnection partners to resolve differently from non-partners or even each other. We understand that queries must resolve even if to NXDOMAIN rather than being dropped on the floor and generating retries. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Jim Reid Sent: Thursday, June 23, 2005 9:57 AM To: Stastny Richard Cc: Subject: [Enum] Name Spaces & Domain Names (was Non-Terrminal NAPTRsConsidered Harmful) On Jun 22, 2005, at 11:50, Stastny Richard wrote: > 1) Should (user) ENUM and Infrastructure (Carrier) ENUM > implementations be mixed within e.164.arpa? Probably not though it depends on your definitions of "mixed" and "Carrier ENUM" and "User ENUM". > 2) If yes, how should this be done technically? Split DNS. Though I can hear Rich Shockey screaming "No!" as I type this... :-) This discussion seems to be doing around in circles and never gets anywhere. It also seems to get hung up about the choice of domain name, which is beside the point quite frankly. The focus should be on requirements and name spaces IMO, not the domain name. Once the requirements are clear, the proper DNS architecture will suggest itself. And after that's clear, then it's time to consider what the domain name should be. Let's try to refocus the discussion. User ENUM is inherently an opt-in process. The user of a number gets the delegation and populates it with whatever they want. Carrier or Infrastructure ENUM is not opt-in as a telco will want to provision that for all the numbers they provide service for. Consent by the users of those numbers will not be required. To all intents and purposes this means Infrastructure ENUM can't be in the public DNS. Carriers wouldn't want that anyway since this could disclose data they'd prefer to keep secret: location of their border gateways, internal network topology, which numbers are in use or have been ported, where and how they interconnect with other carriers, etc, etc. So a telco implementing Infrastructure ENUM wouldn't want to use the public User ENUM infrastructure. Besides, they won't want that for operational reasons. They would not be in control of the public infrastructure: placement and performance of DNS servers, choice of hardware and DNS software, monitoring, (D)DoS protection, choice of TTL values, propagation of updates, support, etc, etc. It's very unlikely any telco would choose to depend on anyone else's infrastructure for their most critical network operations: routing phone calls. This means that a telco will almost certainly operate their own Carrier ENUM infrastructure according to their own operational requirements. Notice I've not yet said anything about the domain name that they'd use for Infrastructure ENUM. Therefore each telco will want to set up and run their own Carrier ENUM infrastructure according to their own rules and populate that with whatever they want. Which is fine. This infrastructure probably shouldn't be visible to the public internet anyway. The question is then which domain name is used. Well, the first thing to agree is that there should be exactly one domain name for Infrastructure/Carrier ENUM. This means that there's a common standard that can be followed by telcos, vendors, developers and solution suppliers. The same domain name will work inside every telco's network. Secondly, it makes it a whole lot easier to merge or split these name spaces whenever telcos merge their operations or divest something. [If say Verizon and BT merge, combining their two private Infrastructure ENUM trees would be far simpler if they both use enum.foo (say) instead of one using something like enum.us and the other using e164.bt.net.] So the telcos need to agree a standard or a convention for the domain name that anchors these name spaces. Now what should be the name of the zone apex that would be at the top of this forest of trees, one tree per telco? IMO this should be e164.arpa. That's the IETF standard for mapping E.164 numbers to domain names after all. So we now have N+1 name spaces for this domain. There's the public one on the internet. And there's a private one operated and controlled by each telco for its own internal purposes. Why choose e164.arpa? Well the chances are that the appications used on the public internet are very likely to be very similar or identical to those used by telcos inside their own networks. On the internet, end users are likely to publish details of which SIP server to use to terminate VoIP traffic for their telephone number. Unless I've missed something, a telco is likely (amongst other things) to use Infrastructure ENUM to figure out which SIP server to use for terminating VoIP traffic for a given telephone number. So it makes sense to be able to use the same software in both places. Though obviously, telcos will prefer "carrier class" software from their approved suppliers rather than an open source SIP server that has no support. The only real difference is that inside the telco's network, resolvers are configured to query internal name servers that know about the internal DNS infrastructure for e164.arpa instead of the public one. Now telcos could probably share a single, private tree for Infrastructure ENUM. This would be a lot cleaner, more efficient and very much cheaper to operate. However I think this is an unrealistic goal. It would be very difficult to get all the telcos to agree a common set of requirements, far less figure out a way to pay for the setup and operation of that shared infrastructure. _______________________________________________ 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 mhammer@cisco.com Thu, 23 Jun 2005 10:43:35 -0400 From: "Michael Hammer \(mhammer\)" Date: Thu, 23 Jun 2005 10:43:35 -0400 To: "Jim Reid" Subject: RE: [Enum] Non-Terrminal NAPTRs Considered Harmful Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3471CC1@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Please keep the reachability and ability to discover an address completely separate. They are absolutely orthogonal issues. There are many reasons (out of radio range, not registered, feature blocking) that someone might not be reachable. I could have a fight with my girlfriend and be "unreachable" today, make up with her and be "reachable" tomorrow. That has nothing to do with whether I can translate an E.164 number to a SIP address, be it direct or some proxy. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Jim Reid > Sent: Thursday, June 23, 2005 5:19 AM > To: Michael Haberler > Cc: enum at ietf.org; Stastny Richard; lconroy; Patrik Faltstrom > (pfaltstr); Richard Shockey > Subject: Re: [Enum] Non-Terrminal NAPTRs Considered Harmful > > On Jun 23, 2005, at 08:01, Michael Haberler wrote: > > "publicly available" doesnt necessarily translate into "openly > > reachable for everybody" > > Indeed. The DNS is just a way to make information publicly available. > It makes no judgements about the content that's stored there. > That said, advertising information in the public DNS about > end-points that are not openly reachable is pointless. > > > or is "openly reachable" a requirement posed on all URI's under > > e164.arpa ? It might be an implicit assumption but I havent > seen such > > a requirement > > No. And I'm not sure this is an implicit assumption either. > Perhaps it should be an explicit assumption. Maybe there > should be an ENUM WG I-D along the lines of Philip Hazel's > draft-ietf-dnsop-dontpublish-unreachable-03.txt which was > about IP addresses that should never appear in the public > DNS. The ENUM version would of course be concerned with > unreachable URIs. Or URI end points that have access control > filters in front of them. Technically, these are generally > reachable: they're just not accessible to everyone. > > > _______________________________________________ > 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 Thu, 23 Jun 2005 12:59:02 -0400 From: Jim Reid Date: Thu, 23 Jun 2005 12:59:02 -0400 To: "Stastny Richard" Subject: Re: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF9E@oefeg-s04.oefeg.loc> Message-ID: <27a84095d2e2ca81b004245c4f24ece6@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 15:21, Stastny Richard wrote: Jim, you are completely missing the point: First you say Therefore each telco will want to set up and run their own Carrier ENUM infrastructure according to their own rules and populate that with whatever they want. Which is fine. Agreed, they may do this any time, but it does not help to INTERCONNECT Yes, it does. There are a number of ways this can be achieved. BT could come to an agreement with Telekom Austria (say) along the lines of "you can get access to my copy of 4.4.e16.arpa if I can get access to your copy of 3.4.e164.arpa". Or Telekom Austria's Infrastructure ENUM could just have entries which say "throw all calls to the UK at the SIP gateways provided by whoever is our UK based telecoms-partner-of-the-month". Now telcos could probably share a single, private tree for Infrastructure ENUM. emphasis on SHARE and you say: Please remember I said that the telcos were very unlikely to share a common infrastructure. Aside from the problems of agreeing the requirements and a way of paying from it, no telco is going to rely on infrastructure outwith its control for the core operational job of routing phone calls. Unless I've missed something, a telco is likely (amongst other things) to use Infrastructure ENUM to figure out which SIP server to use for terminating VoIP traffic for a given telephone number. Not only for telephone numbers: Now we are at the point: How are the SIP URIs resolved:? In the same way as anything is resolved. You just look it up in the DNS! If my internal DNS setup has a private instance of e164.arpa which I use for my own purposes, that does not prevent my name servers seeing and resolving anything under the public root on the internet. Apart from stuff under e164.arpa of course: instead of the public ENUM name space (the User ENUM tree), my world sees my private, internal copy. But that's OK because that's what I want everything in my world to see for that part of the name space. FYI, I'm doing something like that right now and it works perfectly. My wireless net at home uses RFC1918 addressing, 10.0.1/24. Reverse lookups of these addresses can't work on the internet as the range has been set aside for private use. So my name servers have their own private version of 10.in-addr.arpa containing PTR records for the stuff on my wireless net. Local clients get these names back from the DNS when they do reverse lookups. If they tried resolving them on the internet, they'd get an NXDOMAIN response from the AS112 name servers which serve up the public version of the 10.in-addr.arpa zone. And how are the PUBLIC User Identities in IMS resolved? If those names don't live under e164.arpa, see above. How is sonera.fi resolved, not to speak about sip:richard at stastny.com, which I may have according to IR.65 ? I refer you to my previous answer. ;-) Again, please read IR.65 and come up with a workable solution for their problem. I will read this document later today. However given some of the "interesting" DNS architectures the GSM has come up with in the past -- .gprs anyone? -- it may be hard to find solutions for them. I think there's still a very big disconnect between bell-heads and net-heads. Few of the former seem to know how the DNS works (or can be made to work). Few of the latter understand SS7 signalling or how calls get routed in the telco world. Sigh. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Thu, 23 Jun 2005 13:15:41 -0400 From: Michael Haberler Date: Thu, 23 Jun 2005 13:15:41 -0400 To: Jim Reid Subject: Re: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF9E@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050623190500.049808c0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: RO At 18:58 23.06.2005, you wrote: Agreed, they may do this any time, but it does not help to INTERCONNECT Yes, it does. There are a number of ways this can be achieved. BT could come to an agreement with Telekom Austria (say) along the lines of "you can get access to my copy of 4.4.e16.arpa if I can get access to your copy of 3.4.e164.arpa". Or Telekom Austria's Infrastructure ENUM could just have entries which say "throw all calls to the UK at the SIP gateways provided by whoever is our UK based telecoms-partner-of-the-month". IMO the value add of an unvisible identifier visavis a visible, but unreachble identifier is moderate to nonexistent, especially if the associated downside is private tree bartering. Management cost is an issue and I cant see revenues going up in telco space. Plus, in business terms split DNS is a good way to kill user ENUM long term. When you get critical mass in a tree, however that mass gets used, cost per entry goes down and operation becomes sustainable. Tom Kershaw's right in a sense - whoever gets 30 million entries wins the game - not necessarily as a company but as an approach. I'd add - if that is the barrier I wouldnt bother too much how the entries are used - carrier or user. Plus, there will be no "migration" from tree swapping to user ENUM if that eventually takes off. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 23 Jun 2005 13:33:18 -0400 From: "Stastny Richard" Date: Thu, 23 Jun 2005 13:33:18 -0400 To: "Jim Reid" Subject: Re: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFA0@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim. To start with the point I agree ;-= >I think there's still a very big disconnect between bell-heads and >net-heads. Few of the former seem to know how the DNS works (or can be >made to work). Few of the latter understand SS7 signalling or how calls >get routed in the telco world. Sigh. >Yes, it does. There are a number of ways this can be achieved. BT could >come to an agreement with Telekom Austria (say) along the lines of "you >can get access to my copy of 4.4.e16.arpa if I can get access to your >copy of 3.4.e164.arpa". Or Telekom Austria's Infrastructure ENUM could >just have entries which say "throw all calls to the UK at the SIP >gateways provided by whoever is our UK based >telecoms-partner-of-the-month". Either you are now also a bellhead or wnat to pull the leg of the bellheads. What you are proposing is that the telcos continue their model just to be sure they are dead sooner. Imagine only all VoIP providers in the world to make bilateral agreements. Why are you not proposing that every ISP in the world is making bilateral agreements with any other ISP just to see the web-sites he is hosting. You may see only websites your provider is hosting or are hosted by providers your provider has an agreement with. I cannot propose this model to my or any other VoIP provider because the OPEX will kill them. The benefit of ENUM is that every provider is maintaining his own data and if you want to know who is hosting a number, you just look it up in ENUM. Done. Everything else is baroque unnecessary complications just draining OPEX money out. BTW, I just read the new proposed US regulatory framework http://www.pff.org/issues-pubs/other/050617regframework.pdf and the only things what basically remain is singnificant market power and the obligation to INTERCONNECT ;-) "For purposes of this act, unfair methods of competition means: (a) practices that present a threat of abuse of significant and non-transitory market power as determined by the Commission consistent with the application of jurisprudential principles grounded in market-oriented competition analysis such as those commonly employed by the Federal Trade Commission and the United States Department of Justice in enforcing the Federal Trade Commission Act and the antitrust laws of the United States; and (b) with respect to interconnection, practices that pose a substantial and non-transitory risk to consumer welfare by materially and substantially impeding the interconnection of public communications facilities and services in circumstances in which the Commission determines that marketplace competition is not sufficient adequately to protect consumer welfare, providing that in making any such determination the Commission must consider whether requiring interconnection will affect adversely investment in facilities and innovation in services. " Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 23 Jun 2005 18:32:40 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 23 Jun 2005 18:32:40 -0400 To: Stastny Richard Subject: Re: [Enum] Re: Access controls on URI end points In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF9D@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 06:44, Stastny Richard wrote: - Domain names reserved but not resolving (e.g. ims.3gppnetwork.org) I have no problems with domain names not resolving, but I have problems when the PUBLIC tree for ENUM, e164.arpa, include delegations by NS or non-terminal NAPTR point to records that do not resolve. I.e. the only ones that should resolve such names are the ones that can resolve them. Timeouts in DNS is a bad thing. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 23 Jun 2005 18:35:19 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 23 Jun 2005 18:35:19 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 07:28, Pfautz, Penn L, NEO wrote: To be clear, the aspect of carrier ENUM that is the focus of the original I-D is carrier ENUM for interconnection between carriers. As I have suggested to you a few times, if "carrier ENUM" is only to be used by a known group of organizations and noone else, there is absolutely no reason what so ever to have the DNS names in e164.arpa. The only reason to have records there is if carriers want to put data in DNS that anyone should be able to access. If the argument for carrier ENUM is to only let some people be able to do the lookup, it should be done in a different corner of the DNS hierarchy, and what corner that is can be part of the contractual agreement between the carriers when they set up their "traffic exchange agreement". paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Thu, 23 Jun 2005 19:13:16 -0400 From: "Pfautz, Penn L, NEO" Date: Thu, 23 Jun 2005 19:13:16 -0400 To: Patrik Fältström Subject: RE: [Enum] Carrier ENUM Message-ID: <34DA635B184A644DA4588E260EC0A25A0A82A276@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO I agree. I don't see interconnection as *necessarily* meaning private though some Parties may choose to implement so. I hope not. Penn -----Original Message----- From: Patrik Fältström [mailto:paf at cisco.com] Sent: Thursday, June 23, 2005 6:35 PM To: Pfautz, Penn L, NEO Cc: Jim Reid; Stastny Richard; enum at ietf.org Subject: Re: [Enum] Carrier ENUM On Jun 23, 2005, at 07:28, Pfautz, Penn L, NEO wrote: > To be clear, the aspect of carrier ENUM that is the focus of the > original I-D is carrier ENUM for interconnection > between carriers. As I have suggested to you a few times, if "carrier ENUM" is only to be used by a known group of organizations and noone else, there is absolutely no reason what so ever to have the DNS names in e164.arpa. The only reason to have records there is if carriers want to put data in DNS that anyone should be able to access. If the argument for carrier ENUM is to only let some people be able to do the lookup, it should be done in a different corner of the DNS hierarchy, and what corner that is can be part of the contractual agreement between the carriers when they set up their "traffic exchange agreement". paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Fri, 24 Jun 2005 02:48:19 -0400 From: "Clive D.W. Feather" Date: Fri, 24 Jun 2005 02:48:19 -0400 To: Patrik Fältström Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: <20050624064711.GA13484@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: RO Patrik Fältström said: > As I have suggested to you a few times, if "carrier ENUM" is only to > be used by a known group of organizations and noone else, there is > absolutely no reason what so ever to have the DNS names in e164.arpa. > The only reason to have records there is if carriers want to put data > in DNS that anyone should be able to access. > > If the argument for carrier ENUM is to only let some people be able > to do the lookup, it should be done in a different corner of the DNS > hierarchy, and what corner that is can be part of the contractual > agreement between the carriers when they set up their "traffic > exchange agreement". However, you don't want to use 57 different domain names if you have 57 different partners you exchange traffic with. There should be a single domain that can be configured into all carrier ENUM systems. Whether this is carrier.e164.arpa, or carrier-enum.info, or what, I don't care. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 24 Jun 2005 04:02:03 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 24 Jun 2005 04:02:03 -0400 To: "Clive D.W. Feather" Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: <25367D9B-C85F-476F-BCBC-83E17719F528@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 23:47, Clive D.W. Feather wrote: However, you don't want to use 57 different domain names if you have 57 different partners you exchange traffic with. There should be a single domain that can be configured into all carrier ENUM systems. Whether this is carrier.e164.arpa, or carrier- enum.info, or what, I don't care. You will need one carrier enum domain for each "club" of carriers. I have already heard one carrier wanting to publish their "ENUM data" in such a way that two peers see different information. Just because they wanted different ingress points for SIP calls to their "sip server clouds". So, believing you will get only one root domain for "hidden" domains for carriers I see has already lost the battle in the form of private agreements. What we discuss here on this list is the situation when someone else than the owner/holder of the E.164 want to make ENUM data publicly available for everyone to use. At least from my point of view, and I have not been convinced I am wrong -- yet... :-) paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From salmon@sipgate.de Fri, 24 Jun 2005 04:04:50 -0400 From: Thilo Salmon Date: Fri, 24 Jun 2005 04:04:50 -0400 To: Stastny Richard Subject: Re: [Enum] Re: Name Spaces & Domain Names (was Non-Terrminal NAPTRs Considered Harmful) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFA0@oefeg-s04.oefeg.loc> Message-ID: <1119600408.21495.52.camel@gw12> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard, > Why are you not proposing that every ISP in the world is making > bilateral agreements with any other ISP just to see the web-sites he > is hosting. You may see only websites your provider is hosting or are > hosted by providers your provider has an agreement with. Two reasons actually: 1.) websites facilitate media distribution rather than end2end communication services 2.) websites have not been accessible through a parallel infrastructure based on a different economic model ad 1.) limiting access to public web sites does not usually make sense - for neither the content provider nor the end user. End2end communication services are quite different animals. Comparing voip with email seems more fair to me. In this case an infrastracture openly accessible by anyone has almost rendered email to be useless due to the high amount of unauthorized traffic. While I do not wish to suggest a border gateways will prevent 100% of voip spam, I believe any additional layer of control would bring a benefit. ad 2.) Hardly any carrier has the reputation of being overly cuddly leave alone altruistic. I am suprised what you expect from those in the POTS market today. In almost all cases do carriers earn access charges for incoming calls. What would be your proposition to carriers to waives them for the general public? Would it not come naturally to assume, that _if_ there were waived, they would be waived mutually? Best, Thilo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 24 Jun 2005 04:14:29 -0400 From: Jim Reid Date: Fri, 24 Jun 2005 04:14:29 -0400 To: Patrik Fältström Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: <0af5c0f22a4fd8aa84d4adf3cab87e0f@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 23, 2005, at 23:34, Patrik Fältström wrote: As I have suggested to you a few times, if "carrier ENUM" is only to be used by a known group of organizations and noone else, there is absolutely no reason what so ever to have the DNS names in e164.arpa. The only reason to have records there is if carriers want to put data in DNS that anyone should be able to access. Just to make things crystal-clear Patrik, you're saying there's no justification for putting *private* data in the *public* e164.arpa tree. Right? An organisation or groups of organisations are free to put their own private data in their own private instance of an e164.arpa zone. And if they do that, they don't need to get permission from anyone. In other words, what someone does in private behind closed doors is nobody else's business. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 24 Jun 2005 04:27:23 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 24 Jun 2005 04:27:23 -0400 To: Jim Reid Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: <7B0498EB-C75C-47C2-A2F4-E3B39BC9D15A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 24, 2005, at 01:12, Jim Reid wrote: Just to make things crystal-clear Patrik, you're saying there's no justification for putting *private* data in the *public* e164.arpa tree. Right? An organisation or groups of organisations are free to put their own private data in their own private instance of an e164.arpa zone. And if they do that, they don't need to get permission from anyone. In other words, what someone does in private behind closed doors is nobody else's business. Correct, *I* can not see any justification. It is the contrary, I can see problems with having data in the public area if some of the DNS servers are not reachable. Sure, split DNS can take care of some of this, but I MUCH rather see split dns for e164.foo. than 3.4.5.1.2.e164.arpa. Simply because I am nervous for leakage. If people want to play around with such things, do it somewhere else (unless someone really see some reason why it must be in the (public) e164.arpa tree. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 24 Jun 2005 04:30:49 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 24 Jun 2005 04:30:49 -0400 To: Jim Reid Subject: Re: [Enum] Carrier ENUM In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A7F4D90@ACCLUST02EVS1.ugd.att.com> Message-ID: <740B5D90-F53C-4C1F-889F-DB3E8351F8AE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 24, 2005, at 01:12, Jim Reid wrote: An organisation or groups of organisations are free to put their own private data in their own private instance of an e164.arpa zone. And if they do that, they don't need to get permission from anyone. In other words, what someone does in private behind closed doors is nobody else's business. Let me explain in a different way: - If A want to make information available to B, and only B, A and B probably have a contract that stipulates how that data can be used etc. That contract/agreement can also include information what root in the DNS hierarchy the data is in (together with access/ authorization information etc). - If A and B do not have any agreement, which is the case when B is anyone in the world, they have to fall back to the ENUM RFC that tell e164.arpa is to be used. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From salmon@sipgate.de Fri, 24 Jun 2005 05:49:29 -0400 From: Thilo Salmon Date: Fri, 24 Jun 2005 05:49:29 -0400 To: enum at ietf.org Subject: [Enum] Multiple service providers routing to single E.164? Message-ID: <1119606710.21495.80.camel@gw12> MIME-Version: 1.0 Content-Type: text/plain Status: RO Penn, Steve, can I ask you to clarify this part for me? "The E2U+carrier record, on the other hand, is controlled by the GSTN carrier of record for the E.164 number (i.e., the service provider who has been allocated the block of numbers in which the number in question is contained or to which the number has been ported)." Apart from the difficulties for c.c.e164.arpa administratiors to verify the PSTN routing of ported numbers in some countries, I sense another problem: Unlike in the PSTN world in which each number is terminated by a single service provider this may not be the case in the voip world. The absence of naked DSL (i.e. DSL on land lines without PSTN service) hinders number portability as a number cannot possibly ported from a land line without the end user loosing his or her DSL service. As a workaround numerous service providers have started to validate their end users' phone numbers and route them. This development has been boosted by CPEs which integrate FXO/FXS and SIP into a single box. Today it is not uncommon for an end user to receive incoming routing on his or her land line numbers through multiple service providers without any public records of the established routing whatsoever (btw, that fact is driving law enforcement officers nuts). In Germany alone I would expect about one percent of all numbers to be listed in alternative routing tables. Where in this a shared user and carrier enum tree would you accomodate those service providers and what would be the proposition for them? All the best, Thilo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 24 Jun 2005 06:16:13 -0400 From: "Stastny Richard" Date: Fri, 24 Jun 2005 06:16:13 -0400 To: "Thilo Salmon" Subject: RE: [Enum] Re: Name Spaces & Domain Names Message-ID: <32755D354E6B65498C3BD9FD496C7D461B204C@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Thilo, I did not use the e-mail example because I expected that someone will immediately sent me an e-mail stating that the e-mail system is broken ;-) SIP is modelled after e-mail and this is exactly how it should work. The problems currently with e-mail is a more broader problem on the Internet and has to be solved in general. We should not stop SIP as intended because identification and authentication on the Internet is broken. BTW: web started as broadcast, but no it is also basically P2P. Anybody providing customer services at the Internet via web-access should know this ;-) What we see at the moment is: We have two systems running in parallel at the moment: There will be a competition (at the end-users device) giving him the choice 1) to use any service on the Internet or 2) to use a walled garden NGN type service ala IMS, YahooBB or Skype (Skype is something special here in between). The walled garden approach is favoured by the "bellheads" to keep their current revenue streams up and running, which requires charging for voice calls for origination, transit and termination. This requires interconnect agreements and is causing all this mess. If a user is accessing the Internet NOT at home, he has bring his own equipment (device) and to pay for access to the local access provider. The user he is calling has to do the same. This holds true for both models, which means that in the second case the user has to pay extra. Why should he want to do this? The only argument left is more security (ha, on a Wifi hotspot at Starbucks) and "improved" or "guarantied" QoS (again from the same Starbucks Hotspot, or even worse via a mobile access in the US). ROTFL - this means that in one case you are tunnelling from New York back to Germany to your IMS homenetwork, they are setting up the call via your super peering agreements to the Austrian IMS homenetwork and this is tunnelled now to a Hotspot in Japan. I bet 100 Euro the quality with Skype direct will be better. So with the already available multi-mode (3G, WiFI) devices there will be a competition between using the Internet direct or using the IMS service provided @home. Since the quality will be the same, the services provided will also be the same (remark: the services provided on the Internet may even be better or at least available sooner ;-), I also believe that the security (good or Bad) will be the same, the only difference will be the price. So the carrier should do anything possible to reduce their OPEX, which implies a very efficient interconnect regime. Please remember the word from Clay Shirky regarding fax-mail: You may compete with everybody, but NOT with your customer. Additional remark regarding termination fees: pls look up the Proposal http://www2.sprint.com/mr/cmastaticfiles/non-landing/documents/PPTopic/8 -13-04sd.pdf from the intercarrier Compensation Forum http://www2.sprint.com/mr/topic.do?topicId=180 The proposal goes from 0.000175/minute down to zero in 2001. Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > > > Why are you not proposing that every ISP in the world is making > > bilateral agreements with any other ISP just to see the web-sites he > > is hosting. You may see only websites your provider is hosting or are > > hosted by providers your provider has an agreement with. > > Two reasons actually: > > 1.) websites facilitate media distribution rather than end2end > communication services > 2.) websites have not been accessible through a parallel infrastructure > based on a different economic model > > ad 1.) limiting access to public web sites does not usually make sense - > for neither the content provider nor the end user. End2end communication > services are quite different animals. Comparing voip with email seems > more fair to me. In this case an infrastracture openly accessible by > anyone has almost rendered email to be useless due to the high amount of > unauthorized traffic. While I do not wish to suggest a border gateways > will prevent 100% of voip spam, I believe any additional layer of > control would bring a benefit. > > ad 2.) Hardly any carrier has the reputation of being overly cuddly > leave alone altruistic. I am suprised what you expect from those in the > POTS market today. In almost all cases do carriers earn access charges > for incoming calls. What would be your proposition to carriers to waives > them for the general public? Would it not come naturally to assume, that > _if_ there were waived, they would be waived mutually? > > Best, > Thilo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Fri, 24 Jun 2005 08:33:16 -0400 From: "Pfautz, Penn L, NEO" Date: Fri, 24 Jun 2005 08:33:16 -0400 To: "Thilo Salmon" Subject: [Enum] RE: Multiple service providers routing to single E.164? Message-ID: <34DA635B184A644DA4588E260EC0A25A0A82A398@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Thilo: In most, though not all, countries a number in the GSTN is associated with a particular carrier and A particular default point of interconnection for the non-VoIP world. Thus, the "carrier of record." This is simple to identify if you do NP via all-call-query (and let me just say that IS the RIGHT way :-), doubters see RFC 4041). Doesn't mean that others couldn't deliver calls to the customer in the evolving IP world and we see carrier/user ENUM as way to bridge the two perspectives. You can't have interconnection if you have to have opt-in but you want to allow for end user choice to have alternate paths as well. Where does that leave the third party? Probably in the user tree. Users can agree with multiple service providers To put NAPTR record each allowing termination through a different SP in their Tier 2. Penn -----Original Message----- From: Thilo Salmon [mailto:salmon at sipgate.de] Sent: Friday, June 24, 2005 5:52 AM To: enum at ietf.org Cc: Lind, Steven D, ALABS; Pfautz, Penn L, NEO Subject: Multiple service providers routing to single E.164? Penn, Steve, can I ask you to clarify this part for me? "The E2U+carrier record, on the other hand, is controlled by the GSTN carrier of record for the E.164 number (i.e., the service provider who has been allocated the block of numbers in which the number in question is contained or to which the number has been ported)." Apart from the difficulties for c.c.e164.arpa administratiors to verify the PSTN routing of ported numbers in some countries, I sense another problem: Unlike in the PSTN world in which each number is terminated by a single service provider this may not be the case in the voip world. The absence of naked DSL (i.e. DSL on land lines without PSTN service) hinders number portability as a number cannot possibly ported from a land line without the end user loosing his or her DSL service. As a workaround numerous service providers have started to validate their end users' phone numbers and route them. This development has been boosted by CPEs which integrate FXO/FXS and SIP into a single box. Today it is not uncommon for an end user to receive incoming routing on his or her land line numbers through multiple service providers without any public records of the established routing whatsoever (btw, that fact is driving law enforcement officers nuts). In Germany alone I would expect about one percent of all numbers to be listed in alternative routing tables. Where in this a shared user and carrier enum tree would you accomodate those service providers and what would be the proposition for them? All the best, Thilo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 24 Jun 2005 11:08:31 -0400 From: "Peter Williams" Date: Fri, 24 Jun 2005 11:08:31 -0400 To: Subject: RE: [Enum] Carrier ENUM In-Reply-To: <740B5D90-F53C-4C1F-889F-DB3E8351F8AE@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Jim Reid technology liberalism, vs Cisco telco business planning! Let's reflect on operations reality, as practiced in the US telco market! Two providers of private management domain of name servers can always share a private copy of the e.164.arpa service, served with cached and/or augmented information sets. Cached copies of "high-quality-serviced" public information will quite normally be augmented with additional information objects only relevant to the user of the interconnect - another cooperating provider. Such cache slaves may be only a 1ms out of date, in practice, so this is all "Cache" semantics, really. What really matters is the augmented data, and its accuracy. In the X.500 equivalent of these name resolver processes in commercial communities, the cached slave entries of an AD would be augmented with acls limiting which ADs and PMDs could replicate or chain operations to particular portions of that particular slave copy of the public name space. Normal practice had subordinate objects stored in the publicly named entry of the slave DIB, which was only available to interconnecting parties, and was provisioned by the maintainer for private consumption in the interconnected provider group. These datasets commonly contained registration info, security (certificates from the interconnect parties CAs, for security policy enforcement and value add secure messaging service delivery within the interconnect community) and billing/token counting information shared as part of the commercial practices of the interconnect. 12 years ago, Einar and Marshall created quite a reputable set of operating practices for sharing a public naming tree (see NADF RFCs), suited to the way interconnects amongst those issuing PRIVATE security credentials and billing rights benefiting PUBLIC end users usually work. It was tuned to unique way interconnect business works in the US telco services and management services market. An alternative to look at is the European SIM/SAM model for orchestrating security interconnects in the roaming-centric cellular space, which add the offline dimension of management, control and security key provisioning to the domain interconnects. > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Patrik Fältström > Sent: Friday, June 24, 2005 1:30 AM > To: Jim Reid > Cc: enum at ietf.org; Stastny Richard; Pfautz, Penn L,NEO > Subject: Re: [Enum] Carrier ENUM > > On Jun 24, 2005, at 01:12, Jim Reid wrote: > > > An organisation or groups of organisations are free to put their > > own private data in their own private instance of an e164.arpa > > zone. And if they do that, they don't need to get permission from > > anyone. In other words, what someone does in private behind closed > > doors is nobody else's business. > > Let me explain in a different way: > > - If A want to make information available to B, and only B, A and B > probably have a contract that stipulates how that data can be used > etc. That contract/agreement can also include information what root > in the DNS hierarchy the data is in (together with access/ > authorization information etc). > > - If A and B do not have any agreement, which is the case when B is > anyone in the world, they have to fall back to the ENUM RFC that tell > e164.arpa is to be used. > > 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 paf@cisco.com Fri, 24 Jun 2005 12:25:22 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 24 Jun 2005 12:25:22 -0400 To: Peter Williams Subject: Re: [Enum] Carrier ENUM In-Reply-To: Message-ID: <71C9629D-EA20-4AB4-849F-E3A2B272EA96@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 24, 2005, at 08:08, Peter Williams wrote: Two providers of private management domain of name servers can always share a private copy of the e.164.arpa service, served with cached and/or augmented information sets. Absolutely, but if they have a private copy that both know about (a) they really don't have to have it in e164.arpa, but they can have it somewhere else (b) there is no argument why it have to be in e164.arpa and (this is important) (c) setting up split DNS so that 100% of the lookups are actually responded correctly with absolutely no leakage of the responses is extremely difficult. DNS is designed to be koherent, that all queries get responded with the same data, and because of this DNS protocol / caches etc by design is hard to run within a walled garden. For telephony call routing, it is enough with one wrongly routed call, and you as a carrier have problems. Because of this, and the fact I don't see any need for the "walled garden ENUM tree" have to be rooted in e164.arpa I don't think it should be there. If you don't agree with me (and to be honest, I don't know whether you do or not), please explain why it has to be in e164.arpa. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@NLnetLabs.nl Fri, 24 Jun 2005 13:08:36 -0400 From: Jaap Akkerhuis Date: Fri, 24 Jun 2005 13:08:36 -0400 To: Thilo Salmon Subject: Re: [Enum] Multiple service providers routing to single E.164? In-Reply-To: <1119606710.21495.80.camel@gw12> Message-ID: <200506241708.j5OH844V023175@bartok.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain Status: RO Apart from the difficulties for c.c.e164.arpa administratiors to verify the PSTN routing of ported numbers in some countries, I sense another problem: Unlike in the PSTN world in which each number is terminated by a single service provider this may not be the case in the voip world. The absence of naked DSL (i.e. DSL on land lines without PSTN service) hinders number portability as a number cannot possibly ported from a land line without the end user loosing his or her DSL service. For your information: In the Netherlands one can get xDSL service without PSTN. Basically, one only pays for the use of the old trusted copper wire to whoever maintains it (most likely the old phone company). You can then pick your xxDSL service supplier yourself. There are also companie(s) which give you VOIP independent from where you buy your IP services. And they are happy to over port the PSTN number as wel for a fee. jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 24 Jun 2005 13:47:23 -0400 From: "Stastny Richard" Date: Fri, 24 Jun 2005 13:47:23 -0400 To: Subject: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFAB@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Dear all, The discussion regarding User vs Carrier ENUM and where to place is circling around the central point of the problem, which is the future usability and purpose of a sip: URI SIP was originally modelled along the lines of the e-mail archtecture and in every presentation frem Henry and Alan at the VON SIP Tutorial you see the famous SIP trapeziod: A user is sending an invite to a proxy, containing and Address-of-Record, (AoR)in the form of a SIP URI sip:user at domain.foo the proxy is querying the DNS the domain for SRV-records (=MX) forwarding the invite to the proxy serving the domain.foo. The proxy has either the "user" registered" already and know where in the world the user is atteched to the Internet, or the proxy knows what to do with the call, e.g. connects to a voce-box. Done. No need for E.164 numbers. User ENUM now started with the basic idea that if a user has such a SIP URI, and he has also an E.164 number, he may hint that somebody trying to establish a call in the Internet and knowing only the E.164 number that he has also a SIP URI to be reached also there. User ENUM without SIP URIs is useless Now lets look at Carriers. Originally the carriers had only E.164 numbers and where only on the PSTN. Carrier ENUM could have been useful there as IN-SCP replacement for NP, holding tel: records with routing numbers Nice idea, but nobody was interested. Then the carrier moved on also to VoIP. After some experiements, e.g with H.323 they finally settled on using SIP (the same arguments are BTW also valid for H323). For using sip you basically need a sip URI as AoR. The best example is the 3GPP IMS model. 3GPP is using two types of SIP URIs: the private User Identity, basically derived by some algorith from the IMSI and used with registration to find the home network and the Public User Identity. The Public User Identity is a SIP URI which should be known also by the User, because it is basically the means to establish a call: e.g. sip:frank at vodafone.de, or even sip:richard at stastny.com. Now the queston comes up, how public is public. Naive netheads would assome you just put an SRV record in vodafone.de to point to the whatever-CSCF Not so, this is bad for a number of reasons I do not want elaborate further here, but there may some 3GPP and TISPAN experts out there willing to explain. So if even this is bad, you are not giving anything about which user belongs to you and how many away with this, only eventually the IP address of you SBC. But since they do not want to be reached from the Internet anyway,because they do not get termination charges, this is a minor problem (how public is public?) Now we come to the real problem: every sip:frank at vodafone.de has also a E.164 number attached to him, for compatibility with the PSTN and also users on 3G may want to continue to use E.164 for various reasons also stated many times by Rich Shockey. Since they want to interconnect via IP and not via the PSTN (really), they need a mapping from E.164 numbers to the Public User IDs (SIP URIs) to route the calls properly. You do not need the mapping of you own E.164 number, this is done at the SIP proxy, you need the mapping of all other numbers. This is done best with all call query via a global NP database, giving you the E.164 to provider mapping. If you get as an additioanl bonus the routing information (the IP address of the proxy, One possible solution for this problem is a Carrier ENUM tree. Done..Fine One would think. The problem is: they do not want their compet... partners 1. to know how many users they have 2. who these users are - the partner may just make call and alienate him So even putting the ENUM tree in an extranet only accessible by partners does not help to solve this problem, because the partners are not really partners. And in addition there are still "partners" and others, so you cannot peer with them; they have their own tree, this creating the ENUM forest. Even if all decide to use the same global tree, and regardless if this tree is public (e164.arpa or carrier.e164.arpa) or somewhere else e164.info, it does not solve the basic problem, because this is a Catch 22. Ideas to have a ENUM tree where my entries can only be seen by some others I decide to do so, is the perverting the whole idea, and proves the fact that these operators do care about everything, but not about their costomers. Can you imagine an announcement on the PSTN like this: "the user you are calling is hosted with a provider we have no interconnect agreement with, so we are sorry that we cannot complete your call. Tell your friend to move over to a provider we have an agreement with, but be aware, we may change our interconnect agreements at any time without prior notice, so tell you friend to move quickly, because in one month this may have changed already." So either the carriers get their whatever together and introduce an ACQ in public space (because of the Public User Identities) or they forget the whole issue. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 24 Jun 2005 16:17:16 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 24 Jun 2005 16:17:16 -0400 To: "Stastny Richard" Subject: RE: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <072C5B76F7CEAB488172C6F64B30B5E347205C@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard, What a complicated Gordean Knot we weave! I disagree with your central premise. The issue is not the use or purpose of a sip: URI; it is whether ENUM can act as a global routing mechanism if it's fundamental property "universal access" (or openness) is undermined by walled ENUM gardens. (Funny, I don't hear anyone talking much about "Carrier DNS".) Any user (including those still on TDM) MUST be able to call any other connected user. Metcalf's Law and the value of the VoIP network is at stake. Because the PSTN is part of the equation, all users MUST have E.164 numbers for the previous statement to work. Notice that I did not try to categorize users as being on the Internet or within some walled garden of a service provider. The routing mechanism of VoIP is based (or soon will be) on sip:URI and the ability (using DNS) to translate that into an IP address for routing over ANY IP-based network. But, the assumption is that any user MUST have the ability to translate ANY assigned E.164 number into a sip:URI. That would imply that the resource record for any E.164 number must be reachable universally. That does not mean that all information associated with a user is available, just the basic mapping from E.164 to sip:URI to further route a call. Additional pointers can send one to a private server that can play guard to the exclusive club. The sip: or other URI can lead to a walled garden policeman server (personal, enterprise, or carrier) that only lets "approved guests" through, but that is secondary. As the first part of your message indicates, if a VoIP user does not want to be reached universally, then they don't really need an E.164 number, just a sip:URI, and can stop wasting a public numbering resource. Sooner or later the national regulators will realize that ENUM is broken unless the fundamental E.164-to-URI translation exists publicly for all E.164 numbers. (Just wait until E911 calls/call-backs fail.) The legacy number portability (and in US LERG) database operators will be only too happy to extend their TDM routing mechanisms into the IP space to fill a broken-on-arrival ENUM system. Note that numbers can be ported using ENUM, you just don't need all the legacy NP mechanisms and process to do that. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Friday, June 24, 2005 1:50 PM > To: enum at ietf.org > Subject: [Enum] Carreir ENUM, SIP URIs and DNS > > Dear all, > > The discussion regarding User vs Carrier ENUM and where to > place is circling around the central point of the problem, > which is the future usability and purpose of a sip: URI > > SIP was originally modelled along the lines of the e-mail > archtecture and in every presentation frem Henry and Alan at > the VON SIP Tutorial you see the famous SIP trapeziod: > > A user is sending an invite to a proxy, containing and > Address-of-Record, (AoR)in the form of a SIP URI > sip:user at domain.foo the proxy is querying the DNS the domain > for SRV-records (=MX) forwarding the invite to the proxy > serving the domain.foo. > The proxy has either the "user" registered" already and know > where in the world the user is atteched to the Internet, or > the proxy knows what to do with the call, e.g. connects to a voce-box. > > Done. > > No need for E.164 numbers. > > User ENUM now started with the basic idea that if a user has > such a SIP URI, and he has also an E.164 number, he may hint > that somebody trying to establish a call in the Internet and > knowing only the E.164 number that he has also a SIP URI to > be reached also there. > > User ENUM without SIP URIs is useless > > Now lets look at Carriers. Originally the carriers had only > E.164 numbers and where only on the PSTN. Carrier ENUM could > have been useful there as IN-SCP replacement for NP, holding > tel: records with routing numbers Nice idea, but nobody was > interested. > > Then the carrier moved on also to VoIP. After some > experiements, e.g with > H.323 they finally settled on using SIP (the same arguments > are BTW also valid for H323). For using sip you basically > need a sip URI as AoR. The best example is the 3GPP IMS > model. 3GPP is using two types of SIP > URIs: the private User Identity, basically derived by some > algorith from the IMSI and used with registration to find the > home network and the Public User Identity. The Public User > Identity is a SIP URI which should be known also by the User, > because it is basically the means to establish a call: > e.g. sip:frank at vodafone.de, or even sip:richard at stastny.com. > > Now the queston comes up, how public is public. Naive > netheads would assome you just put an SRV record in > vodafone.de to point to the whatever-CSCF Not so, this is bad > for a number of reasons I do not want elaborate further here, > but there may some 3GPP and TISPAN experts out there willing > to explain. > > So if even this is bad, you are not giving anything about > which user belongs to you and how many away with this, only > eventually the IP address of you SBC. > But since they do not want to be reached from the Internet > anyway,because they do not get termination charges, this is a > minor problem (how public is public?) > > Now we come to the real problem: every sip:frank at vodafone.de > has also a E.164 number attached to him, for compatibility > with the PSTN and also users on 3G may want to continue to > use E.164 for various reasons also stated many times by Rich Shockey. > > Since they want to interconnect via IP and not via the PSTN > (really), they need a mapping from E.164 numbers to the > Public User IDs (SIP URIs) to route the calls properly. You > do not need the mapping of you own E.164 number, this is done > at the SIP proxy, you need the mapping of all other numbers. > This is done best with all call query via a global NP > database, giving you the E.164 to provider mapping. If you > get as an additioanl bonus the routing information (the IP > address of the proxy, One possible solution for this problem > is a Carrier ENUM tree. Done..Fine > > One would think. > > The problem is: they do not want their compet... partners 1. > to know how many users they have 2. who these users are - the > partner may just make call and alienate him > > So even putting the ENUM tree in an extranet only accessible > by partners does not help to solve this problem, because the > partners are not really partners. > > And in addition there are still "partners" and others, so you > cannot peer with them; they have their own tree, this > creating the ENUM forest. > > Even if all decide to use the same global tree, and > regardless if this tree is public (e164.arpa or > carrier.e164.arpa) or somewhere else e164.info, it does not > solve the basic problem, because this is a Catch 22. > > Ideas to have a ENUM tree where my entries can only be seen > by some others I decide to do so, is the perverting the whole > idea, and proves the fact that these operators do care about > everything, but not about their costomers. > > Can you imagine an announcement on the PSTN like this: > > "the user you are > calling is hosted with a provider we have no interconnect > agreement with, so we are sorry that we cannot complete your > call. Tell your friend to move over to a provider we have an > agreement with, but be aware, we may change our interconnect > agreements at any time without prior notice, so tell you > friend to move quickly, because in one month this may have > changed already." > > So either the carriers get their whatever together and > introduce an ACQ in public space (because of the Public User > Identities) or they forget the whole issue. > > Richard > > > > > _______________________________________________ > 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 taylor@nortel.com Fri, 24 Jun 2005 16:30:12 -0400 From: Tom Taylor Date: Fri, 24 Jun 2005 16:30:12 -0400 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Carreir ENUM, SIP URIs and DNS In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E347205C@xmb-rtp-20b.amer.cisco.com> Message-ID: <42BC6D29.9080407@nortel.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO I'm not sure you and Richard are really in conflict. Undoubtedly it will be possible to resolve all E.164 numbers into default routes using ENUM. What the present discussion has been all about is what happens after that default routing is realized. Michael Hammer (mhammer) wrote: Richard, What a complicated Gordean Knot we weave! I disagree with your central premise. The issue is not the use or purpose of a sip: URI; it is whether ENUM can act as a global routing mechanism if it's fundamental property "universal access" (or openness) is undermined by walled ENUM gardens. (Funny, I don't hear anyone talking much about "Carrier DNS".) Any user (including those still on TDM) MUST be able to call any other connected user. Metcalf's Law and the value of the VoIP network is at stake. Because the PSTN is part of the equation, all users MUST have E.164 numbers for the previous statement to work. Notice that I did not try to categorize users as being on the Internet or within some walled garden of a service provider. The routing mechanism of VoIP is based (or soon will be) on sip:URI and the ability (using DNS) to translate that into an IP address for routing over ANY IP-based network. But, the assumption is that any user MUST have the ability to translate ANY assigned E.164 number into a sip:URI. That would imply that the resource record for any E.164 number must be reachable universally. That does not mean that all information associated with a user is available, just the basic mapping from E.164 to sip:URI to further route a call. Additional pointers can send one to a private server that can play guard to the exclusive club. The sip: or other URI can lead to a walled garden policeman server (personal, enterprise, or carrier) that only lets "approved guests" through, but that is secondary. As the first part of your message indicates, if a VoIP user does not want to be reached universally, then they don't really need an E.164 number, just a sip:URI, and can stop wasting a public numbering resource. Sooner or later the national regulators will realize that ENUM is broken unless the fundamental E.164-to-URI translation exists publicly for all E.164 numbers. (Just wait until E911 calls/call-backs fail.) The legacy number portability (and in US LERG) database operators will be only too happy to extend their TDM routing mechanisms into the IP space to fill a broken-on-arrival ENUM system. Note that numbers can be ported using ENUM, you just don't need all the legacy NP mechanisms and process to do that. Mike ... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 24 Jun 2005 16:57:57 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 24 Jun 2005 16:57:57 -0400 To: "Tom Taylor" Subject: RE: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3472076@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Tom, Not really in conflict. I see this as a matter of determining how the default routing is realized. In a forest of one tree it is not hard to find a particular fruit on a branch. In a forest of many trees, you have no chance of finding that particular fruit until you can reach the right tree. If everyone insists on owning a whole tree, you end up with the latter, not the former. Mike > -----Original Message----- > From: Tom Taylor [mailto:taylor at nortel.com] > Sent: Friday, June 24, 2005 4:29 PM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: Re: [Enum] Carreir ENUM, SIP URIs and DNS > > I'm not sure you and Richard are really in conflict. > Undoubtedly it will be possible to resolve all E.164 numbers > into default routes using ENUM. What the present discussion > has been all about is what happens after that default routing > is realized. > > Michael Hammer (mhammer) wrote: > > Richard, > > > > What a complicated Gordean Knot we weave! > > > > I disagree with your central premise. The issue is not the use or > > purpose of a sip: URI; it is whether ENUM can act as a > global routing > > mechanism if it's fundamental property "universal access" (or > > openness) is undermined by walled ENUM gardens. (Funny, I > don't hear > > anyone talking much about "Carrier DNS".) > > > > Any user (including those still on TDM) MUST be able to > call any other > > connected user. Metcalf's Law and the value of the VoIP > network is at > > stake. Because the PSTN is part of the equation, all users > MUST have > > E.164 numbers for the previous statement to work. Notice > that I did > > not try to categorize users as being on the Internet or within some > > walled garden of a service provider. > > > > The routing mechanism of VoIP is based (or soon will be) on sip:URI > > and the ability (using DNS) to translate that into an IP > address for > > routing over ANY IP-based network. But, the assumption is that any > > user MUST have the ability to translate ANY assigned E.164 > number into a sip:URI. > > That would imply that the resource record for any E.164 > number must be > > reachable universally. That does not mean that all information > > associated with a user is available, just the basic mapping > from E.164 > > to sip:URI to further route a call. Additional pointers > can send one > > to a private server that can play guard to the exclusive club. The > > sip: or other URI can lead to a walled garden policeman server > > (personal, enterprise, or carrier) that only lets "approved guests" > > through, but that is secondary. > > > > As the first part of your message indicates, if a VoIP user > does not > > want to be reached universally, then they don't really need > an E.164 > > number, just a sip:URI, and can stop wasting a public numbering > > resource. Sooner or later the national regulators will > realize that > > ENUM is broken unless the fundamental E.164-to-URI > translation exists > > publicly for all E.164 numbers. (Just wait until E911 > > calls/call-backs > > fail.) > > > > The legacy number portability (and in US LERG) database > operators will > > be only too happy to extend their TDM routing mechanisms > into the IP > > space to fill a broken-on-arrival ENUM system. Note that > numbers can > > be ported using ENUM, you just don't need all the legacy NP > mechanisms > > and process to do that. > > > > Mike > > > > > > > ... > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 24 Jun 2005 17:01:04 -0400 From: "Stastny Richard" Date: Fri, 24 Jun 2005 17:01:04 -0400 To: "Tom Taylor" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFAD@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Tom Taylor wrote: >I'm not sure you and Richard are really in conflict. I think we are not so far apart. Still, the basic question for any type of ENUM is: Can you reach a sip: URI one gets from an mobile operator e.g. sip:frank at vodafone.de from any enterprise owned SIP server, from sipgate.de or from fwd.pulver.com If yes, any type of ENUM will work, if not, the ENUM is doomed. And of course is ENUM the ultimate in (global) Service Provider Number Portability: porting a number is a change of the NAPTR. The question of User or Carrier ENUM finally succeeds will be decided by the end-user, as always (=marketing;-) Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 24 Jun 2005 17:03:23 -0400 From: "Stastny Richard" Date: Fri, 24 Jun 2005 17:03:23 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFAE@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Mike wrote: >Not really in conflict. I see this as a matter of determining how the >default routing is realized. In a forest of one tree it is not hard to >find a particular fruit on a branch. In a forest of many trees, you >have no chance of finding that particular fruit until you can reach the >right tree. If everyone insists on owning a whole tree, you end up with >the latter, not the former. I like the picture - will eventually use it ;-) Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 24 Jun 2005 20:37:25 -0400 From: "Peter Williams" Date: Fri, 24 Jun 2005 20:37:25 -0400 To: "'Patrik Fältström'" Subject: RE: [Enum] Carrier ENUM In-Reply-To: <71C9629D-EA20-4AB4-849F-E3A2B272EA96@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Patrick, and IETF friends: I think of things really simply - focussing on the case that a (mega-) carrier creates a superior "service quality level" for some fragment of public e164.arpa name space, and perhaps even sells one or more variants of that enhanced ENUM resolution service to other carriers - who nominally administer other fragments in that same naming space. Conventionally, part of the value add providers create is security management. Lets say, practically, that 5 particular fragment providers all agree to act as a single security domain, and thus their ENUM resolver infrastructures all respect either other's user security credentials (provided by a common ISP, perhaps). Surely this is a perfectly reasonable operating model? For example, in the theoretical cs.ucl.ac.uk.e164.arpa enum name space, lets imagine that it?s the AC.UK domain admin (and provider) that actually hosts the ENUM services for all universities in that ac domain, including cs.ucl. When resolving an ENUM tree walk involving peter.cs.ucl.ac.uk.e164.arpa, the mega carrier for all AC.UK naming fragments will, "for AC.UK sourced DNS requests on UK targets ONLY" provide additional ENUM tree walking capabilities to requestors. This will allow the ENUM resolution algorithm to ALSO wander into some NON public ENUM name fragments (operated also by AC.UK, and which do not even have a public access point, perhaps) but only when the two sip end points are known to be UK-regulated. In said extra fragments in a private tree, perhaps a second set of E.164/SIP mappings are maintained, ones for which there are some crypto keys pre-provisioned, with UK-based key escrow, for voip phones protocol usage. In said practical telco culture, the ENUM Algorithm will only be permitted to resolve to entries bearing keys IF the underlying VOIP transport carrier has an interconnect agreement with the ENNUM provider @AC.UK. This agreement will comply with and enforce UK government licensing rules - to ensure, for example, that the various legal message interception capabilities are in place on the VOIP carrier's transport services, should a user actually invoke the security modes ,and the key escrow and consumer privacy rules are working, etc., etc. If these interconnect rules are not satisfied, no secure mode resolution is available: only insecure mappings are ever provided. The security domain vs naming domain models of X.500 were always provider centric. Even if the name space was a public ADMD, the security domain was managed behind the scenes within the provider interconnect arrangements- to allow for regulation on a interconnect basis. ------------ Its hard to know (despite the theory of the universal DNS, now with a tree walking ENUM algorithm added) why IETF would want to DENY folks this model, per se. I'm not really arguing for or against, only detecting the resistance, to the idea itself. If the retort is essentially, well one is challenging the fundamental religion of the Taoist internet, well... lets get real. We dumped all that dogma, in 1994 when the DARPA/NSF/NASA walls came a tumbling down, along with the "thou shalt not sell" rule. If DNS and now ENUM resolution is the last bastion of early IP religion, then its walls SHALL also tumble. I suspect, on half reading the emails, and sensing the tone (mostly), we are dealing with such a religious perspective, here. As you seem to want a formal opinion, this is it: I never like religious operating doctrine disguised as technical rules in protocol standards, addressing bits and bytes. Unfortunately, this is common in the security and DNS WGs, and stems from IAB and US regulatory policy usually. In this community, I would not bother to vote one way or the other, not being sufficiently involved, and thus having no real right to much of a voice. But, I DO wonder WHY its SUCH an issue: letting (professional carrier grade architects) build any deployment (and interconnect-based) model they want, in and across their fragment(s) of the public tree! Peter. > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Patrik Fältström > Sent: Friday, June 24, 2005 9:25 AM > To: Peter Williams > Cc: enum at ietf.org > Subject: Re: [Enum] Carrier ENUM > > > On Jun 24, 2005, at 08:08, Peter Williams wrote: > > > Two providers of private management domain of name servers can > > always share > > a private copy of the e.164.arpa service, served with cached and/or > > augmented information sets. > > Absolutely, but if they have a private copy that both know about (a) > they really don't have to have it in e164.arpa, but they can have it > somewhere else (b) there is no argument why it have to be in > e164.arpa and (this is important) (c) setting up split DNS so that > 100% of the lookups are actually responded correctly with absolutely > no leakage of the responses is extremely difficult. > > DNS is designed to be koherent, that all queries get responded with > the same data, and because of this DNS protocol / caches etc by > design is hard to run within a walled garden. For telephony call > routing, it is enough with one wrongly routed call, and you as a > carrier have problems. Because of this, and the fact I don't see any > need for the "walled garden ENUM tree" have to be rooted in e164.arpa > I don't think it should be there. > > If you don't agree with me (and to be honest, I don't know whether > you do or not), please explain why it has to be in e164.arpa. > > 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 jmce@nortel.com Sun, 26 Jun 2005 15:37:50 -0400 From: "James McEachern" Date: Sun, 26 Jun 2005 15:37:50 -0400 To: enum at ietf.org Subject: RE: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard Stastny wrote: >Still, the basic question for any type of ENUM is: >Can you reach a sip: URI one gets from an mobile operator >e.g. sip:frank at vodafone.de from any enterprise owned >SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Sun, 26 Jun 2005 15:52:05 -0400 From: Adrian Georgescu Date: Sun, 26 Jun 2005 15:52:05 -0400 To: James McEachern Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS In-Reply-To: Message-ID: <4FB57578-40F1-4906-A962-1858F466C3BC@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO On Jun 26, 2005, at 3:37 PM, James McEachern wrote: Richard Stastny wrote: Still, the basic question for any type of ENUM is: Can you reach a sip: URI one gets from an mobile operator e.g. sip:frank at vodafone.de from any enterprise owned SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? What you are missing is that if the target SIP URI is not reachable in the first place, you (as a carrier) would not need to use the e164.arpa tree to publish mappings of an E.164 number to that SIP URI either. Adrian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 26 Jun 2005 15:54:17 -0400 From: "Stastny Richard" Date: Sun, 26 Jun 2005 15:54:17 -0400 To: "James McEachern" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFB8@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO James wrote: >So isn't it really a SIP issue rather than an >ENUM issue? > >What am I missing? Nothing, you are exactly at the point. What I was saying is: ENUM is just an add-on: If you do not have the possibility to put a reachable SIP URI in whatever ENUM you have (User, Carreir, Infrastructure.. ) you cannot use ENUM anyway, so the discussion where the ENUM "forrest" is placed is somewhat useless. Or the other way round: the ENUM tree has to be placed in the same namespace where you can resolve the SIP URI. Putting an ENUM tree im a namespace where you cannot resolve the resulting SIP URIs makes no sense. And if you can resolve the SIP URI and hide the ENUM tree; this is also not very useful. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 21:37 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard Stastny wrote: >Still, the basic question for any type of ENUM is: >Can you reach a sip: URI one gets from an mobile operator >e.g. sip:frank at vodafone.de from any enterprise owned >SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Sun, 26 Jun 2005 16:18:02 -0400 From: "James McEachern" Date: Sun, 26 Jun 2005 16:18:02 -0400 To: enum at ietf.org Subject: RE: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Richard, So is it accurate to say that the ENUM discussion should proceed on the assumption that the resulting URI will be routable, either now, or after some other WG fixes the problem, and that we should not be distracted by this issue? >the ENUM tree has to be placed in >the same namespace where you can resolve the SIP URI. I'm not sure I fully understand the implications of this statement. Do you mean the ENUM tree must be in the same namespace where you can fully resolve the SIP URI? Or is it enough to be in the same namespace where you are able to resolve the URI to the appropriate SIP Proxy, or SBC, or whatever next step that will eventually fully resolve the URI? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Sunday, June 26, 2005 3:57 PM To: McEachern, James [CAR:5N00:EXCH]; enum at ietf.org Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS James wrote: >So isn't it really a SIP issue rather than an >ENUM issue? > >What am I missing? Nothing, you are exactly at the point. What I was saying is: ENUM is just an add-on: If you do not have the possibility to put a reachable SIP URI in whatever ENUM you have (User, Carreir, Infrastructure.. ) you cannot use ENUM anyway, so the discussion where the ENUM "forrest" is placed is somewhat useless. Or the other way round: the ENUM tree has to be placed in the same namespace where you can resolve the SIP URI. Putting an ENUM tree im a namespace where you cannot resolve the resulting SIP URIs makes no sense. And if you can resolve the SIP URI and hide the ENUM tree; this is also not very useful. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 21:37 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard Stastny wrote: >Still, the basic question for any type of ENUM is: >Can you reach a sip: URI one gets from an mobile operator >e.g. sip:frank at vodafone.de from any enterprise owned >SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 26 Jun 2005 16:28:15 -0400 From: "Stastny Richard" Date: Sun, 26 Jun 2005 16:28:15 -0400 To: "James McEachern" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFB9@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO James wrote: >Or is it enough to be in the same namespace where you are able >to resolve the URI to the appropriate SIP Proxy, or SBC, or whatever next >step that will eventually fully resolve the URI? Again you are correct: If the ENUM DNS responses with a SIP URI of the form sip:+samenumber at vodafone.de and the SRV records in the DNS with vodafone.de are pointing to an SBC of vodafone, thats fine. Basically user ENUM is a routing from end-user to end-user (proxy - AoR), carrier ENUM should be a routing from orig network to dest network, so a SBC as entry is ok. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 22:17 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard, So is it accurate to say that the ENUM discussion should proceed on the assumption that the resulting URI will be routable, either now, or after some other WG fixes the problem, and that we should not be distracted by this issue? >the ENUM tree has to be placed in >the same namespace where you can resolve the SIP URI. I'm not sure I fully understand the implications of this statement. Do you mean the ENUM tree must be in the same namespace where you can fully resolve the SIP URI? Or is it enough to be in the same namespace where you are able to resolve the URI to the appropriate SIP Proxy, or SBC, or whatever next step that will eventually fully resolve the URI? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Sunday, June 26, 2005 3:57 PM To: McEachern, James [CAR:5N00:EXCH]; enum at ietf.org Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS James wrote: >So isn't it really a SIP issue rather than an >ENUM issue? > >What am I missing? Nothing, you are exactly at the point. What I was saying is: ENUM is just an add-on: If you do not have the possibility to put a reachable SIP URI in whatever ENUM you have (User, Carreir, Infrastructure.. ) you cannot use ENUM anyway, so the discussion where the ENUM "forrest" is placed is somewhat useless. Or the other way round: the ENUM tree has to be placed in the same namespace where you can resolve the SIP URI. Putting an ENUM tree im a namespace where you cannot resolve the resulting SIP URIs makes no sense. And if you can resolve the SIP URI and hide the ENUM tree; this is also not very useful. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 21:37 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard Stastny wrote: >Still, the basic question for any type of ENUM is: >Can you reach a sip: URI one gets from an mobile operator >e.g. sip:frank at vodafone.de from any enterprise owned >SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sun, 26 Jun 2005 17:49:36 -0400 From: lconroy Date: Sun, 26 Jun 2005 17:49:36 -0400 To: "Stastny Richard" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFB9@oefeg-s04.oefeg.loc> Message-ID: <908a417084a76241c5ca0f4f87ad123b@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Richard, James, folks, Careful - this is strictly true, but... You need to get usable results for your ENUM query. You will also need to get usable results for your subsequent SRV query (as specified in rfc3263), then do AAAA/A6/A lookups on the host name(s) of the server(s) indicated. In addition, you need to deliver messages to the IP address you have found with these ENUM, SRV, AAAA/A6/A queries. That means that for the call to be successful, you need access to the SBC/SIP Server, not just the DNS records that identify it. What happens after it hits the SBC is S.O.P. As an aside, there's nothing that any IETF WG can do to fix broken DNS implementations or broken firewall configurations. atb, Lawrence On 26 Jun 2005, at 21:31, Stastny Richard wrote: James wrote: Or is it enough to be in the same namespace where you are able to resolve the URI to the appropriate SIP Proxy, or SBC, or whatever next step that will eventually fully resolve the URI? Again you are correct: If the ENUM DNS responses with a SIP URI of the form sip:+samenumber at vodafone.de and the SRV records in the DNS with vodafone.de are pointing to an SBC of vodafone, thats fine. Basically user ENUM is a routing from end-user to end-user (proxy - AoR), carrier ENUM should be a routing from orig network to dest network, so a SBC as entry is ok. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 22:17 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard, So is it accurate to say that the ENUM discussion should proceed on the assumption that the resulting URI will be routable, either now, or after some other WG fixes the problem, and that we should not be distracted by this issue? the ENUM tree has to be placed in the same namespace where you can resolve the SIP URI. I'm not sure I fully understand the implications of this statement. Do you mean the ENUM tree must be in the same namespace where you can fully resolve the SIP URI? Or is it enough to be in the same namespace where you are able to resolve the URI to the appropriate SIP Proxy, or SBC, or whatever next step that will eventually fully resolve the URI? Jim -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Sunday, June 26, 2005 3:57 PM To: McEachern, James [CAR:5N00:EXCH]; enum at ietf.org Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS James wrote: So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Nothing, you are exactly at the point. What I was saying is: ENUM is just an add-on: If you do not have the possibility to put a reachable SIP URI in whatever ENUM you have (User, Carreir, Infrastructure.. ) you cannot use ENUM anyway, so the discussion where the ENUM "forrest" is placed is somewhat useless. Or the other way round: the ENUM tree has to be placed in the same namespace where you can resolve the SIP URI. Putting an ENUM tree im a namespace where you cannot resolve the resulting SIP URIs makes no sense. And if you can resolve the SIP URI and hide the ENUM tree; this is also not very useful. Richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: So 26.06.2005 21:37 An: enum at ietf.org Cc: Stastny Richard Betreff: RE: [Enum] Carrier ENUM, SIP URIs and DNS Richard Stastny wrote: Still, the basic question for any type of ENUM is: Can you reach a sip: URI one gets from an mobile operator e.g. sip:frank at vodafone.de from any enterprise owned SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Sun, 26 Jun 2005 23:20:09 -0400 From: "Livingood, Jason" Date: Sun, 26 Jun 2005 23:20:09 -0400 To: "Stastny Richard" Subject: RE: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <6EEEACD9D7F52940BEE26F5467C02C735EDE10@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO > Done. > > No need for E.164 numbers. Right, except for all those silly devices out there with just numeric keypads that are likely to be around for a few more years. ;-) I think you concede as such by noting Richard Shockey's comments on this topic on your ENUM blog (or here - looks as if the text may be the same). > One would think. > > The problem is: they do not want their compet... partners > 1. to know how many users they have Is this that big a fear for carriers? In the US at least, most of the carriers are likely to be public companies and therefore have a responsibility to disclose the number of subscribers. Everyone will know every several months how many subs they have and what the growth, or lack thereof, is. > 2. who these users are - the partner may just make call and alienate him Well, for this a type of regulatory vehicle may help (did I actually write that?). In the US at least, there is the national do-not-call registry which once a user opts into would bar most inbound telemarketing. Also, many IP-based phone services can enable users to block anonymous callers (as on the PSTN) and use whitelisting to only allow calls from known parties. Of course with PSTN service, users are of generally listed in the whitepages directories anyway of course. I think I partially accept this point of your arguement but would say that technical and regulatory methods can play a role in mitigating the risks. And after all, if the customer is being pleased by the carrier, then said carrier should be have nothing to worry about. The competitor may not call but may send a mailer or may put an advert on the TV or on a billboard, or whatever. Customers will be aware of alternatives, whether or not they get said call from competitor. Thus, customer satisfaction is the best tool. Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 26 Jun 2005 23:37:34 -0400 From: "Stastny Richard" Date: Sun, 26 Jun 2005 23:37:34 -0400 To: "Livingood, Jason" Subject: Re: [Enum] Carreir ENUM, SIP URIs and DNS Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFBD@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: RO Jason wrote: >>No need for E.164 numbers. >Right, except for all those silly devices out there with just numeric >keypads that are likely to be around for a few more years. ;-) Correct, you just have to read on ;-) >> The problem is: they do not want their compet... partners >> 1. to know how many users they have >Is this that big a fear for carriers? It seems to me, at least from some just look at: the XConnet presentation at the VON Europe http://enum.nic.at/documents/AETP/Presentations/Austria/0053-2005-05_VON_Europe/200505_VON_Europe_ENUM_Update_BSterman.ppt (link may be broken) You will be able to talk to this guys on Wednesday right sfter your presentation I basically consider this approach - not very wise. >Thus, customer satisfaction is the best tool. Agreed regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 27 Jun 2005 10:04:35 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 27 Jun 2005 10:04:35 -0400 To: "Adrian Georgescu" Subject: RE: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: <072C5B76F7CEAB488172C6F64B30B5E34721A7@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Adrian, May I tweak this slightly. Reachability from a telephony feature standpoint depends on whether the proxy, SBC or whatever is permitted to allow the call through. The issue here is that an ENUM query on an E.164 number from any PSTN gateway MUST resolve to a URI and subsequently to an IP address to which a request can be routed. What the receiving server does with that request is not ENUM's problem, but a service feature. If the above request routing can not take place, then the E.164 number should not have been assigned in the first place, as it is simply wasting a numbering resource. That is the bottom line. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Adrian Georgescu > Sent: Sunday, June 26, 2005 3:52 PM > To: James McEachern > Cc: enum at ietf.org > Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS > > > On Jun 26, 2005, at 3:37 PM, James McEachern wrote: > > > > Richard Stastny wrote: > > > > > > > >> Still, the basic question for any type of ENUM is: Can you reach a > >> sip: URI one gets from an mobile operator e.g. > sip:frank at vodafone.de > >> from any enterprise owned SIP server, from sipgate.de or from > >> fwd.pulver.com > >> > >> > > > > The ability, or inability, to reach a URI such as > > sip:frank at vodafone.de from any enterprise owned SIP server would > > appear to have nothing to do with converting E.164 numbers to URIs. > > The problem would be the same if you started with the URI, > or even if > > there was no E.164 number associated with the URI at all, would it > > not? So isn't it really a SIP issue rather than an ENUM issue? > > > > What am I missing? > > > > What you are missing is that if the target SIP URI is not > reachable in the first place, you (as a carrier) would not > need to use the e164.arpa tree to publish mappings of an > E.164 number to that SIP URI either. > > Adrian > > > > _______________________________________________ > 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 lconroy@insensate.co.uk Mon, 27 Jun 2005 12:44:57 -0400 From: lconroy Date: Mon, 27 Jun 2005 12:44:57 -0400 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E34721A7@xmb-rtp-20b.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi Mike, Adrian, folks, whilst we're doing slight tweaks... Numbers do go out of service. Thus even if a numbering resource was originally assigned for a legitimate use, service to this number may have "gone away". There is still a responsibility on some node to deal with the situation. In the case you describe, the inbound PSTN Gateway is responsible for a sane termination, from the perspective of the PSTN-based call origination point. If IT can't get through then it still has to provide the tri-tone and the appropriate ISUP clearback with some reason code. It might fail to place the call because of: - ENUM failure, or - DNS failure, or - the SBC isn't talking at all to this IP address, or - the SBC rejects the call because this is not from an anointed SBC/known server, or - the SIP URI is wrong or not found or the destination UA is not registered or out of coverage or ... In all these cases, it's the PSTN Gateway that has to pick up the pieces. If the receiving server/SBC does anything other than giving a failure code, then the PSTN gateway just relays state information "back" through the call path, but for all those other cases, it has the joy of working out what reason code to send back if there's an ENUM failure, or ... Should be fun to design these gateways - testing them for interoperability will be even more fun. I await the specs with interest. all the best, Lawrence On 27 Jun 2005, at 15:04, Michael Hammer (mhammer) wrote: Adrian, May I tweak this slightly. Reachability from a telephony feature standpoint depends on whether the proxy, SBC or whatever is permitted to allow the call through. The issue here is that an ENUM query on an E.164 number from any PSTN gateway MUST resolve to a URI and subsequently to an IP address to which a request can be routed. What the receiving server does with that request is not ENUM's problem, but a service feature. If the above request routing can not take place, then the E.164 number should not have been assigned in the first place, as it is simply wasting a numbering resource. That is the bottom line. Mike -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Adrian Georgescu Sent: Sunday, June 26, 2005 3:52 PM To: James McEachern Cc: enum at ietf.org Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS On Jun 26, 2005, at 3:37 PM, James McEachern wrote: Richard Stastny wrote: Still, the basic question for any type of ENUM is: Can you reach a sip: URI one gets from an mobile operator e.g. sip:frank at vodafone.de from any enterprise owned SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? What you are missing is that if the target SIP URI is not reachable in the first place, you (as a carrier) would not need to use the e164.arpa tree to publish mappings of an E.164 number to that SIP URI either. Adrian _______________________________________________ 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 --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 27 Jun 2005 13:08:09 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 27 Jun 2005 13:08:09 -0400 To: "lconroy" Subject: RE: [Enum] Carrier ENUM, SIP URIs and DNS Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3472283@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: RO Lawrence, Of course, error cases as well as service rejection cases must be handled. SIP-ISUP/BICC PTST Gateway interworking: IETF: RFC-3398 ITU-T: Q.1912.5 ATIS: T1.679 Mike > -----Original Message----- > From: lconroy [mailto:lconroy at insensate.co.uk] > Sent: Monday, June 27, 2005 12:45 PM > To: Michael Hammer (mhammer) > Cc: 'enum at ietf.org' ENUM; Adrian Georgescu > Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS > > Hi Mike, Adrian, folks, > whilst we're doing slight tweaks... > Numbers do go out of service. Thus even if a numbering > resource was originally assigned for a legitimate use, > service to this number may have "gone away". There is still a > responsibility on some node to deal with the situation. > > In the case you describe, the inbound PSTN Gateway is > responsible for a sane termination, from the perspective of > the PSTN-based call origination point. > > If IT can't get through then it still has to provide the > tri-tone and the appropriate ISUP clearback with some reason code. > It might fail to place the call because of: > - ENUM failure, or > - DNS failure, or > - the SBC isn't talking at all to this IP address, or > - the SBC rejects the call because this is not from an > anointed SBC/known server, or > - the SIP URI is wrong or not found or the destination UA is > not registered or out of coverage or ... > > In all these cases, it's the PSTN Gateway that has to pick up > the pieces. > > If the receiving server/SBC does anything other than giving a > failure code, then the PSTN gateway just relays state > information "back" > through the call path, but for all those other cases, it has > the joy of working out what reason code to send back if > there's an ENUM failure, or ... > > Should be fun to design these gateways - testing them for > interoperability will be even more fun. > I await the specs with interest. > > all the best, > Lawrence > > On 27 Jun 2005, at 15:04, Michael Hammer (mhammer) wrote: > > Adrian, > > > > May I tweak this slightly. > > > > Reachability from a telephony feature standpoint depends on whether > > the proxy, SBC or whatever is permitted to allow the call through. > > The issue here is that an ENUM query on an E.164 number > from any PSTN > > gateway MUST resolve to a URI and subsequently to an IP address to > > which a request can be routed. What the receiving server does with > > that request is not ENUM's problem, but a service feature. > > > > If the above request routing can not take place, then the > E.164 number > > should not have been assigned in the first place, as it is simply > > wasting a numbering resource. That is the bottom line. > > > > Mike > > > > > >> -----Original Message----- > >> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > >> Of Adrian Georgescu > >> Sent: Sunday, June 26, 2005 3:52 PM > >> To: James McEachern > >> Cc: enum at ietf.org > >> Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS > >> > >> > >> On Jun 26, 2005, at 3:37 PM, James McEachern wrote: > >> > >> > >>> Richard Stastny wrote: > >>> > >>> > >>> > >>>> Still, the basic question for any type of ENUM is: Can > you reach a > >>>> sip: URI one gets from an mobile operator e.g. > >> sip:frank at vodafone.de > >>>> from any enterprise owned SIP server, from sipgate.de or from > >>>> fwd.pulver.com > >>>> > >>>> > >>> > >>> The ability, or inability, to reach a URI such as > >>> sip:frank at vodafone.de from any enterprise owned SIP server would > >>> appear to have nothing to do with converting E.164 > numbers to URIs. > >>> The problem would be the same if you started with the URI, > >> or even if > >>> there was no E.164 number associated with the URI at all, > would it > >>> not? So isn't it really a SIP issue rather than an ENUM issue? > >>> > >>> What am I missing? > >>> > >> > >> What you are missing is that if the target SIP URI is not > reachable > >> in the first place, you (as a carrier) would not need to use the > >> e164.arpa tree to publish mappings of an > >> E.164 number to that SIP URI either. > >> > >> Adrian > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > --------------------------------------- > lawrence conroy |tel:+44-1794-833666 > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Tue, 28 Jun 2005 06:33:30 -0400 From: lconroy Date: Tue, 28 Jun 2005 06:33:30 -0400 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3472283@xmb-rtp-20b.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: RO Hi again Mike, folks, Oh, that it were that simple. AFAICT, these referenced documents do not deal with ENUM failures or DNS failures. RFC3398 section 8.2.6.1 has the SIP to ISDN cause mapping, bit this rather requires that you get to a SIP system in the first place. What reason code does the inbound gateway return if the allegedly authoritative DNS server is lame, or the zone has too many entries, but the server doesn't support TCP or EDNS0, or ...? More importantly, does your gateway send back the same reason codes as mine? all the best, Lawrence On 27 Jun 2005, at 18:05, Michael Hammer (mhammer) wrote: Lawrence, Of course, error cases as well as service rejection cases must be handled. SIP-ISUP/BICC PTST Gateway interworking: IETF: RFC-3398 ITU-T: Q.1912.5 ATIS: T1.679 Mike -----Original Message----- From: lconroy [mailto:lconroy at insensate.co.uk] Sent: Monday, June 27, 2005 12:45 PM To: Michael Hammer (mhammer) Cc: 'enum at ietf.org' ENUM; Adrian Georgescu Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS Hi Mike, Adrian, folks, whilst we're doing slight tweaks... Numbers do go out of service. Thus even if a numbering resource was originally assigned for a legitimate use, service to this number may have "gone away". There is still a responsibility on some node to deal with the situation. In the case you describe, the inbound PSTN Gateway is responsible for a sane termination, from the perspective of the PSTN-based call origination point. If IT can't get through then it still has to provide the tri-tone and the appropriate ISUP clearback with some reason code. It might fail to place the call because of: - ENUM failure, or - DNS failure, or - the SBC isn't talking at all to this IP address, or - the SBC rejects the call because this is not from an anointed SBC/known server, or - the SIP URI is wrong or not found or the destination UA is not registered or out of coverage or ... In all these cases, it's the PSTN Gateway that has to pick up the pieces. If the receiving server/SBC does anything other than giving a failure code, then the PSTN gateway just relays state information "back" through the call path, but for all those other cases, it has the joy of working out what reason code to send back if there's an ENUM failure, or ... Should be fun to design these gateways - testing them for interoperability will be even more fun. I await the specs with interest. all the best, Lawrence On 27 Jun 2005, at 15:04, Michael Hammer (mhammer) wrote: Adrian, May I tweak this slightly. Reachability from a telephony feature standpoint depends on whether the proxy, SBC or whatever is permitted to allow the call through. The issue here is that an ENUM query on an E.164 number from any PSTN gateway MUST resolve to a URI and subsequently to an IP address to which a request can be routed. What the receiving server does with that request is not ENUM's problem, but a service feature. If the above request routing can not take place, then the E.164 number should not have been assigned in the first place, as it is simply wasting a numbering resource. That is the bottom line. Mike -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Adrian Georgescu Sent: Sunday, June 26, 2005 3:52 PM To: James McEachern Cc: enum at ietf.org Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS On Jun 26, 2005, at 3:37 PM, James McEachern wrote: Richard Stastny wrote: Still, the basic question for any type of ENUM is: Can you reach a sip: URI one gets from an mobile operator e.g. sip:frank at vodafone.de from any enterprise owned SIP server, from sipgate.de or from fwd.pulver.com The ability, or inability, to reach a URI such as sip:frank at vodafone.de from any enterprise owned SIP server would appear to have nothing to do with converting E.164 numbers to URIs. The problem would be the same if you started with the URI, or even if there was no E.164 number associated with the URI at all, would it not? So isn't it really a SIP issue rather than an ENUM issue? What am I missing? What you are missing is that if the target SIP URI is not reachable in the first place, you (as a carrier) would not need to use the e164.arpa tree to publish mappings of an E.164 number to that SIP URI either. Adrian _______________________________________________ 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 --------------------------------------- lawrence conroy |tel:+44-1794-833666 --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum