From lwc@roke.co.uk Tue, 01 Jun 2004 10:10:32 -0400 From: "Conroy, Lawrence (SMTP)" Date: Tue, 01 Jun 2004 10:10:32 -0400 To: Jim Reid Subject: Re: [Enum] Re: IP claims that may impact ENUM In-Reply-To: <20428.1086018060@gromit.rfc1035.com> Message-ID: <495AA4D3-B3BC-11D8-AD10-00039355516C@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, ...and I hope you have more joy than I. I did manage to extract each of the 55 pages of the PCT/US00/14780 Patent Application as a separate scanned .PDF, so after stitching these together I now have a 1.8 MB .PDF of this fine document. Note - this whole thing (i.e. not just the PCT) appears to be an International application; I'm not sure if the UK one has been actually granted or they have merely applied for a patent and the search has not been done yet. I would be surprised if the Examiner managed to find some novelty from what I've seen and the dates involved. all the best, Lawrence On 31 May 2004, at 4:41 pm, Jim Reid wrote: "Desiree" == Desiree Miloshevic writes: Desiree> Jim, how did you get that data? I tried entering the Desiree> number in the db below and it said publicaiton number Desiree> invalid? The web site implies Publication Numbers end in digits, not a letter Dropping the trailing 'B' from the reference Scott quoted will work. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 07 Jun 2004 17:18:00 -0400 From: Richard Shockey Date: Mon, 07 Jun 2004 17:18:00 -0400 To: enum at ietf.org Subject: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <6.1.0.6.2.20040607162916.03aaaef0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Patrik and I will start to accept idea now. If there are drafts we need to be aware of coming down the pipeline please let us know. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 08 Jun 2004 17:12:50 -0400 From: Internet-Drafts@ietf.org Date: Tue, 08 Jun 2004 17:12:50 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-04.txt Message-ID: <200406082012.QAA21192@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : E.164 Number Mapping for the Extensible Provisioning Protocol Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-04.txt Pages : 17 Date : 2004-6-8 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-epp-e164-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Wed, 09 Jun 2004 14:01:54 -0400 From: Richard Shockey Date: Wed, 09 Jun 2004 14:01:54 -0400 To: enum at ietf.org Subject: [Enum] Fwd: Last Call: 'IFAX service of ENUM' to Proposed Standard Message-ID: <6.1.0.6.2.20040609133723.03f68280@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R X-test-idtracker: no To: IETF-Announce From: The IESG Date: Wed, 09 Jun 2004 11:30:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ietf-fax at imc.org Subject: Last Call: 'IFAX service of ENUM' to Proposed Standard X-BeenThere: ietf-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: iesg at ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces at ietf.org The IESG has received a request from the Internet Fax WG to consider the following document: - 'IFAX service of ENUM ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2004-06-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-faxservice-enum-02.txt _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Wed, 09 Jun 2004 19:26:04 -0400 From: Michael Haberler Date: Wed, 09 Jun 2004 19:26:04 -0400 To: Richard Shockey Message-ID: <6.1.0.6.2.20040610010800.03152a38@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R I wrote a "rough running code" implementation of the ifax:mailto enumservice in the Asterisk IP PBX see http://bugs.digium.com/bug_view_page.php?bug_id=0001720 for the diffs, they are in not in the mainstream code yet (login as anonymous through http://bugs.digium.com and 'jump' to BugID 0001720) it is based on the opencall.org SpanDSP softfax. -Michael At 19:37 09.06.2004, Richard Shockey wrote: X-test-idtracker: no To: IETF-Announce From: The IESG Date: Wed, 09 Jun 2004 11:30:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ietf-fax at imc.org Subject: Last Call: 'IFAX service of ENUM' to Proposed Standard X-BeenThere: ietf-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: iesg at ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces at ietf.org The IESG has received a request from the Internet Fax WG to consider the following document: - 'IFAX service of ENUM ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2004-06-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-faxservice-enum-02.txt _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 10 Jun 2004 04:06:30 -0400 From: "Stastny Richard" Date: Thu, 10 Jun 2004 04:06:30 -0400 To: "Richard Shockey" Subject: AW: [Enum] Please start thinking about agenda items for IETF San Diegoetc Message-ID: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Rich, I am currently writing on a draft for registration of enum-service "void", I hope I will have it ready before the deadline Another item I could offer is about the Austrian number ordinance (in force) and the ENUM-driven numbers. A hot issue currently is infrastructure ENUM. I do not know if we should discuss this in ENUM WG or in a separate BoF as you proposed. Infrastructure ENUM is getting currently more speed in take-up then ENUM in e164.arpa. The reason is (as you know very well) that there is an increasing need for VoIP operators to interconnect their islands on VoIP. There a really two groups: one is trying to hide the end-user information by not disclosing the URIs to the public (I call them the NGN walled gardens) and the others which want to disclose the URIs (the zero termination cost club), and they would like to go into e164.arpa, but do not get delegations in their country. These guys look for a (temporary, unregulated=quick) solution beside e164.arpa, but will be at least not lost forever for e164.arpa (at least for some time). Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on an European scale, linking all European virtual VoIP providers together with iENUM. BTW, Henry said clearly at the the VON Europe that he consideres implementations not giving out URIs to the end-user not as VoIP. So IMHO there is currently a critical time period for e164.arpa. If e164.arpa is not implemented very soon in a wide range of countries, it will be dead. One year trial in +1 is definetely too long, and this is also important for Europe since it seems that many countries, even if the have delegations already, are still waiting for the US. Or as James Seng said at the ENUM Workshop in Brunei: "The biggest problem in ENUM currently is: -Those who want to do trials do not get delegations. -Those who get delegations do not know what to do with it." And I can even add to this: time for trials is over, or it is game over (TILT). And this not for technical reasons, but for administrative and regulatory reasons. Groups of operators will move to infrastructure ENUM, which is in pronciple not bad, but will delay global interoperability for some time until a new "golden tree" finally emerges. In infrastructure ENUM there is of courso also the danger of some wild implementations ala 882 99 and the Boing 747 Area code, adding to customer confusion. I do not know if these problems are IETF issues at all, but since e164.arpa is defined in RFC3671, I think it is. regards Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Mo 07.06.2004 22:31 An: enum at ietf.org Cc: paf at cisco.com Betreff: [Enum] Please start thinking about agenda items for IETF San Diegoetc Patrik and I will start to accept idea now. If there are drafts we need to be aware of coming down the pipeline please let us know. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Thu, 10 Jun 2004 06:40:14 -0400 From: "Christian de Larrinaga" Date: Thu, 10 Jun 2004 06:40:14 -0400 To: "Stastny Richard" Subject: RE: [Enum] Please start thinking about agenda items for IETF SanDiegoetc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard Do you think that operators are likely to establish an unofficial golden tree before enough countries in e164 get round to it? Or do you think that in the end the costs and oversight issues of such an undertaking will mean that iENUM players will come round to the preference of encouraging e164 deployment to support their customer offerings with "universal" connectivity? Christian Christian de Larrinaga Network Brokers Ltd -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: 10 June 2004 08:56 To: Richard Shockey; enum at ietf.org Cc: paf at cisco.com Subject: AW: [Enum] Please start thinking about agenda items for IETF SanDiegoetc Hi Rich, I am currently writing on a draft for registration of enum-service "void", I hope I will have it ready before the deadline Another item I could offer is about the Austrian number ordinance (in force) and the ENUM-driven numbers. A hot issue currently is infrastructure ENUM. I do not know if we should discuss this in ENUM WG or in a separate BoF as you proposed. Infrastructure ENUM is getting currently more speed in take-up then ENUM in e164.arpa. The reason is (as you know very well) that there is an increasing need for VoIP operators to interconnect their islands on VoIP. There a really two groups: one is trying to hide the end-user information by not disclosing the URIs to the public (I call them the NGN walled gardens) and the others which want to disclose the URIs (the zero termination cost club), and they would like to go into e164.arpa, but do not get delegations in their country. These guys look for a (temporary, unregulated=quick) solution beside e164.arpa, but will be at least not lost forever for e164.arpa (at least for some time). Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on an European scale, linking all European virtual VoIP providers together with iENUM. BTW, Henry said clearly at the the VON Europe that he consideres implementations not giving out URIs to the end-user not as VoIP. So IMHO there is currently a critical time period for e164.arpa. If e164.arpa is not implemented very soon in a wide range of countries, it will be dead. One year trial in +1 is definetely too long, and this is also important for Europe since it seems that many countries, even if the have delegations already, are still waiting for the US. Or as James Seng said at the ENUM Workshop in Brunei: "The biggest problem in ENUM currently is: -Those who want to do trials do not get delegations. -Those who get delegations do not know what to do with it." And I can even add to this: time for trials is over, or it is game over (TILT). And this not for technical reasons, but for administrative and regulatory reasons. Groups of operators will move to infrastructure ENUM, which is in pronciple not bad, but will delay global interoperability for some time until a new "golden tree" finally emerges. In infrastructure ENUM there is of courso also the danger of some wild implementations ala 882 99 and the Boing 747 Area code, adding to customer confusion. I do not know if these problems are IETF issues at all, but since e164.arpa is defined in RFC3671, I think it is. regards Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Mo 07.06.2004 22:31 An: enum at ietf.org Cc: paf at cisco.com Betreff: [Enum] Please start thinking about agenda items for IETF San Diegoetc Patrik and I will start to accept idea now. If there are drafts we need to be aware of coming down the pipeline please let us know. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 10 Jun 2004 11:44:41 -0400 From: "Stastny Richard" Date: Thu, 10 Jun 2004 11:44:41 -0400 To: Subject: AW: [Enum] Please start thinking about agenda items for IETF SanDiegoetc Message-ID: <06CF906FE3998C4E944213062009F162233E5D@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >Do you think that operators are likely to establish an unofficial golden tree before enough countries in e164 get round to >it? The answer is yes, it is happening already, see e.g. http://www.lightreading.com/document.asp?site=lightreading&doc_id=53617 The problem is that there is not ONE unofficial tree, there is a whole forest. regards Richard -----UrsprĂngliche Nachricht----- Von: Christian de Larrinaga [mailto:cdel at firsthand.net] Gesendet: Do 10.06.2004 12:29 An: Stastny Richard; Richard Shockey; enum at ietf.org Cc: paf at cisco.com Betreff: RE: [Enum] Please start thinking about agenda items for IETF SanDiegoetc Richard Do you think that operators are likely to establish an unofficial golden tree before enough countries in e164 get round to it? Or do you think that in the end the costs and oversight issues of such an undertaking will mean that iENUM players will come round to the preference of encouraging e164 deployment to support their customer offerings with "universal" connectivity? Christian Christian de Larrinaga Network Brokers Ltd -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: 10 June 2004 08:56 To: Richard Shockey; enum at ietf.org Cc: paf at cisco.com Subject: AW: [Enum] Please start thinking about agenda items for IETF SanDiegoetc Hi Rich, I am currently writing on a draft for registration of enum-service "void", I hope I will have it ready before the deadline Another item I could offer is about the Austrian number ordinance (in force) and the ENUM-driven numbers. A hot issue currently is infrastructure ENUM. I do not know if we should discuss this in ENUM WG or in a separate BoF as you proposed. Infrastructure ENUM is getting currently more speed in take-up then ENUM in e164.arpa. The reason is (as you know very well) that there is an increasing need for VoIP operators to interconnect their islands on VoIP. There a really two groups: one is trying to hide the end-user information by not disclosing the URIs to the public (I call them the NGN walled gardens) and the others which want to disclose the URIs (the zero termination cost club), and they would like to go into e164.arpa, but do not get delegations in their country. These guys look for a (temporary, unregulated=quick) solution beside e164.arpa, but will be at least not lost forever for e164.arpa (at least for some time). Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on an European scale, linking all European virtual VoIP providers together with iENUM. BTW, Henry said clearly at the the VON Europe that he consideres implementations not giving out URIs to the end-user not as VoIP. So IMHO there is currently a critical time period for e164.arpa. If e164.arpa is not implemented very soon in a wide range of countries, it will be dead. One year trial in +1 is definetely too long, and this is also important for Europe since it seems that many countries, even if the have delegations already, are still waiting for the US. Or as James Seng said at the ENUM Workshop in Brunei: "The biggest problem in ENUM currently is: -Those who want to do trials do not get delegations. -Those who get delegations do not know what to do with it." And I can even add to this: time for trials is over, or it is game over (TILT). And this not for technical reasons, but for administrative and regulatory reasons. Groups of operators will move to infrastructure ENUM, which is in pronciple not bad, but will delay global interoperability for some time until a new "golden tree" finally emerges. In infrastructure ENUM there is of courso also the danger of some wild implementations ala 882 99 and the Boing 747 Area code, adding to customer confusion. I do not know if these problems are IETF issues at all, but since e164.arpa is defined in RFC3671, I think it is. regards Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Mo 07.06.2004 22:31 An: enum at ietf.org Cc: paf at cisco.com Betreff: [Enum] Please start thinking about agenda items for IETF San Diegoetc Patrik and I will start to accept idea now. If there are drafts we need to be aware of coming down the pipeline please let us know. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 11 Jun 2004 07:44:39 -0400 From: Richard Shockey Date: Fri, 11 Jun 2004 07:44:39 -0400 To: "Stastny Richard" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: <6.1.0.6.2.20040610114438.03a8dec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 03:56 AM 6/10/200 Hi Rich, I am currently writing on a draft for registration of enum-service "void", I hope I will have it ready before the deadline OK Another item I could offer is about the Austrian number ordinance (in force) and the ENUM-driven numbers. Well we have so far 1. The ENUM operations document that needs very careful review. 2. Andrzej Bartosiewicz "draft-bartosiewicz-enterprise-enum-00.txt" 3. Scott Hollenbeck on EPP-e164 and whether this is fully baked enough to advance . I'm disappointed to see that there has been little or no discussion of this important work on the list. A hot issue currently is infrastructure ENUM. I do not know if we should discuss this in ENUM WG or in a separate BoF as you proposed. I still don't know. I vacillate on this issue depending on cicada insects I have to deal with in the morning. I'm curious to hear what the list thinks about this. I'm reluctant to use WG time since the discussion of infrastructure/carrier ENUM ( aka non e164.arpa) could spin off in any number of useless directions and there is more fundamental question on whether their is even an appropriate role for the IETF in this area at all. That said its manifestly self evident that everyone and their brother-in-law is either becoming a VoIP service provider and or infrastructure ENUM registry. If we did a BoF on carrier ENUM , what would the proposed agenda be? Infrastructure ENUM is getting currently more speed in take-up then ENUM in e164.arpa. The reason is (as you know very well) that there is an increasing need for VoIP operators to interconnect their islands on VoIP. ENUM and VoIP have been joined at the hip since its inception. We've always known this. As VoIP takes off like a rocket the need to interconnect the islands increases exponentially. There a really two groups: one is trying to hide the end-user information by not disclosing the URIs to the public (I call them the NGN walled gardens) and the others which want to disclose the URIs (the zero termination cost club), and they would like to go into e164.arpa, but do not get delegations in their country. These guys look for a (temporary, unregulated=quick) solution beside e164.arpa, but will be at least not lost forever for e164.arpa (at least for some time). Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on an European scale, linking all European virtual VoIP providers together with iENUM. humm and as you know a group of Asia-Pac CCTLD operators are putting together thieir own ENUM Engineering group http://www.apenum.org BTW, Henry said clearly at the the VON Europe that he consideres implementations not giving out URIs to the end-user not as VoIP. Dr. Sinnreich, as usual, is absolutely correct. So IMHO there is currently a critical time period for e164.arpa. If e164.arpa is not implemented very soon in a wide range of countries, it will be dead. One year trial in +1 is definetely too long, and this is also important for Europe since it seems that many countries, even if the have delegations already, are still waiting for the US. well you remember that +1 is a unique problem in herding 19 nation states together but the progress in recent months has been substantial. The Canadian ENUM forum is moving forward very quickly the NANP regulators are in ongoing discussions...etc etc. If North Americans would like the process to move faster they can always write their MP's, Senators and Congressmen ..the FCC, The CRTC, the DoC etc etc. I'm told they enjoy letters from constituents. Or as James Seng said at the ENUM Workshop in Brunei: "The biggest problem in ENUM currently is: -Those who want to do trials do not get delegations. -Those who get delegations do not know what to do with it." And I can even add to this: time for trials is over, or it is game over (TILT). Right ..It works. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 11 Jun 2004 07:45:09 -0400 From: "Stastny Richard" Date: Fri, 11 Jun 2004 07:45:09 -0400 To: "Richard Shockey" Subject: Re: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <06CF906FE3998C4E944213062009F162233E60@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >If we did a BoF on carrier ENUM , what would the proposed agenda be? Concerning IETF two agenda items could be: 1. What are the principal differences between user and carrier ENUM, if any? 2. Is there any additional requirement in protocol, eg different enumservices carrier ENUM would need? If yes, speak now. Now to non IETF, but ENUM issues: >That said its manifestly self evident that everyone and their >brother-in-law is either becoming a VoIP service provider and or >infrastructure ENUM registry. >>Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on >>an European scale, linking all European virtual VoIP providers together >>with iENUM. >humm and as you know a group of Asia-Pac CCTLD operators are putting >together thieir own ENUM Engineering group >http://www.apenum.org of course I now about APEET ;-) (hi James) I consider the sideways operation born out of disparation with their regulators or ENUM Forums of the mentioned groups still in principle as user ENUM, and not operator ENUM, because this groups accept the end-to-end principle Dr. Sinnreich and the IETF is talking aboit. Since most of the usual suspects know each other, we may still be able to capture the movement before it is completely out of the box and at least agree on a common tree. I also suggest to host the tier 0 of this tree also with RIPE, and delegate the CC via the national or regional groups forming. These group should decide who is operating the tier 1s for a country or group of countries. Since this then stays near RIPE, this would be in most cases also the potential tier 1s for e164.arpa, so a later transition back to e164.arpa would be easier. BTW, in SER and asterisk (and also in the IX66 beta) the query of different trees for different number ranges or first querying e164.arpa and then another tree is already implemented (see freenum.org), so the two systems could smoothly co-operate and run in paralell And finally it would create some pressure to get e164.arpa on track asap. Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Do 10.06.2004 18:08 An: Stastny Richard; enum at ietf.org Cc: paf at cisco.com Betreff: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc At 03:56 AM 6/10/200 >Hi Rich, > >I am currently writing on a draft for registration of enum-service "void", >I hope I will have it ready before the deadline OK > >Another item I could offer is about the Austrian number ordinance >(in force) and the ENUM-driven numbers. Well we have so far 1. The ENUM operations document that needs very careful review. 2. Andrzej Bartosiewicz "draft-bartosiewicz-enterprise-enum-00.txt" 3. Scott Hollenbeck on EPP-e164 and whether this is fully baked enough to advance . I'm disappointed to see that there has been little or no discussion of this important work on the list. > >A hot issue currently is infrastructure ENUM. I do not know if we should >discuss >this in ENUM WG or in a separate BoF as you proposed. I still don't know. I vacillate on this issue depending on cicada insects I have to deal with in the morning. I'm curious to hear what the list thinks about this. I'm reluctant to use WG time since the discussion of infrastructure/carrier ENUM ( aka non e164.arpa) could spin off in any number of useless directions and there is more fundamental question on whether their is even an appropriate role for the IETF in this area at all. That said its manifestly self evident that everyone and their brother-in-law is either becoming a VoIP service provider and or infrastructure ENUM registry. If we did a BoF on carrier ENUM , what would the proposed agenda be? > >Infrastructure ENUM is getting currently more speed in take-up then >ENUM in e164.arpa. The reason is (as you know very well) that >there is an increasing need for VoIP operators to interconnect >their islands on VoIP. ENUM and VoIP have been joined at the hip since its inception. We've always known this. As VoIP takes off like a rocket the need to interconnect the islands increases exponentially. > >There a really two groups: one is trying to hide the end-user information >by not disclosing the URIs to the public (I call them the NGN walled gardens) >and the others which want to disclose the URIs (the zero termination cost >club), >and they would like to go into e164.arpa, but do not get delegations in >their country. >These guys look for a (temporary, unregulated=quick) solution beside >e164.arpa, but >will be at least not lost forever for e164.arpa (at least for some time). > >Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing on >an European scale, linking all European virtual VoIP providers together >with iENUM. humm and as you know a group of Asia-Pac CCTLD operators are putting together thieir own ENUM Engineering group http://www.apenum.org > >BTW, Henry said clearly at the the VON Europe that he consideres >implementations >not giving out URIs to the end-user not as VoIP. Dr. Sinnreich, as usual, is absolutely correct. > >So IMHO there is currently a critical time period for e164.arpa. If e164.arpa >is not implemented very soon in a wide range of countries, it will be dead. >One year trial in +1 is definetely too long, and this is also important >for Europe >since it seems that many countries, even if the have delegations already, >are still >waiting for the US. well you remember that +1 is a unique problem in herding 19 nation states together but the progress in recent months has been substantial. The Canadian ENUM forum is moving forward very quickly the NANP regulators are in ongoing discussions...etc etc. If North Americans would like the process to move faster they can always write their MP's, Senators and Congressmen ..the FCC, The CRTC, the DoC etc etc. I'm told they enjoy letters from constituents. > >Or as James Seng said at the ENUM Workshop in Brunei: >"The biggest problem in ENUM currently is: >-Those who want to do trials do not get delegations. >-Those who get delegations do not know what to do with it." > >And I can even add to this: time for trials is over, or it is game over >(TILT). Right ..It works. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Fri, 11 Jun 2004 10:16:29 -0400 From: James Seng Date: Fri, 11 Jun 2004 10:16:29 -0400 To: enum at ietf.org Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: <200406112116.09232.jseng@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R i would support enterprise and infrastructure enum to be part of the enum charter. i would prefer EPP-e164 to be @ PROVREG instead. discussion maybe, charter, no. james On 11 June 2004 am 00:08, Richard Shockey wrote: > Well we have so far > > 1. The ENUM operations document that needs very careful review. > > 2. Andrzej Bartosiewicz "draft-bartosiewicz-enterprise-enum-00.txt" > > 3. Scott Hollenbeck on EPP-e164 and whether this is fully baked enough to > advance . I'm disappointed to see that there has been little or no > discussion of this important work on the list. > > >A hot issue currently is infrastructure ENUM. I do not know if we should > >discuss > >this in ENUM WG or in a separate BoF as you proposed. > > I still don't know. I vacillate on this issue depending on cicada insects > I have to deal with in the morning. > > I'm curious to hear what the list thinks about this. I'm reluctant to use > WG time since the discussion of infrastructure/carrier ENUM ( aka non > e164.arpa) could spin off in any number of useless directions and there is > more fundamental question on whether their is even an appropriate role for > the IETF in this area at all. > > That said its manifestly self evident that everyone and their > brother-in-law is either becoming a VoIP service provider and or > infrastructure ENUM registry. > > If we did a BoF on carrier ENUM , what would the proposed agenda be? > > >Infrastructure ENUM is getting currently more speed in take-up then > >ENUM in e164.arpa. The reason is (as you know very well) that > >there is an increasing need for VoIP operators to interconnect > >their islands on VoIP. > > ENUM and VoIP have been joined at the hip since its inception. We've always > known this. As VoIP takes off like a rocket the need to interconnect the > islands increases exponentially. > > >There a really two groups: one is trying to hide the end-user information > >by not disclosing the URIs to the public (I call them the NGN walled > > gardens) and the others which want to disclose the URIs (the zero > > termination cost club), > >and they would like to go into e164.arpa, but do not get delegations in > >their country. > >These guys look for a (temporary, unregulated=quick) solution beside > >e164.arpa, but > >will be at least not lost forever for e164.arpa (at least for some time). > > > >Here at VON Europe a group of UK ITSPs (ITSPA) is considering such a thing > > on an European scale, linking all European virtual VoIP providers > > together with iENUM. > > humm and as you know a group of Asia-Pac CCTLD operators are putting > together thieir own ENUM Engineering group > > http://www.apenum.org > > >BTW, Henry said clearly at the the VON Europe that he consideres > >implementations > >not giving out URIs to the end-user not as VoIP. > > Dr. Sinnreich, as usual, is absolutely correct. > > >So IMHO there is currently a critical time period for e164.arpa. If > > e164.arpa is not implemented very soon in a wide range of countries, it > > will be dead. One year trial in +1 is definetely too long, and this is > > also important for Europe > >since it seems that many countries, even if the have delegations already, > >are still > >waiting for the US. > > well you remember that +1 is a unique problem in herding 19 nation > states together but the progress in recent months has been substantial. The > Canadian ENUM forum is moving forward very quickly the NANP regulators are > in ongoing discussions...etc etc. > > If North Americans would like the process to move faster they can always > write their MP's, Senators and Congressmen ..the FCC, The CRTC, the DoC etc > etc. I'm told they enjoy letters from constituents. > > >Or as James Seng said at the ENUM Workshop in Brunei: > >"The biggest problem in ENUM currently is: > >-Those who want to do trials do not get delegations. > >-Those who get delegations do not know what to do with it." > > > >And I can even add to this: time for trials is over, or it is game over > >(TILT). > > Right ..It works. > > > > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > 815.333.1237 or > ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Fri, 11 Jun 2004 10:47:24 -0400 From: "Christian de Larrinaga" Date: Fri, 11 Jun 2004 10:47:24 -0400 To: "Stastny Richard" Subject: RE: [Enum] Please start thinking about agenda items for IETFSanDiegoetc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5D@oefeg-s02.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard >>Do you think that operators are likely to establish an unofficial golden tree before enough countries in e164 get round to >it? >The ansI wer is yes, it is happening already, see e.g. >http://www.lightreading.com/document.asp?site=lightreading&doc_id=53617 --->cdel > Nice article. But the argument that nobody has managed to think of a reason why users might want ENUM does not lead to the conclusion that users won't find a few reasons themselves once a billion or so are using VoIP end to end regularly. >The problem is that there is not ONE unofficial tree, there is a whole forest. --->cdel >If the premise is accepted that universal addressing requires a golden tree then where we have a forest of trees (or forest of forests) these ultimately will all be looking to form into the universal golden tree. The first question is whether e164 is not the most obvious way for these "trees or forests" to ultimately interconnect? If not then why not? Secondly if infrastructure ENUM contiunues to be seen as a useful tool for carriers then this could become an important contributor to boost VoIP usage. These new users in turn will learn that they can take control by using ENUM amongst other tools themselves to manipulate the routing through URI and or IP address routing and so strengthen independence from operators. (Hence significance of Henry Sinnrich's observation). So I am not convinced as yet that iENUM is a long range threat to existance of e164, provided e164 is implemented, robustly and universally, although I can see it might cause ripples of concern amongst us sensitive folk involved in various national trials as we contemplate the possibility that the infra-structures being designed to support e164 deployment have not taken (or been able to take) the market impact of iENUM into account. Christian Christian de Larrinaga _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 11 Jun 2004 10:53:54 -0400 From: Richard Shockey Date: Fri, 11 Jun 2004 10:53:54 -0400 To: James Seng Message-ID: <6.1.0.6.2.20040611101914.039e5c80@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 09:16 AM 6/11/2004, James Seng wrote: i would support enterprise and infrastructure enum to be part of the enum charter. humm OK I'd certainly like to hear views on this subject from a wide a group as possible from the list. James ..at the very least put together a BOF? What kind of charter for the BOF would you favor? i would prefer EPP-e164 to be @ PROVREG instead. discussion maybe, charter, no. PROVRED is already shut down. Its seems appropriate to review the application specifics here but to your point there has unfortunately has not been much discussion on Scott's excellent draft. james On >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 11 Jun 2004 11:22:06 -0400 From: Jim Reid Date: Fri, 11 Jun 2004 11:22:06 -0400 To: James Seng Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <200406112116.09232.jseng@pobox.org.sg> Message-ID: <24590.1086965516@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "James" == James Seng writes: James> i would support enterprise and infrastructure enum to be James> part of the enum charter. Me too! I believe infrastructure ENUM belongs under e164.arpa, although this will be achieved with split DNS. Choosing another domain name for this stuff will make life difficult for applications that will live in both worlds. And there's already a working process in place for delegations under e164.arpa. Picking another domain name could cause fragmentation and complicate the relationship with ITU and the various alternate ENUM tree providers. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Fri, 11 Jun 2004 11:43:30 -0400 From: "Hollenbeck, Scott" Date: Fri, 11 Jun 2004 11:43:30 -0400 To: "'enum at ietf.org> Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03677405@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > >i would prefer EPP-e164 to be @ PROVREG instead. discussion > maybe, charter, > >no. > > PROVRED is already shut down. Its seems appropriate to review the > application specifics here but to your point there has > unfortunately has > not been much discussion on Scott's excellent draft. Plus, we had this discussion about "which WG?" two *years* ago. It's a "draft-enum" document because a discussion that took place during IETF-53 (March 2002) was confirmed on the WG mailing list. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From sdlind@att.com Fri, 11 Jun 2004 11:54:02 -0400 From: "Lind, Steven D, ALABS" Date: Fri, 11 Jun 2004 11:54:02 -0400 To: "Stastny Richard" Subject: RE: [Enum] Please start thinking about agenda items for IETF SanDiego etc Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard S., As to your proposed agenda item 1, I believe that the direct should be: 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the "Carrier" ENUM activities on that side of the pond. Steve -------------------------------------------------------------------------------- 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: Thursday, June 10, 2004 1:16 PM > To: Richard Shockey; enum at ietf.org > Cc: paf at cisco.com > Subject: Re: [Enum] Please start thinking about agenda items for IETF > SanDiego etc > > > >If we did a BoF on carrier ENUM , what would the proposed agenda be? > > Concerning IETF two agenda items could be: > > 1. What are the principal differences between user and > carrier ENUM, if any? > 2. Is there any additional requirement in protocol, eg > different enumservices > carrier ENUM would need? If yes, speak now. > > Now to non IETF, but ENUM issues: > > >That said its manifestly self evident that everyone and their > >brother-in-law is either becoming a VoIP service provider and or > >infrastructure ENUM registry. > > >>Here at VON Europe a group of UK ITSPs (ITSPA) is > considering such a thing on > >>an European scale, linking all European virtual VoIP > providers together > >>with iENUM. > > >humm and as you know a group of Asia-Pac CCTLD operators are putting > >together thieir own ENUM Engineering group > > >http://www.apenum.org > > of course I now about APEET ;-) (hi James) > > I consider the sideways operation born out of disparation with their > regulators or ENUM Forums of the mentioned groups > still in principle as user ENUM, and not operator ENUM, > because this groups accept the end-to-end principle Dr. Sinnreich > and the IETF is talking aboit. > > Since most of the usual suspects know each other, we may still > be able to capture the movement before it is completely out of > the box and at least agree on a common tree. > > I also suggest to host the tier 0 of this tree also with RIPE, > and delegate the CC via the national or regional groups > forming. These group should decide who is operating the > tier 1s for a country or group of countries. Since this then > stays near RIPE, this would be in most cases also the potential > tier 1s for e164.arpa, so a later transition back to e164.arpa > would be easier. > > BTW, in SER and asterisk (and also in the IX66 beta) the query of > different trees for different number ranges or first querying > e164.arpa > and then another tree is already implemented (see freenum.org), > so the two systems could smoothly co-operate and run in paralell > > And finally it would create some pressure to get e164.arpa on > track asap. > > Richard > > > -----UrsprĂngliche Nachricht----- > Von: Richard Shockey [mailto:richard at shockey.us] > Gesendet: Do 10.06.2004 18:08 > An: Stastny Richard; enum at ietf.org > Cc: paf at cisco.com > Betreff: Re: AW: [Enum] Please start thinking about > agenda items for IETF San Diego etc > > > > At 03:56 AM 6/10/200 > > >Hi Rich, > > > >I am currently writing on a draft for registration of > enum-service "void", > >I hope I will have it ready before the deadline > > OK > > > > >Another item I could offer is about the Austrian > number ordinance > >(in force) and the ENUM-driven numbers. > > Well we have so far > > 1. The ENUM operations document that needs very careful review. > > 2. Andrzej Bartosiewicz > "draft-bartosiewicz-enterprise-enum-00.txt" > > 3. Scott Hollenbeck on EPP-e164 and whether this is > fully baked enough to > advance . I'm disappointed to see that there has been > little or no > discussion of this important work on the list. > > > > >A hot issue currently is infrastructure ENUM. I do not > know if we should > >discuss > >this in ENUM WG or in a separate BoF as you proposed. > > I still don't know. I vacillate on this issue > depending on cicada insects > I have to deal with in the morning. > > I'm curious to hear what the list thinks about this. > I'm reluctant to use > WG time since the discussion of infrastructure/carrier > ENUM ( aka non > e164.arpa) could spin off in any number of useless > directions and there is > more fundamental question on whether their is even an > appropriate role for > the IETF in this area at all. > > That said its manifestly self evident that everyone and their > brother-in-law is either becoming a VoIP service provider and or > infrastructure ENUM registry. > > If we did a BoF on carrier ENUM , what would the > proposed agenda be? > > > > >Infrastructure ENUM is getting currently more speed in > take-up then > >ENUM in e164.arpa. The reason is (as you know very well) that > >there is an increasing need for VoIP operators to interconnect > >their islands on VoIP. > > ENUM and VoIP have been joined at the hip since its > inception. We've always > known this. As VoIP takes off like a rocket the need to > interconnect the > islands increases exponentially. > > > > >There a really two groups: one is trying to hide the > end-user information > >by not disclosing the URIs to the public (I call them > the NGN walled gardens) > >and the others which want to disclose the URIs (the > zero termination cost > >club), > >and they would like to go into e164.arpa, but do not > get delegations in > >their country. > >These guys look for a (temporary, unregulated=quick) > solution beside > >e164.arpa, but > >will be at least not lost forever for e164.arpa (at > least for some time). > > > >Here at VON Europe a group of UK ITSPs (ITSPA) is > considering such a thing on > >an European scale, linking all European virtual VoIP > providers together > >with iENUM. > > humm and as you know a group of Asia-Pac CCTLD > operators are putting > together thieir own ENUM Engineering group > > http://www.apenum.org > > > > >BTW, Henry said clearly at the the VON Europe that he > consideres > >implementations > >not giving out URIs to the end-user not as VoIP. > > Dr. Sinnreich, as usual, is absolutely correct. > > > > >So IMHO there is currently a critical time period for > e164.arpa. If e164.arpa > >is not implemented very soon in a wide range of > countries, it will be dead. > >One year trial in +1 is definetely too long, and this > is also important > >for Europe > >since it seems that many countries, even if the have > delegations already, > >are still > >waiting for the US. > > well you remember that +1 is a unique problem in > herding 19 nation > states together but the progress in recent months has > been substantial. The > Canadian ENUM forum is moving forward very quickly the > NANP regulators are > in ongoing discussions...etc etc. > > If North Americans would like the process to move > faster they can always > write their MP's, Senators and Congressmen ..the FCC, > The CRTC, the DoC etc > etc. I'm told they enjoy letters from constituents. > > > > >Or as James Seng said at the ENUM Workshop in Brunei: > >"The biggest problem in ENUM currently is: > >-Those who want to do trials do not get delegations. > >-Those who get delegations do not know what to do with it." > > > >And I can even add to this: time for trials is over, > or it is game over > >(TILT). > > Right ..It works. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology > Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 > 703.593.2683, Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Fri, 11 Jun 2004 11:56:50 -0400 From: Andrew Newton Date: Fri, 11 Jun 2004 11:56:50 -0400 To: Richard Shockey Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: <9F15D98A-BBBD-11D8-A056-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 11, 2004, at 10:23 AM, Richard Shockey wrote: i would prefer EPP-e164 to be @ PROVREG instead. discussion maybe, charter, no. PROVRED is already shut down. Its seems appropriate to review the application specifics here but to your point there has unfortunately has not been much discussion on Scott's excellent draft. I agree. PROVREG is no more, and it seems silly to start a new WG just for this. EPP-e164 should be done in the ENUM working group. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 11 Jun 2004 12:11:18 -0400 From: Richard Shockey Date: Fri, 11 Jun 2004 12:11:18 -0400 To: "Lind, Steven D, ALABS" Message-ID: <6.1.0.6.2.20040611115202.03d58ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 11:27 AM 6/11/2004, Lind, Steven D, ALABS wrote: Richard S., As to your proposed agenda item 1, I believe that the direct should be: 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? Excellent description... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Fri, 11 Jun 2004 12:42:18 -0400 From: Allison Mankin Date: Fri, 11 Jun 2004 12:42:18 -0400 To: enum at ietf.org Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <9F15D98A-BBBD-11D8-A056-000A95B3BA44@hxr.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On the epp-e164 point, even before provreg was closed, the model preferred was for applications of EPP to be produced by their WGs rather than by provreg, if possible. ENUM adopted the epp-e164 document as a WG item some time ago, and it is quite right for the group to give it a thorough expert discussion now. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@sidn.nl Fri, 11 Jun 2004 13:03:15 -0400 From: Jaap Akkerhuis Date: Fri, 11 Jun 2004 13:03:15 -0400 To: Andrew Newton Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <9F15D98A-BBBD-11D8-A056-000A95B3BA44@hxr.us> Message-ID: <200406111654.i5BGstPN093218@bartok.sidn.nl> MIME-Version: 1.0 Content-Type: text/plain Status: R I agree. PROVREG is no more, and it seems silly to start a new WG just for this. EPP-e164 should be done in the ENUM working group. Agreed. However, the mailing list is still open. So if you want to comments from the origional crowd, you might post a pointer there to point at the discussion at the enum list. jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Fri, 11 Jun 2004 13:19:12 -0400 From: James Seng Date: Fri, 11 Jun 2004 13:19:12 -0400 To: Andrew Newton Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: <40C9E6FB.1020900@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R as a matter of curiousity, anyone interested to implement epp-e164? please rise your hand if you are. on a non-related topic, there is something that has been on my mind for a while. the original vision where enum is allocated to the end users doesn't seem to hold true anymore. in all our discussion of numbering plans, enum is more likely to be allocated like IP address by blocks of numbers (if that makes sense). there are also talks about not delegating to the end-user (or even service provider) so that we can preserve the numbering plans. -James Seng Andrew Newton wrote: On Jun 11, 2004, at 10:23 AM, Richard Shockey wrote: i would prefer EPP-e164 to be @ PROVREG instead. discussion maybe, charter, no. PROVRED is already shut down. Its seems appropriate to review the application specifics here but to your point there has unfortunately has not been much discussion on Scott's excellent draft. I agree. PROVREG is no more, and it seems silly to start a new WG just for this. EPP-e164 should be done in the ENUM working group. -andy _______________________________________________ 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 Fri, 11 Jun 2004 13:49:20 -0400 From: "Pfautz, Penn L, ALABS" Date: Fri, 11 Jun 2004 13:49:20 -0400 To: "James Seng" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETFSan Diego etc Message-ID: <34DA635B184A644DA4588E260EC0A25A075D1E09@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James: While I think that public vs carrier enum is a reasonable topic for discussion (and one which ought be settled one way or another), I believe that number portability will prevent keeping number blocks together. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of James Seng Sent: Friday, June 11, 2004 1:08 PM To: Andrew Newton Cc: enum at ietf.org; Richard Shockey Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSan Diego etc as a matter of curiousity, anyone interested to implement epp-e164? please rise your hand if you are. on a non-related topic, there is something that has been on my mind for a while. the original vision where enum is allocated to the end users doesn't seem to hold true anymore. in all our discussion of numbering plans, enum is more likely to be allocated like IP address by blocks of numbers (if that makes sense). there are also talks about not delegating to the end-user (or even service provider) so that we can preserve the numbering plans. -James Seng Andrew Newton wrote: > > On Jun 11, 2004, at 10:23 AM, Richard Shockey wrote: > >>> i would prefer EPP-e164 to be @ PROVREG instead. discussion maybe, >>> charter, >>> no. >> >> >> PROVRED is already shut down. Its seems appropriate to review the >> application specifics here but to your point there has unfortunately >> has not been much discussion on Scott's excellent draft. >> > > I agree. PROVREG is no more, and it seems silly to start a new WG just > for this. EPP-e164 should be done in the ENUM working group. > > -andy > > > _______________________________________________ > 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 shollenbeck@verisign.com Fri, 11 Jun 2004 13:51:02 -0400 From: "Hollenbeck, Scott" Date: Fri, 11 Jun 2004 13:51:02 -0400 To: "'enum at ietf.org> Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > as a matter of curiousity, anyone interested to implement epp-e164? > please rise your hand if you are. It's a distinct possibility that my employer will be interested in implementing and deploying the extension. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From sdlind@att.com Fri, 11 Jun 2004 14:23:50 -0400 From: "Lind, Steven D, ALABS" Date: Fri, 11 Jun 2004 14:23:50 -0400 To: "James Seng" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETFSan Diego etc Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R You might want to look at the ENUM Forum's document 6000_1_0, particularly section 11.10, that talks about the use of EPP. Steve ------------------------------------------------------------------------ -------- 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 > James Seng > Sent: Friday, June 11, 2004 1:08 PM > To: Andrew Newton > Cc: enum at ietf.org; Richard Shockey > Subject: Re: AW: [Enum] Please start thinking about agenda items for > IETFSan Diego etc > > > as a matter of curiousity, anyone interested to implement epp-e164? > please rise your hand if you are. > [SNIP] > -James Seng > > Andrew Newton wrote: > > > > > On Jun 11, 2004, at 10:23 AM, Richard Shockey wrote: > > > >>> i would prefer EPP-e164 to be @ PROVREG instead. > discussion maybe, > >>> charter, > >>> no. > >> > >> > >> PROVRED is already shut down. Its seems appropriate to review the > >> application specifics here but to your point there has > unfortunately > >> has not been much discussion on Scott's excellent draft. > >> > > > > I agree. PROVREG is no more, and it seems silly to start a > new WG just > > for this. EPP-e164 should be done in the ENUM working group. > > > > -andy > > > > > > _______________________________________________ > > 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@shockey.us Fri, 11 Jun 2004 14:23:52 -0400 From: Richard Shockey Date: Fri, 11 Jun 2004 14:23:52 -0400 To: "Hollenbeck, Scott" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <6.1.0.6.2.20040611141202.03efb3c8@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 01:41 PM 6/11/2004, Hollenbeck, Scott wrote: > as a matter of curiousity, anyone interested to implement epp-e164? > please rise your hand if you are. It's a distinct possibility that my employer will be interested in implementing and deploying the extension. fancy that :-) Make that 2. Though for several reasons the possibility of a SOAP binding could be explored. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@eunet.at Fri, 11 Jun 2004 17:01:57 -0400 From: Michael Haberler Date: Fri, 11 Jun 2004 17:01:57 -0400 To: "Hollenbeck, Scott" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <6.1.0.6.2.20040611223311.0315eec0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R Scott, reading your latest draft - do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? I've been working on the "thin Tier1" (NS delegations only) assumption so far. What has changed - do other people think collapsing these roles should be done as well? -Michael At 19:41 11.06.2004, Hollenbeck, Scott wrote: > as a matter of curiousity, anyone interested to implement epp-e164? > please rise your hand if you are. It's a distinct possibility that my employer will be interested in implementing and deploying the extension. -Scott- _______________________________________________ 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 ag@ag-projects.com Fri, 11 Jun 2004 17:53:10 -0400 From: Adrian Georgescu Date: Fri, 11 Jun 2004 17:53:10 -0400 To: Michael Haberler Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <30048EBD-BBF0-11D8-A64C-000A95C7765A@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: R As an ENUM product exhibitor at VON I can describe the interest showed about ENUM this week in London as seen from a Tier 2 provider. - Vendors showed genuine interest in integrating ENUM into their soft-switch solutions. Alcatel, Mitel, Siemens and other "small" players kept on returning for more information at the stand - VoIP providers asked for a tool to bypass PSTN when interconnecting 1234 at domainA.com with 1234 at domainB.com - BT and CW asked plenty of good questions, the subject is surely on their agenda - Leaflets about the first ENUM Plug-test taking place this November at ETSI ran quickly of the shelf (about 150 leaflets) A question which popped up often was whether I could also provide the numbers. So a combination of both Tier1 - Tier2 would surely have success in having ENUM deployed at a faster pace. Adrian On Jun 11, 2004, at 10:39 PM, Michael Haberler wrote: Scott, reading your latest draft - do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? I've been working on the "thin Tier1" (NS delegations only) assumption so far. What has changed - do other people think collapsing these roles should be done as well? -Michael At 19:41 11.06.2004, Hollenbeck, Scott wrote: > as a matter of curiousity, anyone interested to implement epp-e164? > please rise your hand if you are. It's a distinct possibility that my employer will be interested in implementing and deploying the extension. -Scott- _______________________________________________ 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 Sat, 12 Jun 2004 05:49:48 -0400 From: "Stastny Richard" Date: Sat, 12 Jun 2004 05:49:48 -0400 To: "Lind, Steven D, ALABS" Subject: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162233E6A@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Steve wrote: >As to your proposed agenda item 1, I believe that the direct should be: >1a: What are the issues/problems that need to be addressed? >1b: What are the reasons that "Public" ENUM can't solve them? >I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the >"Carrier" ENUM activities on that side of the pond. You are correct insofar that your "European colleagues" are more involved in "Carrier" (infrastructure, operator) ENUM activities, because ETSI is trying to write a TS on this issue. Sorry for answering a bit late, but I was yesterday at a meeting on this issue hosted by a Telco operator, which implies that one is incommunicado Internet-wise ;-) A short recap of the status: On one side you have User ENUM, which means this is End-user to End-user on the Internet. This implies that the calling user has direct access to the data in the DNS and also can do something with the retrieved data. It also implies that the called user has direct or indirect managing access to the data in the DNS, especially he is provided by his VoIP SP with a public accessible URI. It also means that you may use the information provided in DNS for establishing communication, but if you know the URI you also be able to establish the communication without using ENUM. ENUM is only necessary to establish communication form the PSTN because you cannot enter a URI. It also implies that there is zero termination charge to reach the called party. User ENUM should be implemented in e164.arpa, but could also be implemented in other trees. If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem. On the other side you have operator ENUM: Operator ENUM is used to route calls between operators - as the name implies, and NOT end-user. So operator ENUM is all about linking controlled VoIP islands together. Other buzzword coming into my mind is walled-garden, termination charges, hiding of end-user information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS routing etc.. User ENUM and operator ENUM are orthogonal to each other regarding opt-in numbers, because operator ENUM can really be considered as part ot the PSTN. For opt-in ENUM entries, one looks first in User ENUM, and if no entry is found, he looks in a (or more) Operator ENUM trees, and finally as a last resort he dumps the call to the "real" PSTN. Done correctly, he should find the information in operator ENUM finally always, especially if no conventional PSTN exists in 5-10 years. On hack in this is the now created ENUM-enabled number ranges which can only be resolved in User ENUM. For operator ENUM the same applies as for User ENUM: If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem (but see high-jacking below). The only difference here is that the domain name holder in this case is the operator, because there is nor opt-in from the user, which also implies that either the information is not in a public DNS, not in a public accessible DNS, or if in a public accessible DNS, the information does not disclose any "privacy" information. This means you may find in a domain related to a number e.g. +4319793321 only NAPTRs in the form e.g. sip:+4319793321 at provider.net, which is in essencey all what operator ENUM is about: finding the operator or service provider hosting the number. One word about high-jacking of numbers: in User ENUM high-jacking is an issue because the number exists on the PSTN and on the Internet, at least for opt-in numbers (not for ENUM-enabled numbers). In operator ENUM high-jacking of numbers would not be a problem, if zero-termination would apply and also if calls would only be routed to the destination network (no transit function). This means, if everybody would put in operater ENUM only the numbers he is hosting (and why should he put in other numbers, because he cannot terminate it), as said above, the whole could start out with 10 differnt trees, but merging trees would not be a problem, because there would be no "domain name disputes". There is only one problem with this: operator ENUM created by con-federations will also be used for transit routing: Take the following (virtual) example: US-cable operators aggree to use a common "private" database to route calls between numbers hosted by these cable operators directly between also privatly agreed upon IP-based Point of interconnect. All other calls will be routed to the "PSTN". Now one UK-cable operator joins the club. The easiest thing to do is to route ALL calls to +44 to this cable operator via the PoI of this UK operator. So ENUM is used to find the terminating network (for the numbers the UK operator is hosting himself, and as a transit (bypass) network for all other UK-numbers. One could call this legal high-jacking ;-) The problem only starts here of another UK operator is joining the club or if two trees are merged. To summarize: -User ENUM and operator ENUM are in principle orthogonal and may co-exists. -Starting with more than one tree in both of them is not optimal, but causes problems later when merging only if number or number-ranges are high-jacked (legally or illegally). So having a parking tree besides e164.arpa for user ENUM is NOT a problem if some minum rules are obeyed If User ENUM or Operator ENUM finally survives is not decided by ENUM, it will be decided in the battle between NGN vs Internet (or Zero termination vs Termination charges) best regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.yu@neustar.biz Sat, 12 Jun 2004 10:31:08 -0400 From: "Yu, James" Date: Sat, 12 Jun 2004 10:31:08 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] User ENUM vs Operator ENUM Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5632@stntexch01.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Status: R One example/use of carrier ENUM is to retrieve the routing number/prefix for a ported phone number. End User ENUM will not have this NAPTR RR (end user will not have the knowledge to put in the info.). As Richard mentioned, carriers use carrier ENUM for inter-carrier communication/routing (e.g., identify the MMSC for a mobile phone number or the SIP URI for receing incoming INVITEs). So carrier ENUM contains NAPTR RRs for the phone numbers served by the carriers. A carrier can put in the service info. only for the phone numbers it serves. In end user ENUM, an end user can put service info. associated with many carriers and/or non-carrier service providers (e.g., those who don't assign phone numbers to their subscribers). General public may not access NAPTR RRs in carrier ENUM. Access control can be applied to carrier ENUM to block unauthored access. Also the access can be retricted to private-IP networks if the carrier community decide so (e.g., carrier ENUM's DNS servers can only be accessed via private-IP networks such as the GRX in GSM/GPRS and the CRX that is discussed among the CDMA carriers. James -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Stastny Richard To: Lind, Steven D, ALABS ; Richard Shockey ; enum at ietf.org CC: jseng at pobox.org.sg ; mah at eunet.at ; paf at cisco.com Sent: Sat Jun 12 05:45:05 2004 Subject: [Enum] User ENUM vs Operator ENUM Steve wrote: >As to your proposed agenda item 1, I believe that the direct should be: >1a: What are the issues/problems that need to be addressed? >1b: What are the reasons that "Public" ENUM can't solve them? >I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the >"Carrier" ENUM activities on that side of the pond. You are correct insofar that your "European colleagues" are more involved in "Carrier" (infrastructure, operator) ENUM activities, because ETSI is trying to write a TS on this issue. Sorry for answering a bit late, but I was yesterday at a meeting on this issue hosted by a Telco operator, which implies that one is incommunicado Internet-wise ;-) A short recap of the status: On one side you have User ENUM, which means this is End-user to End-user on the Internet. This implies that the calling user has direct access to the data in the DNS and also can do something with the retrieved data. It also implies that the called user has direct or indirect managing access to the data in the DNS, especially he is provided by his VoIP SP with a public accessible URI. It also means that you may use the information provided in DNS for establishing communication, but if you know the URI you also be able to establish the communication without using ENUM. ENUM is only necessary to establish communication form the PSTN because you cannot enter a URI. It also implies that there is zero termination charge to reach the called party. User ENUM should be implemented in e164.arpa, but could also be implemented in other trees. If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem. On the other side you have operator ENUM: Operator ENUM is used to route calls between operators - as the name implies, and NOT end-user. So operator ENUM is all about linking controlled VoIP islands together. Other buzzword coming into my mind is walled-garden, termination charges, hiding of end-user information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS routing etc.. User ENUM and operator ENUM are orthogonal to each other regarding opt-in numbers, because operator ENUM can really be considered as part ot the PSTN. For opt-in ENUM entries, one looks first in User ENUM, and if no entry is found, he looks in a (or more) Operator ENUM trees, and finally as a last resort he dumps the call to the "real" PSTN. Done correctly, he should find the information in operator ENUM finally always, especially if no conventional PSTN exists in 5-10 years. On hack in this is the now created ENUM-enabled number ranges which can only be resolved in User ENUM. For operator ENUM the same applies as for User ENUM: If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem (but see high-jacking below). The only difference here is that the domain name holder in this case is the operator, because there is nor opt-in from the user, which also implies that either the information is not in a public DNS, not in a public accessible DNS, or if in a public accessible DNS, the information does not disclose any "privacy" information. This means you may find in a domain related to a number e.g. +4319793321 only NAPTRs in the form e.g. sip:+4319793321 at provider.net, which is in essencey all what operator ENUM is about: finding the operator or service provider hosting the number. One word about high-jacking of numbers: in User ENUM high-jacking is an issue because the number exists on the PSTN and on the Internet, at least for opt-in numbers (not for ENUM-enabled numbers). In operator ENUM high-jacking of numbers would not be a problem, if zero-termination would apply and also if calls would only be routed to the destination network (no transit function). This means, if everybody would put in operater ENUM only the numbers he is hosting (and why should he put in other numbers, because he cannot terminate it), as said above, the whole could start out with 10 differnt trees, but merging trees would not be a problem, because there would be no "domain name disputes". There is only one problem with this: operator ENUM created by con-federations will also be used for transit routing: Take the following (virtual) example: US-cable operators aggree to use a common "private" database to route calls between numbers hosted by these cable operators directly between also privatly agreed upon IP-based Point of interconnect. All other calls will be routed to the "PSTN". Now one UK-cable operator joins the club. The easiest thing to do is to route ALL calls to +44 to this cable operator via the PoI of this UK operator. So ENUM is used to find the terminating network (for the numbers the UK operator is hosting himself, and as a transit (bypass) network for all other UK-numbers. One could call this legal high-jacking ;-) The problem only starts here of another UK operator is joining the club or if two trees are merged. To summarize: -User ENUM and operator ENUM are in principle orthogonal and may co-exists. -Starting with more than one tree in both of them is not optimal, but causes problems later when merging only if number or number-ranges are high-jacked (legally or illegally). So having a parking tree besides e164.arpa for user ENUM is NOT a problem if some minum rules are obeyed If User ENUM or Operator ENUM finally survives is not decided by ENUM, it will be decided in the battle between NGN vs Internet (or Zero termination vs Termination charges) best regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sat, 12 Jun 2004 11:10:13 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sat, 12 Jun 2004 11:10:13 -0400 To: Stastny Richard Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <06CF906FE3998C4E944213062009F162233E6A@oefeg-s02.oefeg.loc> Message-ID: <0E4EFACF-BC82-11D8-8582-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, (recipients pruned - I suspect you're all on the ML :) As someone who was also in Telco-purdah and so only with Internet access today, I'm impressed with the level of discussion on the ML in the last couple of days. I second//third the comments on the VON - it was hectic, and interest in ENUM or ENUM-like systems is strong. As James S. says, the issue for some of the ITCSPs (i.e. lots of people, now that the bureaucracy has processed the EU Framework so that it's finally embodied in real live forms one can fill in and send off) is that one can get PSTN number ranges, but ENUM availability is at best erratic - bizarre but true. Note - there are a LOT of small ITCSPs "out there", so ENUM for interconnect is a "slam dunk" - it's about the only realistic way to do this stuff. One of the issues that came up both at the VON and afterwards is the way that sets of SPs can form into consortia/confederations/clubs. We discussed the concept of a "three ring circus" to try to classify interoperation modes. SP clubs in the "inner ring" allow "direct" SIP connections from one member's servers to a customer of another member. One might expect an example of this to be a single Company that provides service in more than one country (but judging from the way some such companies' divisions interwork, maybe not :). The next ring is a confederation of SPs who use an "IP Point of Interconnect" for sessions between members of the club, and so expose the Contact/Gateway information for E.164 numbers to members, but not to others (or to "the public"). Note - this differs in that the calls still traverse defined gateways rather than going "direct", but ENUM is still a pretty obvious choice to identify these IP POIs to other 'Club members'. Finally, in the outermost ring, the SPs don't use ENUM so all sessions have to go via a standard SCN/PSTN interconnect - the fact that a customer is "on VoIP" is no one's business. A degenerate case is a single Operator that uses ENUM "in-house" to route their sessions, but doesn't expose this to anyone else. From outside this barrier, it's a standard SCN provider. Now... note that in the middle and outer ring, there's no full mesh to end customers, so sessions traverse defined border elements. This is (I believe) tied in to Richard's comments that Infrastructure ENUM identifies the destination network and so supports routeing the session rather than delivering the session to the end user. user ENUM, OTOH, is about selecting between different sessions and/or delivering an end user's choice of URI - this is not the same as iENUM. Thus it's perfectly possible to have both user ENUM domain content and, in addition, Infrastructure ENUM domain content, and they need not be the same, even when queried from the same place. For example, I could have a user ENUM domain for +441794833000 with a NAPTR that points to tel:+441794511603. The originating end user (or the system that acts as their agent) could decide to place a call to this number, and make a request of "the Infrastructure" to set up the call. Then, the SP might look up this destination number in Infrastructure ENUM to find out how to route it, and could find that it's possible to send it to an IP POI, or even directly to a SIP URI (as this is a "VoIP customer" and the SP is part of a close-knit club that allows such direct connection). I'd expect the "CSP of record" for +441794511603 to have complete control over population of the content for the Infrastructure ENUM domain. Conversely, it's perfectly possible for there to be a user ENUM registration for this that might include content that the originating user doesn't want to use in this case; nevertheless, it's still under the control of the customer who is provided service via this E.164 number - NOT their SP. In short, whilst split horizon will almost certainly be useful in the three-ring circus of SP clubs, it's very tricky to use one tree for both user *and* Infrastructure ENUM as there may be two sets of data for the same ENUM domain (even from the same querying node's perspective). One last joker in the pack: It's possible/probable that the Infrastructure ENUM content includes Routing numbers. Not only are these of no earthy use to an End user as they can't place a call using them, they may not be much use for every SP either, even if they're exposed to all Operators. For example, a RN is often not usable outside a particular country. Thus it's important that such entries include the "phone context" as well, so that processing at an originating SP is easier - it must be given enough information to know that it can't use this entry directly, but needs to find a transit that can. ... and with that, back to your normal service (and back to the BCP for me). all the best, Lawrence On 12 Jun 2004, at 10:45, Stastny Richard wrote: A short recap of the status: On one side you have User ENUM, which means this is End-user to End-user on the Internet. This implies that the calling user has direct access to the data in the DNS and also can do something with the retrieved data. It also implies that the called user has direct or indirect managing access to the data in the DNS, especially he is provided by his VoIP SP with a public accessible URI. It also means that you may use the information provided in DNS for establishing communication, but if you know the URI you also be able to establish the communication without using ENUM. ENUM is only necessary to establish communication form the PSTN because you cannot enter a URI. It also implies that there is zero termination charge to reach the called party. User ENUM should be implemented in e164.arpa, but could also be implemented in other trees. If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem. On the other side you have operator ENUM: Operator ENUM is used to route calls between operators - as the name implies, and NOT end-user. So operator ENUM is all about linking controlled VoIP islands together. Other buzzword coming into my mind is walled-garden, termination charges, hiding of end-user information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS routing etc.. User ENUM and operator ENUM are orthogonal to each other regarding opt-in numbers, because operator ENUM can really be considered as part ot the PSTN. For opt-in ENUM entries, one looks first in User ENUM, and if no entry is found, he looks in a (or more) Operator ENUM trees, and finally as a last resort he dumps the call to the "real" PSTN. Done correctly, he should find the information in operator ENUM finally always, especially if no conventional PSTN exists in 5-10 years. On hack in this is the now created ENUM-enabled number ranges which can only be resolved in User ENUM. For operator ENUM the same applies as for User ENUM: If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem (but see high-jacking below). The only difference here is that the domain name holder in this case is the operator, because there is nor opt-in from the user, which also implies that either the information is not in a public DNS, not in a public accessible DNS, or if in a public accessible DNS, the information does not disclose any "privacy" information. This means you may find in a domain related to a number e.g. +4319793321 only NAPTRs in the form e.g. sip:+4319793321 at provider.net, which is in essencey all what operator ENUM is about: finding the operator or service provider hosting the number. One word about high-jacking of numbers: in User ENUM high-jacking is an issue because the number exists on the PSTN and on the Internet, at least for opt-in numbers (not for ENUM-enabled numbers). In operator ENUM high-jacking of numbers would not be a problem, if zero-termination would apply and also if calls would only be routed to the destination network (no transit function). This means, if everybody would put in operater ENUM only the numbers he is hosting (and why should he put in other numbers, because he cannot terminate it), as said above, the whole could start out with 10 differnt trees, but merging trees would not be a problem, because there would be no "domain name disputes". There is only one problem with this: operator ENUM created by con-federations will also be used for transit routing: Take the following (virtual) example: US-cable operators aggree to use a common "private" database to route calls between numbers hosted by these cable operators directly between also privatly agreed upon IP-based Point of interconnect. All other calls will be routed to the "PSTN". Now one UK-cable operator joins the club. The easiest thing to do is to route ALL calls to +44 to this cable operator via the PoI of this UK operator. So ENUM is used to find the terminating network (for the numbers the UK operator is hosting himself, and as a transit (bypass) network for all other UK-numbers. One could call this legal high-jacking ;-) The problem only starts here of another UK operator is joining the club or if two trees are merged. To summarize: -User ENUM and operator ENUM are in principle orthogonal and may co-exists. -Starting with more than one tree in both of them is not optimal, but causes problems later when merging only if number or number-ranges are high-jacked (legally or illegally). So having a parking tree besides e164.arpa for user ENUM is NOT a problem if some minum rules are obeyed If User ENUM or Operator ENUM finally survives is not decided by ENUM, it will be decided in the battle between NGN vs Internet (or Zero termination vs Termination charges) best regards 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 Richard.Stastny@oefeg.at Sat, 12 Jun 2004 11:59:11 -0400 From: "Stastny Richard" Date: Sat, 12 Jun 2004 11:59:11 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162233E6D@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >As someone who was also in Telco-purdah and so only with Internet >access today, >I'm impressed with the level of discussion on the ML in the last couple >of days. Me too, so the issue seems to get more interest then earlier, and this may also give an indication that a BoF at the next IETF is useful. Before somebody starts asking what this mysterios meeting at BT was, it was a mini ETSI TISPAN WG4 meeting scheduled conveniently after the VON and dedicated to forward the ETSI draft on infrastructure ENUM. We did good progress in discussion, caused also by the fact that it was a small but top-class group, consiting of Lawrence, Tony Holmes, Marco Bernardi and Paul Rosbotham. One item I can offer for the BoF is to present the status of the discussion and the document in ETSI on the IETF. Lawrence and James added nicely what I missed in my first e-mail, but one item is still missing that was already discussed in the last ETSI Meeting in Sophia Antipolis, also mention at the VON in Mike Pluke's presentation on UCI and Personal User Agents, and was again discussed yesterday. This issue is of importance for the ENUM WG regarding "enumservices" and is also related somehow to sipping. It is for importance also for User ENUM, but may even be more important for Infrastructure ENUM. iENUM is about information hiding: hinding internal structures, hiding personal information and also hiding services available. So a negotiation is necessary. on the other hand, as already pointed out, the most important infromation in iENUM is the operator, which means that in principle only one NAPTR containing e.g. a SIP or h323 URI e.g. sip:\\1 at prov.net. The enumservice to be used is the already proposed and discussed service resolution service (srs), which indicates the fact that the final communcation method to be used is to be negotiated by the personal user agents. regards Richard -----UrsprĂngliche Nachricht----- Von: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] Gesendet: Sa 12.06.2004 17:06 An: Stastny Richard Cc: enum at ietf.org Betreff: Re: [Enum] User ENUM vs Operator ENUM Hi Folks, (recipients pruned - I suspect you're all on the ML :) As someone who was also in Telco-purdah and so only with Internet access today, I'm impressed with the level of discussion on the ML in the last couple of days. I second//third the comments on the VON - it was hectic, and interest in ENUM or ENUM-like systems is strong. As James S. says, the issue for some of the ITCSPs (i.e. lots of people, now that the bureaucracy has processed the EU Framework so that it's finally embodied in real live forms one can fill in and send off) is that one can get PSTN number ranges, but ENUM availability is at best erratic - bizarre but true. Note - there are a LOT of small ITCSPs "out there", so ENUM for interconnect is a "slam dunk" - it's about the only realistic way to do this stuff. One of the issues that came up both at the VON and afterwards is the way that sets of SPs can form into consortia/confederations/clubs. We discussed the concept of a "three ring circus" to try to classify interoperation modes. SP clubs in the "inner ring" allow "direct" SIP connections from one member's servers to a customer of another member. One might expect an example of this to be a single Company that provides service in more than one country (but judging from the way some such companies' divisions interwork, maybe not :). The next ring is a confederation of SPs who use an "IP Point of Interconnect" for sessions between members of the club, and so expose the Contact/Gateway information for E.164 numbers to members, but not to others (or to "the public"). Note - this differs in that the calls still traverse defined gateways rather than going "direct", but ENUM is still a pretty obvious choice to identify these IP POIs to other 'Club members'. Finally, in the outermost ring, the SPs don't use ENUM so all sessions have to go via a standard SCN/PSTN interconnect - the fact that a customer is "on VoIP" is no one's business. A degenerate case is a single Operator that uses ENUM "in-house" to route their sessions, but doesn't expose this to anyone else. From outside this barrier, it's a standard SCN provider. Now... note that in the middle and outer ring, there's no full mesh to end customers, so sessions traverse defined border elements. This is (I believe) tied in to Richard's comments that Infrastructure ENUM identifies the destination network and so supports routeing the session rather than delivering the session to the end user. user ENUM, OTOH, is about selecting between different sessions and/or delivering an end user's choice of URI - this is not the same as iENUM. Thus it's perfectly possible to have both user ENUM domain content and, in addition, Infrastructure ENUM domain content, and they need not be the same, even when queried from the same place. For example, I could have a user ENUM domain for +441794833000 with a NAPTR that points to tel:+441794511603. The originating end user (or the system that acts as their agent) could decide to place a call to this number, and make a request of "the Infrastructure" to set up the call. Then, the SP might look up this destination number in Infrastructure ENUM to find out how to route it, and could find that it's possible to send it to an IP POI, or even directly to a SIP URI (as this is a "VoIP customer" and the SP is part of a close-knit club that allows such direct connection). I'd expect the "CSP of record" for +441794511603 to have complete control over population of the content for the Infrastructure ENUM domain. Conversely, it's perfectly possible for there to be a user ENUM registration for this that might include content that the originating user doesn't want to use in this case; nevertheless, it's still under the control of the customer who is provided service via this E.164 number - NOT their SP. In short, whilst split horizon will almost certainly be useful in the three-ring circus of SP clubs, it's very tricky to use one tree for both user *and* Infrastructure ENUM as there may be two sets of data for the same ENUM domain (even from the same querying node's perspective). One last joker in the pack: It's possible/probable that the Infrastructure ENUM content includes Routing numbers. Not only are these of no earthy use to an End user as they can't place a call using them, they may not be much use for every SP either, even if they're exposed to all Operators. For example, a RN is often not usable outside a particular country. Thus it's important that such entries include the "phone context" as well, so that processing at an originating SP is easier - it must be given enough information to know that it can't use this entry directly, but needs to find a transit that can. ... and with that, back to your normal service (and back to the BCP for me). all the best, Lawrence On 12 Jun 2004, at 10:45, Stastny Richard wrote: > A short recap of the status: > > On one side you have User ENUM, which means this is End-user to > End-user on the > Internet. This implies that the calling user has direct access to the > data in the DNS and > also can do something with the retrieved data. It also implies that > the called user > has direct or indirect managing access to the data in the DNS, > especially he is provided > by his VoIP SP with a public accessible URI. It also means that you > may use the information > provided in DNS for establishing communication, but if you know the > URI you also > be able to establish the communication without using ENUM. ENUM is > only necessary > to establish communication form the PSTN because you cannot enter a > URI. It also > implies that there is zero termination charge to reach the called > party. User ENUM > should be implemented in e164.arpa, but could also be implemented in > other trees. > If in all trees the rule is obeyed that only the entity having the > right to use > the E.164 number in the first place is the domain name holder, a later > merging of the trees is not a problem. > > > On the other side you have operator ENUM: Operator ENUM is used to > route > calls between operators - as the name implies, and NOT end-user. So > operator > ENUM is all about linking controlled VoIP islands together. Other > buzzword coming into my > mind is walled-garden, termination charges, hiding of end-user > information, session border controllers, NGN, cable-networks, IMS, > 3GPP, MMS routing > etc.. > > User ENUM and operator ENUM are orthogonal to each other regarding > opt-in > numbers, because operator ENUM can really be considered as part ot the > PSTN. > For opt-in ENUM entries, one looks first in User ENUM, and if no entry > is > found, he looks in a (or more) Operator ENUM trees, and finally as a > last resort > he dumps the call to the "real" PSTN. Done correctly, he should find > the information > in operator ENUM finally always, especially if no conventional PSTN > exists in 5-10 years. > > On hack in this is the now created ENUM-enabled number ranges which > can only > be resolved in User ENUM. > > For operator ENUM the same applies as for User ENUM: > If in all trees the rule is obeyed that only the entity having the > right to use > the E.164 number in the first place is the domain name holder, a later > merging of the trees is not a problem (but see high-jacking below). > The only difference here is that > the domain name holder in this case is the operator, because there > is nor opt-in from the user, which also implies that either the > information > is not in a public DNS, not in a public accessible DNS, or if in a > public > accessible DNS, the information does not disclose any "privacy" > information. > > This means you may find in a domain related to a number e.g. > +4319793321 only NAPTRs in the form e.g. > sip:+4319793321 at provider.net, which is in essencey > all what operator ENUM is about: > finding the operator or service provider hosting the number. > > One word about high-jacking of numbers: in User ENUM high-jacking > is an issue because the number exists on the PSTN and on the Internet, > at least for opt-in numbers (not for ENUM-enabled numbers). > > In operator ENUM high-jacking of numbers would not be a problem, > if zero-termination would apply and also if calls would only be routed > to the destination network (no transit function). > > This means, if everybody would put in operater ENUM only the numbers > he is hosting (and why should he put in other numbers, because he > cannot > terminate it), as said above, the whole could start out with 10 > differnt trees, > but merging trees would not be a problem, because there would be > no "domain name disputes". > > There is only one problem with this: operator ENUM created by > con-federations > will also be used for transit routing: > > Take the following (virtual) example: US-cable operators aggree to use > a common "private" database to route calls between numbers hosted by > these cable operators directly between also privatly agreed upon > IP-based > Point of interconnect. All other calls will be routed to the "PSTN". > > Now one UK-cable operator joins the club. The easiest thing to do is > to route > ALL calls to +44 to this cable operator via the PoI of this UK > operator. So ENUM > is used to find the terminating network (for the numbers the UK > operator is > hosting himself, and as a transit (bypass) network for all other > UK-numbers. > One could call this legal high-jacking ;-) > > The problem only starts here of another UK operator is joining the club > or if two trees are merged. > > To summarize: > > -User ENUM and operator ENUM are in principle > orthogonal and may co-exists. > > -Starting with more than one tree in both of them is not optimal, but > causes problems later when merging only if number or number-ranges > are high-jacked (legally or illegally). So having a parking tree > besides > e164.arpa for user ENUM is NOT a problem if some minum rules > are obeyed > > If User ENUM or Operator ENUM finally survives is not decided > by ENUM, it will be decided in the battle between NGN vs Internet > (or Zero termination vs Termination charges) > > best regards > Richard > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum -- Visit our website at www.roke.co.uk Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sat, 12 Jun 2004 16:57:09 -0400 From: Richard Shockey Date: Sat, 12 Jun 2004 16:57:09 -0400 To: "Pfautz, Penn L, ALABS" Subject: [Enum] A note from your co-chair. In-Reply-To: <34DA635B184A644DA4588E260EC0A25A075D1E09@ACCLUST02EVS1.ugd.att.com> Message-ID: <6.1.0.6.2.20040611135739.039f6a98@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 01:34 PM 6/11/2004, Pfautz, Penn L, ALABS wrote: James: While I think that public vs carrier enum is a reasonable topic for discussion (and one which ought be settled one way or another), I believe that number portability will prevent keeping number blocks together. Penn Pfautz I'ts pretty obvious that there "is a pony here" and some form of BOF discussion at San Diego _may_ be warranted. I do not want to mix existing ENUM WG items with this discussion A reminder of what is required here. http://www.ietf.org/ietf/1bof-procedures.txt I'm quite prepared to go to the AD's and request BOF time but further discussion needs to be focused on what I think Steve Lind perfectly pointed out. 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? If and I emphasize _IF_ we were to request a BOF I'd certainly like to see some more support among the list that this is a "good idea" tm. Deliverables to the AD's with the request for a BOF should be at the very minimum. A. 1 paragraph "Problem Statement", B. "Why this is outside the scope of the existing ENUM charter?" C. Proposed list of presenters/topics since I'd need to gauge what size of time slot we might need. - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sun, 13 Jun 2004 07:28:37 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sun, 13 Jun 2004 07:28:37 -0400 To: enum at ietf.org Subject: [Enum] One byte good, two bytes bad? Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, Whilst editing the BCP/"Experiences" draft, I came across one issue that I don't really understand. As far as I can tell, the characters in all of the NAPTR fields are/can be within the US-ASCII equivalent range of UTF-8, EXCEPT possibly for the SED-like substitution sub-field of the RegExp field (i.e. any explicit text used to build a URI that allows UTF-8), AND possibly the Replacement field that holds a domain name in a non-final NAPTR. For all of these other fields, the characters are single-byte. Here's the question: The replacement field holds a domain - but... Does IDN support mean that this domain name could include multi-byte characters? (I think that it can, but I'm hopelessly confused on how IDN works and whether such domain names are to be expected in a NAPTR). Here's the "heads up": As a final observation, multi-byte characters in the substitution expression text can spoil your ENUM client's whole day if you have done what just about everyone has so far - assumed that it's all US-ASCII and used single byte string processing routines. I think that you might confuse the subsequent byte(s) of the UTF-8 character with a delimiter (i.e. whilst looking for "!" - 0x21). all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sun, 13 Jun 2004 08:48:12 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sun, 13 Jun 2004 08:48:12 -0400 To: enum at ietf.org Subject: [Enum] Planned Obsolescence Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, another minor point here, whilst editing the draft. RFC3761 claims that it obsoletes RFC2916. RFC2916 holds no statement that it is obsoleted by 3761. [As a side issue, I note ->in the RFC index<- that 2916 is marked as being obsoleted by 3761] Now... I seem to remember that there is an IETF process by which an RFC is formally obsoleted and/or the content of an RFC is deprecated (e.g. some IPv6 bit strings, or whatever). Question: Is it intended to formally obsolete 2916 in favour of 3761, and can I currently state that 2916 is obsolete? To put it another way, are we formally going to deprecate RFC2916 services field syntax? all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Sun, 13 Jun 2004 08:58:18 -0400 From: Jim Reid Date: Sun, 13 Jun 2004 08:58:18 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] One byte good, two bytes bad? In-Reply-To: Message-ID: <27673.1087131099@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "lwc" == Conroy, Lawrence (SMTP) writes: lwc> Does IDN support mean that this domain name could lwc> include multi-byte characters? No. The whole point of IDN is backwards compatibility with the installed base. Hostnames -- as distinct from domain names -- can only be composed from the characters A-Z, a-z, 0-9 and -. IDN uses Punycode to convert between strings written in Unicode and "legal host name" ASCII. This ensures IDN names won't upset existing web browsers, mail software and so on. You and I might get presented with a domain name of xn--qwertyuiop.co.jp but someone in Japan with an IDN-aware browser sees this name as .co.jp. Now to be pedantic -- this is an IETF list after all -- domain names in NAPTR records could contain multi-byte characters. [Not all domain names are hostnames.] But not because of IDN. The DNS protocol is 8-bit clean. And anyone is able to enter whatever names they want into the zone files they control. This would be unwise: who knows what a SIP client or server (say) might do when presented with an illegal name in a NAPTR record? And as you say multi-byte characters can make life unpleasant for anything doing regexp substitution. It might be worth writing up something on this along the lines of "non-ASCII characters in NAPTRs considered harmful". While multi-byte characters in NAPTRs shouldn't happen, it's not hard to envisage circumstances where they will, either by accident or design. They may even be useful in some cases. Another worry could be regexp processing that eats the "xn--" prefix at the start of an IDN-encoded label. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@sidn.nl Sun, 13 Jun 2004 18:33:31 -0400 From: Jaap Akkerhuis Date: Sun, 13 Jun 2004 18:33:31 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] Planned Obsolescence In-Reply-To: Message-ID: <200406132223.i5DMNfle014316@bartok.sidn.nl> MIME-Version: 1.0 Content-Type: text/plain Status: R RFC3761 claims that it obsoletes RFC2916. RFC2916 holds no statement that it is obsoleted by 3761. Of course. RFCs never change. [As a side issue, I note ->in the RFC index<- that 2916 is marked as being obsoleted by 3761] Yep, since 3761 says so. Now... I seem to remember that there is an IETF process by which an RFC is formally obsoleted and/or the content of an RFC is deprecated (e.g. some IPv6 bit strings, or whatever). The basic IETF process is documented in RFC 2026. Question: Is it intended to formally obsolete 2916 in favour of 3761, and can I currently state that 2916 is obsolete? To put it another way, are we formally going to deprecate RFC2916 services field syntax? Basically, 2916 is replaced by 3761 (and friends). If you want to be really sure that that is the case, a new RFC can be written. That will say something like ''given that RFC 3761 obsoletes 2916, move the classification of 2916 to historic''. jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Sun, 13 Jun 2004 18:33:31 -0400 From: "Hollenbeck, Scott" Date: Sun, 13 Jun 2004 18:33:31 -0400 To: "'Michael Haberler'" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF0367745E@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I can't speak to the service model to be implemented by VeriSign other than noting that the protocol currently supports both delegation-only and NAPTR provisioning modes. The delegation stuff is in the protocol documents developed by the provreg WG. NAPTR provisioning is in the enum WG document. A registry can support one or both modes as appropriate. -Scott- > -----Original Message----- > From: Michael Haberler [mailto:mah at eunet.at] > Sent: Friday, June 11, 2004 4:40 PM > To: Hollenbeck, Scott; 'enum at ietf.org' > Cc: schisch at nic.at; axelm at nic.at; lendl at nic.at; mib at nic.at; > kurt Reichinger > Subject: RE: AW: [Enum] Please start thinking about agenda > items for IETF San Diego etc > > > Scott, > reading your latest draft - > do I understand this correctly that you plan to run service > which combines > delegation and NAPTR hosting (= Tier1 and Tier2)? > I've been working on the "thin Tier1" (NS delegations only) > assumption so far. > What has changed - do other people think collapsing these > roles should be > done as well? > -Michael > At 19:41 11.06.2004, Hollenbeck, Scott wrote: > > > as a matter of curiousity, anyone interested to implement > epp-e164? > > > please rise your hand if you are. > > > >It's a distinct possibility that my employer will be interested in > >implementing and deploying the extension. > > > >-Scott- > > > >_______________________________________________ > >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 jseng@pobox.org.sg Mon, 14 Jun 2004 01:41:26 -0400 From: James Seng Date: Mon, 14 Jun 2004 01:41:26 -0400 To: "Yu, James" Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <4F29BE4689992A4B994A440C3EC924DB012D5632@stntexch01.cis.neustar.com> Message-ID: <40CD3916.30805@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R yes, i seeing trends that people wants to restrict their enum dns to only certain parties whom they have established relationship. we can debate whether that is a good thing or not, but suppose they want to, i am not sure we can do it using enum/dns at all... james Yu, James wrote: One example/use of carrier ENUM is to retrieve the routing number/prefix for a ported phone number. End User ENUM will not have this NAPTR RR (end user will not have the knowledge to put in the info.). As Richard mentioned, carriers use carrier ENUM for inter-carrier communication/routing (e.g., identify the MMSC for a mobile phone number or the SIP URI for receing incoming INVITEs). So carrier ENUM contains NAPTR RRs for the phone numbers served by the carriers. A carrier can put in the service info. only for the phone numbers it serves. In end user ENUM, an end user can put service info. associated with many carriers and/or non-carrier service providers (e.g., those who don't assign phone numbers to their subscribers). General public may not access NAPTR RRs in carrier ENUM. Access control can be applied to carrier ENUM to block unauthored access. Also the access can be retricted to private-IP networks if the carrier community decide so (e.g., carrier ENUM's DNS servers can only be accessed via private-IP networks such as the GRX in GSM/GPRS and the CRX that is discussed among the CDMA carriers. James -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Stastny Richard To: Lind, Steven D, ALABS ; Richard Shockey ; enum at ietf.org CC: jseng at pobox.org.sg ; mah at eunet.at ; paf at cisco.com Sent: Sat Jun 12 05:45:05 2004 Subject: [Enum] User ENUM vs Operator ENUM Steve wrote: As to your proposed agenda item 1, I believe that the direct should be: 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? I've never gotten any answers on those questions from my European colleagues that seem to be more involved in the >"Carrier" ENUM activities on that side of the pond. You are correct insofar that your "European colleagues" are more involved in "Carrier" (infrastructure, operator) ENUM activities, because ETSI is trying to write a TS on this issue. Sorry for answering a bit late, but I was yesterday at a meeting on this issue hosted by a Telco operator, which implies that one is incommunicado Internet-wise ;-) A short recap of the status: On one side you have User ENUM, which means this is End-user to End-user on the Internet. This implies that the calling user has direct access to the data in the DNS and also can do something with the retrieved data. It also implies that the called user has direct or indirect managing access to the data in the DNS, especially he is provided by his VoIP SP with a public accessible URI. It also means that you may use the information provided in DNS for establishing communication, but if you know the URI you also be able to establish the communication without using ENUM. ENUM is only necessary to establish communication form the PSTN because you cannot enter a URI. It also implies that there is zero termination charge to reach the called party. User ENUM should be implemented in e164.arpa, but could also be implemented in other trees. If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem. On the other side you have operator ENUM: Operator ENUM is used to route calls between operators - as the name implies, and NOT end-user. So operator ENUM is all about linking controlled VoIP islands together. Other buzzword coming into my mind is walled-garden, termination charges, hiding of end-user information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS routing etc.. User ENUM and operator ENUM are orthogonal to each other regarding opt-in numbers, because operator ENUM can really be considered as part ot the PSTN. For opt-in ENUM entries, one looks first in User ENUM, and if no entry is found, he looks in a (or more) Operator ENUM trees, and finally as a last resort he dumps the call to the "real" PSTN. Done correctly, he should find the information in operator ENUM finally always, especially if no conventional PSTN exists in 5-10 years. On hack in this is the now created ENUM-enabled number ranges which can only be resolved in User ENUM. For operator ENUM the same applies as for User ENUM: If in all trees the rule is obeyed that only the entity having the right to use the E.164 number in the first place is the domain name holder, a later merging of the trees is not a problem (but see high-jacking below). The only difference here is that the domain name holder in this case is the operator, because there is nor opt-in from the user, which also implies that either the information is not in a public DNS, not in a public accessible DNS, or if in a public accessible DNS, the information does not disclose any "privacy" information. This means you may find in a domain related to a number e.g. +4319793321 only NAPTRs in the form e.g. sip:+4319793321 at provider.net, which is in essencey all what operator ENUM is about: finding the operator or service provider hosting the number. One word about high-jacking of numbers: in User ENUM high-jacking is an issue because the number exists on the PSTN and on the Internet, at least for opt-in numbers (not for ENUM-enabled numbers). In operator ENUM high-jacking of numbers would not be a problem, if zero-termination would apply and also if calls would only be routed to the destination network (no transit function). This means, if everybody would put in operater ENUM only the numbers he is hosting (and why should he put in other numbers, because he cannot terminate it), as said above, the whole could start out with 10 differnt trees, but merging trees would not be a problem, because there would be no "domain name disputes". There is only one problem with this: operator ENUM created by con-federations will also be used for transit routing: Take the following (virtual) example: US-cable operators aggree to use a common "private" database to route calls between numbers hosted by these cable operators directly between also privatly agreed upon IP-based Point of interconnect. All other calls will be routed to the "PSTN". Now one UK-cable operator joins the club. The easiest thing to do is to route ALL calls to +44 to this cable operator via the PoI of this UK operator. So ENUM is used to find the terminating network (for the numbers the UK operator is hosting himself, and as a transit (bypass) network for all other UK-numbers. One could call this legal high-jacking ;-) The problem only starts here of another UK operator is joining the club or if two trees are merged. To summarize: -User ENUM and operator ENUM are in principle orthogonal and may co-exists. -Starting with more than one tree in both of them is not optimal, but causes problems later when merging only if number or number-ranges are high-jacked (legally or illegally). So having a parking tree besides e164.arpa for user ENUM is NOT a problem if some minum rules are obeyed If User ENUM or Operator ENUM finally survives is not decided by ENUM, it will be decided in the battle between NGN vs Internet (or Zero termination vs Termination charges) best regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Mon, 14 Jun 2004 01:46:56 -0400 From: James Seng Date: Mon, 14 Jun 2004 01:46:56 -0400 To: Jaap Akkerhuis Subject: Re: [Enum] Planned Obsolescence In-Reply-To: <200406132223.i5DMNfle014316@bartok.sidn.nl> Message-ID: <40CD3A58.50602@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R i still believe it is worthwhile to write a 'flagday' rfc to formally depreciate rfc2916 and move on to rfc 3761. james Jaap Akkerhuis wrote: RFC3761 claims that it obsoletes RFC2916. RFC2916 holds no statement that it is obsoleted by 3761. Of course. RFCs never change. [As a side issue, I note ->in the RFC index<- that 2916 is marked as being obsoleted by 3761] Yep, since 3761 says so. Now... I seem to remember that there is an IETF process by which an RFC is formally obsoleted and/or the content of an RFC is deprecated (e.g. some IPv6 bit strings, or whatever). The basic IETF process is documented in RFC 2026. Question: Is it intended to formally obsolete 2916 in favour of 3761, and can I currently state that 2916 is obsolete? To put it another way, are we formally going to deprecate RFC2916 services field syntax? Basically, 2916 is replaced by 3761 (and friends). If you want to be really sure that that is the case, a new RFC can be written. That will say something like ''given that RFC 3761 obsoletes 2916, move the classification of 2916 to historic''. jaap _______________________________________________ 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 Mon, 14 Jun 2004 03:32:38 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 03:32:38 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] One byte good, two bytes bad? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 13, 2004, at 13:22, Conroy, Lawrence (SMTP) wrote: Here's the question: The replacement field holds a domain - but... Does IDN support mean that this domain name could include multi-byte characters? (I think that it can, but I'm hopelessly confused on how IDN works and whether such domain names are to be expected in a NAPTR). No, the domain name in a URI always (on the protocol level, which I claim we talk about here) always include the punycode encoded domain name, i.e. ASCII only. For the rest of the URI, I claim ASCII only, but, how to internationalize a URI in general is a separate discussion which is held in the W3C and it goes under the name of IRI. Yes, there is a draft on IRI's as well. See draft-duerst-iri-08.txt Conclusion (my guess): It is "ok" to assume all bytes in the regexp is ASCII, BUT, if any multibyte stuff exists, it will be UTF-8 encoded. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Mon, 14 Jun 2004 03:34:16 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 03:34:16 -0400 To: Michael Haberler Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Mon, 14 Jun 2004 03:34:16 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 03:34:16 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: [Enum] Planned Obsolescence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 13, 2004, at 14:40, Conroy, Lawrence (SMTP) wrote: RFC2916 holds no statement that it is obsoleted by 3761. [As a side issue, I note ->in the RFC index<- that 2916 is marked as being obsoleted by 3761] That is how it is managed. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Mon, 14 Jun 2004 04:21:47 -0400 From: Adrian Georgescu Date: Mon, 14 Jun 2004 04:21:47 -0400 To: Patrik Fältström Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <97ECB280-BDDA-11D8-A64C-000A95C7765A@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Tier2 provider does the management of the records inside delegated zones (aka Registrar function) Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) 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 Mon, 14 Jun 2004 05:00:23 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 05:00:23 -0400 To: Adrian Georgescu Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <4DF344BA-BDE0-11D8-AEB0-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), the one which approve the delegation, the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) 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 ag@ag-projects.com Mon, 14 Jun 2004 05:33:01 -0400 From: Adrian Georgescu Date: Mon, 14 Jun 2004 05:33:01 -0400 To: Patrik Fältström Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <7F4E0432-BDE4-11D8-A64C-000A95C7765A@ag-projects.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), Yes it adds NS records, populating Whois etc.. the one which approve the delegation, Yes the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) 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 Mon, 14 Jun 2004 05:46:17 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 05:46:17 -0400 To: Adrian Georgescu Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 14, 2004, at 11:23, Adrian Georgescu wrote: On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), Yes it adds NS records, populating Whois etc.. the one which approve the delegation, Yes It many cases the one which add NS records is not the same as the one which approve the delegation. And these are in turn not the same as the one which run the DNS server or the one which "owns" the domain itself. Which one of these things do a Tier-1 do? the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. You didn't understand what I wrote. A registry is in the DNS world only front-ends to a registry. A registry do not delegate to a registrar, so you can not use this word for a definition for what a Tier-1 is. As I said, do _NOT_ use these terms, the definition of them is not clear. (We had this discussion on this list some months ago, when I passed a ppt slide (only one picture) with the roles I see. Then someone else sent a list in text with a good list of roles. In neither case the term "tier" was used for reasons which should be clear by now, i.e. that noone know what Tier-N is doing.) paf paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) 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 Mon, 14 Jun 2004 07:16:33 -0400 From: "Stastny Richard" Date: Mon, 14 Jun 2004 07:16:33 -0400 To: "Adrian Georgescu" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF SanDiego etc Message-ID: <06CF906FE3998C4E944213062009F162233E7F@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Adrian wrote: > Generally the Registrars are the ones hosting the zones with the > records. Technically is not mandatory of course you could outsource the > DNS management to a third-party but there is never enough money in the > chain to outsource such activity. Adrian, you are mixing up entities and role: BTW: in the ETSI document we speak about a Tier 1 Registry, a Tier 2 Nameserver provider and a Registrar. Note that the Registrar does not have a Tier attached to it. I support Patrik's view that a Registrar is really a Tier 1 function, but one could also say it is somewhere between Tier 1 and Tier 2. Now, as you say, the "Registrar entity" may perform both the Registrar role and the Tier 2 Nameserver provider role, (in case of a residential subscriber) or eg with an enterprise, the "Registrar" may only perform the registrat role and the enterprise is operating the Tier 2 Nameserver on its own. Do not mix up roles and entities. regards Richard > -----Original Message----- > From: Adrian Georgescu [mailto:ag at ag-projects.com] > Sent: Monday, June 14, 2004 11:23 AM > To: Patrik Fältström > Cc: 'enum at ietf.org' > Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF > SanDiego etc > > > On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: > > > On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: > > > >> Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers > >> (aka Registry function) > > > > Is it the one managing the DNS zone (do the technical delegation), > > Yes it adds NS records, populating Whois etc.. > > > the one which approve the delegation, > > Yes > > > the one which talk with the end-user (registrar), or... > > > >> Tier2 provider does the management of the records inside delegated > >> zones (aka Registrar function) > > > > A registrar in the DNS sense is not managing records inside delegated > > zone, but is only a front-end for the registry. I.e. a registry and > > registrar in the DNS sense is working with the same level of the DNS > > hierarchy and there is _no_ delegation between them. > > Generally the Registrars are the ones hosting the zones with the > records. Technically is not mandatory of course you could outsource the > DNS management to a third-party but there is never enough money in the > chain to outsource such activity. > > > > > paf > > > >> Adrian > >> > >> On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: > >> > >>> > >>> On Jun 11, 2004, at 22:39, Michael Haberler wrote: > >>> > >>>> do I understand this correctly that you plan to run service which > >>>> combines delegation and NAPTR hosting (= Tier1 and Tier2)? > >>> > >>> Can we please have discussions like these without using the terms > >>> "tier" as it is not well defined. Talk explicitly about the > >>> functions provided instead. > >>> > >>> (No, the ETSI documents are not good enough.) > >>> > >>> paf > >>> > >>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum at ietf.org > >>> https://www1.ietf.org/mailman/listinfo/enum > >> > > > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Mon, 14 Jun 2004 07:24:07 -0400 From: "Conroy, Lawrence (SMTP)" Date: Mon, 14 Jun 2004 07:24:07 -0400 To: Patrik Fältström Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <19AEBCF7-BDF4-11D8-AA7E-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Patrik, folks, OK, I'll bite - we always use these terms, they're quite useful, and so far it's obvious that folk mix them up. The conflation seems to be reflected in EPP-E164, and maybe in Adrian's comment. Looking in particular at the Registrar role and the wildly different role of provider of authoritative DNS service for the delegated domain; these roles MAY be combined, but they may be quite distinct. I had a retail registration relationship with a reseller who in turn had a relationship with a Registrar. For one of the domains I registered, the reseller also provides an authoritative DNS service. For others, my company provides it, or I provide it. In none of these does the Registrar provide authoritative DNS service to me. Thus I'm very uncomfortable with folk using the term Registrar and assuming that this includes the authoritative DNS servers for a delegated domain. Please don't do this. The Tier-N relationships come about because a Registry holds a franchise from some authority; this is NOT a Protocol issue but is an Administration issue. Running the DNS registry (i.e. the boxes that are tied into the DNS hierarchy up/down from the root) may be outsourced to another company, but the franchise holder has the responsibility to the franchising authority to deliver service that doesn't break the DNS. If the DNS registry is broken, it's the franchisee's fault. The franchise, in the ENUM case, is a matter for the ITU and the IAB - not for us, as it's not a protocol issue (well... it is for you, Patrik, you poor sod, but not for me :). The problem with the Tier-N roles is that they mix the administration and authority that is tied into the franchise model (e.g. Registry, Registrar, Registrant) with the technical issues of the DNS delegation and DNS "publishing" model (e.g. registry, authoritative DNS servers for delegated domain). These are NOT the same, even though they use similar terms As a final point, for ENUM, it's tempting to add a statement that, for a given administration, the DNS registry NEVER holds zone content for the domains "under" its franchise. In practice, that is the role of the Tier-(N+1) Authoritative DNS server that acts for the Registrant and their delegated domain. However, we have had a recent list discussion on special entries (e.g. NULL NAPTRs) that are not "leaf nodes", so even this statement may be too restrictive. all the best, Lawrence On 14 Jun 2004, at 10:32, Patrik Fältström wrote: On Jun 14, 2004, at 11:23, Adrian Georgescu wrote: On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), Yes it adds NS records, populating Whois etc.. the one which approve the delegation, Yes It many cases the one which add NS records is not the same as the one which approve the delegation. And these are in turn not the same as the one which run the DNS server or the one which "owns" the domain itself. Which one of these things do a Tier-1 do? the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. You didn't understand what I wrote. A registry is in the DNS world only front-ends to a registry. A registry do not delegate to a registrar, so you can not use this word for a definition for what a Tier-1 is. As I said, do _NOT_ use these terms, the definition of them is not clear. (We had this discussion on this list some months ago, when I passed a ppt slide (only one picture) with the roles I see. Then someone else sent a list in text with a good list of roles. In neither case the term "tier" was used for reasons which should be clear by now, i.e. that noone know what Tier-N is doing.) paf paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Mon, 14 Jun 2004 07:42:32 -0400 From: "Hollenbeck, Scott" Date: Mon, 14 Jun 2004 07:42:32 -0400 To: "'Conroy, Lawrence (SMTP)'" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF03677465@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > OK, I'll bite - we always use these terms, they're quite > useful, and so > far it's > obvious that folk mix them up. The conflation seems to be > reflected in > EPP-E164, > and maybe in Adrian's comment. I'm not sure where the situation is reflected in epp-164 since there's no mention of tiers, registrars, or registries in the document. It talks only about the technical aspects of provisioned data, using generic terms like "client" and "server", leaving the policy aspects out completely. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Mon, 14 Jun 2004 08:02:19 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 14 Jun 2004 08:02:19 -0400 To: "Conroy, Lawrence (SMTP)" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677425@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <0E5C7213-BDF8-11D8-AEB0-000A95B2B926@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 14, 2004, at 13:15, Conroy, Lawrence (SMTP) wrote: The problem with the Tier-N roles is that they mix the administration and authority that is tied into the franchise model (e.g. Registry, Registrar, Registrant) with the technical issues of the DNS delegation and DNS "publishing" model (e.g. registry, authoritative DNS servers for delegated domain). These are NOT the same, even though they use similar terms Bingo! In reality in ENUM, I claim we _do_ have "Tiers". But, there is not one function within one "Tier" and extremely seldom (I have never seen it, except in some cases for very high values of "N" in "Tier N") one organisation can be said "THE Tier N". In fact, many organisations normally share the responsibilities inside one layer in the ENUM delegation hierarchy. In one layer, we first of all have someone which by the parent layer can request a delegation (A). This is for me the domain name holder, or the overall administrative body for the domain. We also have someone (B) which can request delegation from the parent domain. In many cases, this is the same as (A), but not always. When the delegation is approved, we have someone running DNS (C) which have to make sure the technical delegation is made, i.e. that the correct NS records are set up in the parent zone etc. A fourth party (D), is acting on delegation requests from children. These requests come directly or indirectly via (F). This is in the DNS sense the "registry". They also create the DNS zone file (or equivalent). A fifth party (E) run the DNS servers. The roles C+D+E can be the same entity, but I have seen both (C+E) as well as (C+D) and the third role separated. A sixth party (F) is receiving the delegation requests from the children. This is from a DNS sense a registrar. A seventh party (G) is authorising the delegation requests from children. Sometimes this is done by (F), in other cases by (D) but in some cases it is a separate entity which is to be contacted either by (F) or (D). An eighth special case is the one which run services which NAPTR refer to. This is a special role which only exist for the lowest layer in the stack, regardless of if it is within the 3rd, 2nd or fourth layer. I think this is about everything I can think of now from the top of my head. And, note, I am only talking about the roles inside one (what I call) layer in the hierarchy. One layer such as "The layer which contains e164.arpa" or "the layer which is the cc delegated from E164.arpa" etc. paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ag@ag-projects.com Mon, 14 Jun 2004 09:03:26 -0400 From: Adrian Georgescu Date: Mon, 14 Jun 2004 09:03:26 -0400 To: "Stastny Richard" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF SanDiego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E7F@oefeg-s02.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Point taken. Probably with carrier ENUM and public ENUM having different meanings this naming gets even more complicated. I guess Patrick's idea to itemize roles instead of using words like TierX that overlap themselves is better. So how somebody managing NAPTR records for both public and the entreprise ENUM should be called? Adrian On Jun 14, 2004, at 12:58 PM, Stastny Richard wrote: Adrian wrote: Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. Adrian, you are mixing up entities and role: BTW: in the ETSI document we speak about a Tier 1 Registry, a Tier 2 Nameserver provider and a Registrar. Note that the Registrar does not have a Tier attached to it. I support Patrik's view that a Registrar is really a Tier 1 function, but one could also say it is somewhere between Tier 1 and Tier 2. Now, as you say, the "Registrar entity" may perform both the Registrar role and the Tier 2 Nameserver provider role, (in case of a residential subscriber) or eg with an enterprise, the "Registrar" may only perform the registrat role and the enterprise is operating the Tier 2 Nameserver on its own. Do not mix up roles and entities. regards Richard -----Original Message----- From: Adrian Georgescu [mailto:ag at ag-projects.com] Sent: Monday, June 14, 2004 11:23 AM To: Patrik Fältström Cc: 'enum at ietf.org' Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF SanDiego etc On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), Yes it adds NS records, populating Whois etc.. the one which approve the delegation, Yes the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 14 Jun 2004 14:37:32 -0400 From: "Peter Williams" Date: Mon, 14 Jun 2004 14:37:32 -0400 To: ag at ag-projects.com Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R From: Adrian Georgescu To: "Stastny Richard" CC: enum at ietf.org, Patrik Fältström Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc Date: Mon, 14 Jun 2004 14:46:54 +0200 Richard, Point taken. Probably with carrier ENUM and public ENUM having different meanings this naming gets even more complicated. I guess Patrick's idea to itemize roles instead of using words like TierX that overlap themselves is better. So how somebody managing NAPTR records for both public and the entreprise ENUM should be called? In the X.500 world, the (orthognal) schematic descriptor for the opeartional entity is "DMO" or domain management organization. A DMO can administer 1 or more MDs - each of which is either public or private. However, any MD has multiple adminsitrative (and security) regions, any one of which can be replicated as part of another (security-level compatible) MD - providing the user with the illusion that one MD supports both public name spaces and private name spaces. To the adminsitrator, the security role and domain management privileges required for the right to manage entities in each class of name space are distinct, however, and are enforced within the naming architecture (i.e. tiering class hierarchy). The fun part of this in ENUM is enforcing the sharing of distribution and security knowledge between the servers mastering adminsitrative regions (e.g. a global carrier's services in each proxy country), so they all correctly provide access points to a uniform discovery service, whilst providing per-MD security policy for users, and while conforming to the common security policy concerning backroom knowledge distribution within the provider community. In the X.500 case, the latter's protocols and operational practices are standardized: in ENUM they appear to be destined for proprietary implementation only, probably to enable the 2 main providers to keep control of their distribution channels, ensure fee arrangements etc when building out the hub and spokes, or the outsourcing business for their telco clients. Its hard to decide whether to bother specifying a common public (ie. internet) adminsitration (and security) model for ENUM. ENUM has all the properties of the Directory, PKI/VPN, and EDI worlds: in which users simply do not seek a common internet-infrastructure - they simply wish interworking standards that support hub-spoke and PTT-centered outreach infrastructures. For the latter goals, work to standardized the proprietary management practice within the industry are unlikely to get much traction, judging from ENUM's parallels. On Jun 14, 2004, at 12:58 PM, Stastny Richard wrote: Adrian wrote: Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. Adrian, you are mixing up entities and role: BTW: in the ETSI document we speak about a Tier 1 Registry, a Tier 2 Nameserver provider and a Registrar. Note that the Registrar does not have a Tier attached to it. I support Patrik's view that a Registrar is really a Tier 1 function, but one could also say it is somewhere between Tier 1 and Tier 2. Now, as you say, the "Registrar entity" may perform both the Registrar role and the Tier 2 Nameserver provider role, (in case of a residential subscriber) or eg with an enterprise, the "Registrar" may only perform the registrat role and the enterprise is operating the Tier 2 Nameserver on its own. Do not mix up roles and entities. regards Richard -----Original Message----- From: Adrian Georgescu [mailto:ag at ag-projects.com] Sent: Monday, June 14, 2004 11:23 AM To: Patrik Fältström Cc: 'enum at ietf.org' Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF SanDiego etc On Jun 14, 2004, at 10:53 AM, Patrik Fältström wrote: On Jun 14, 2004, at 10:12, Adrian Georgescu wrote: Tier 1 does delegations of domains (E164 prefixes) to Tier2 providers (aka Registry function) Is it the one managing the DNS zone (do the technical delegation), Yes it adds NS records, populating Whois etc.. the one which approve the delegation, Yes the one which talk with the end-user (registrar), or... Tier2 provider does the management of the records inside delegated zones (aka Registrar function) A registrar in the DNS sense is not managing records inside delegated zone, but is only a front-end for the registry. I.e. a registry and registrar in the DNS sense is working with the same level of the DNS hierarchy and there is _no_ delegation between them. Generally the Registrars are the ones hosting the zones with the records. Technically is not mandatory of course you could outsource the DNS management to a third-party but there is never enough money in the chain to outsource such activity. paf Adrian On Jun 14, 2004, at 9:24 AM, Patrik Fältström wrote: On Jun 11, 2004, at 22:39, Michael Haberler wrote: do I understand this correctly that you plan to run service which combines delegation and NAPTR hosting (= Tier1 and Tier2)? Can we please have discussions like these without using the terms "tier" as it is not well defined. Talk explicitly about the functions provided instead. (No, the ETSI documents are not good enough.) paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 14 Jun 2004 15:09:20 -0400 From: Jim Reid Date: Mon, 14 Jun 2004 15:09:20 -0400 To: Peter Williams Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: Message-ID: <5466.1087239926@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Peter" == Peter Williams writes: Peter> Its hard to decide whether to bother specifying a common Peter> public (ie. internet) adminsitration (and security) model Peter> for ENUM. ENUM has all the properties of the Directory, Peter> PKI/VPN, and EDI worlds: in which users simply do not seek Peter> a common internet-infrastructure - they simply wish Peter> interworking standards that support hub-spoke and Peter> PTT-centered outreach infrastructures. For the latter Peter> goals, work to standardized the proprietary management Peter> practice within the industry are unlikely to get much Peter> traction, judging from ENUM's parallels. I must be missing something. For (user or operator or enterprise) ENUM to fly, there has to be a single. consistent name space. That name space can be different depending on where you look from. Many organisations already do this with their DNS data. The technique is called split DNS. What you see for VeryBigCompany.com depends on whether you're on the public internet or on VeryBigCompany's net or even on a net for one of VeryBigCompany's business partners. In each case, there's exactly one VeryBigCompany.com name space. This may or may not have commonality with the other instances of that name space. The same model could be used for e164.arpa: eg a telco or enterprise has its own e164.arpa tree for internal use only. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shivkumar_sharma@infosys.com Tue, 15 Jun 2004 01:37:27 -0400 From: "shiv Kumar Sharma" Date: Tue, 15 Jun 2004 01:37:27 -0400 To: Subject: [Enum] unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R     Thanks, Shiv Kumar Sharma Infosys Technologies Ltd.   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Tue, 15 Jun 2004 06:37:12 -0400 From: "Conroy, Lawrence (SMTP)" Date: Tue, 15 Jun 2004 06:37:12 -0400 To: "Hollenbeck, Scott" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF03677465@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <72D79CBE-BEB7-11D8-A536-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Scott, folks, Forgive the loose comments - I really don't understand how the client and server model is embodied (and where). AFAICT, the model is: [Client] --EPP-E164---> [Server] ----> [database shared with...] [DNS Server] The Client could be embodied in a Registrant. They use EPP-E164 to tell the Server the way they want NAPTRs populated in their delegated domain. That EPP Server somehow gets the data into a form that can be used to "publish" over DNS - either writing to a shared database, or using standard DNS zone update, or file transfer, or whatever. [Email automaton, anyone?] Of course, the EPP-E164 deals only with the protocol - any program to specify the NAPTR content will be embedded in the Client. For our user ENUM implementations, the model we've used so far is for secured access to a Web service, so the Client becomes a pure https Browser, and the Server deals with the validation/sanity checking for the NAPTRs - no human gets to see the NAPTR that the web service constructs. For iENUM, the CSP who is the Registrant for some number blocks may well want to have a program to set up their multiple zone contents. They will have a potentially huge number of NAPTRs to populate in different zones, and will almost certainly have their own provisioning application (with its own internal formats) to do this. However... In this case why do they want EPP-E164 rather than sending the Zone files (or some other format) directly to their 3rd party DNS service provider, assuming that they aren't doing this themselves? Is the goal of EPP-E164 just to specify a common format of the data to be sent, along with a single application protocol to carry the data? How is this going to help a CSP who may have to convert from their own internal provisioning system formats into another to be sent over the net anyway? A more likely scenario is a CSP saying to the DNS provider "this is my format in which you will get the data - sort it out yourself". I fear I'm being stupid here, but I genuinely don't understand how to sell this concept to folk who WILL see it as yet another layer that (at best) benefits only the Server, and need some help. all the best, Lawrence ---- On 14 Jun 2004, at 12:32, Hollenbeck, Scott wrote: OK, I'll bite - we always use these terms, they're quite useful, and so far it's obvious that folk mix them up. The conflation seems to be reflected in EPP-E164, and maybe in Adrian's comment. I'm not sure where the situation is reflected in epp-164 since there's no mention of tiers, registrars, or registries in the document. It talks only about the technical aspects of provisioned data, using generic terms like "client" and "server", leaving the policy aspects out completely. -Scott- Note: https://www1.ietf.org/mailman Should we propose an EPP interface to mailman? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Tue, 15 Jun 2004 06:56:13 -0400 From: "Clive D.W. Feather" Date: Tue, 15 Jun 2004 06:56:13 -0400 To: Jim Reid Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: Message-ID: <20040615104409.GA9951@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid said: > I must be missing something. For (user or operator or enterprise) ENUM > to fly, there has to be a single. consistent name space. That name > space can be different depending on where you look from. Many > organisations already do this with their DNS data. The technique is > called split DNS. What you see for VeryBigCompany.com depends on > whether you're on the public internet or on VeryBigCompany's net or > even on a net for one of VeryBigCompany's business partners. But it's a kludge, and it won't do everything that Operator ENUM will need. > The same model could be used for e164.arpa: eg a telco or > enterprise has its own e164.arpa tree for internal use only. Why not put Operator ENUM in op.e164.arpa? Use the same layout as for public ENUM. -- 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 shollenbeck@verisign.com Tue, 15 Jun 2004 07:25:42 -0400 From: "Hollenbeck, Scott" Date: Tue, 15 Jun 2004 07:25:42 -0400 To: "'Conroy, Lawrence (SMTP)'" Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF0367753C@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > For iENUM, the CSP who is the Registrant for some number blocks may > well want to > have a program to set up their multiple zone contents. They > will have a > potentially > huge number of NAPTRs to populate in different zones, and will almost > certainly have > their own provisioning application (with its own internal formats) to > do this. > However... > > In this case why do they want EPP-E164 rather than sending the Zone > files (or some > other format) directly to their 3rd party DNS service provider, > assuming that they > aren't doing this themselves? Anyone building the zone themselves won't need to use a provisioning protocol like EPP. > Is the goal of EPP-E164 just to specify a common format of > the data to > be sent, > along with a single application protocol to carry the data? The goal is for entities that *will* be using EPP to have a facility to provision the data. It might also be useful for entities that don't have a provisioning mechanism in place -- this is one possibility that they might choose to implement. > How is this going to help a CSP who may have to convert from > their own > internal > provisioning system formats into another to be sent over the net > anyway? A more likely > scenario is a CSP saying to the DNS provider "this is my format in > which you will get > the data - sort it out yourself". In that case it might not be helpful at all. -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 15 Jun 2004 07:39:43 -0400 From: Jim Reid Date: Tue, 15 Jun 2004 07:39:43 -0400 To: "Clive D.W. Feather" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: <20040615104409.GA9951@finch-staff-1.thus.net> Message-ID: <7410.1087299252@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Clive" == Clive D W Feather writes: >> I must be missing something. For (user or operator or >> enterprise) ENUM to fly, there has to be a single. consistent >> name space. That name space can be different depending on where >> you look from. Many organisations already do this with their >> DNS data. The technique is called split DNS. What you see for >> VeryBigCompany.com depends on whether you're on the public >> internet or on VeryBigCompany's net or even on a net for one of >> VeryBigCompany's business partners. Clive> But it's a kludge, and it won't do everything that Operator Clive> ENUM will need. Please elaborate. What are the things Operator ENUM will need that can't be achieved with a private instance of e164.arpa but could be achieved with some other domain name? Just because the domain name for Operator and User ENUM could/should be the same IMO, it doesn't follow that they have to use the same infrastructure or administrative models. Yes, split DNS is a kludge. But there doesn't seem to be a better solution IMO. >> The same model could be used for e164.arpa: eg a telco or >> enterprise has its own e164.arpa tree for internal use only. Clive> Why not put Operator ENUM in op.e164.arpa? Use the same Clive> layout as for public ENUM. Suppose I'm a developer of some ENUM-aware VoIP application that talks to SIP servers. I sell this to telcos, enterprises and end users. How is the software to know which domain name to use depending on where my customers are using it today? And might use it tomorrow, which could be somewhere different... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andrzejb@nask.pl Tue, 15 Jun 2004 08:02:14 -0400 From: Andrzej Bartosiewicz Date: Tue, 15 Jun 2004 08:02:14 -0400 To: Richard Shockey Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc In-Reply-To: <06CF906FE3998C4E944213062009F162233E5C@oefeg-s02.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > Well we have so far > > 1. The ENUM operations document that needs very careful review. > > 2. Andrzej Bartosiewicz "draft-bartosiewicz-enterprise-enum-00.txt" > > 3. Scott Hollenbeck on EPP-e164 and whether this is fully baked enough to > advance . I'm disappointed to see that there has been little or no > discussion of this important work on the list. If you are interested, we have the working Registry system for ENUM domain names with EPP's adaptation described in the www.bartosiewicz.pl/draft-bartosiewicz-enum-48tld-00.txt Best, Andrzej Bartosiewicz _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.yu@neustar.biz Tue, 15 Jun 2004 09:48:35 -0400 From: "Yu, James" Date: Tue, 15 Jun 2004 09:48:35 -0400 To: "'James Seng'" Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D5645@stntexch01.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Access control is a way to limited access to the service info. in carrier ENUM if the carrier community does not want the general public to access that info. Whether and how to do it are implementation issues. This subject is certainly not one we need to discuss here. Also retrieving the service info. for a TN from Carrier ENUM does not mean the call/message/transaction processing may continue. One example is the inter-carrier Multimedia Messaging Service (MMS). Carrier ENUM can be used by the Originating Multimedia Messaging Service Center (MMSC) to retrieve the Terminating MMSC host info. (the MMSC that serves the phone number that is shown as the destination address of a to-be-delivered multimedia message). After retrieving the MMSC host info., the Originating MMSC can check if there is a business relationship with the termiating carrier. If not, it can drop the message. Carrier ENUM is no different from End User ENUM in term of DNS queries and retrieved NAPTR RRs (although Carrier ENUM may define some "enumservice" values that are not used by End User ENUM and vice versa). But the provisioning/administrative processes between the two may be different. Carriers are involved in the provisioning process in Carrier ENUM while end users typically are involved in the provisioning process in End User EUNM due to end user opt-in requirement (I heard that in some countries they plan to have the carriers provisioning End User ENUM; don't know if that should be called Carrier ENUM or End User ENUM in that case). We see interests in Carrier ENUM within the wireless community and within the VoIP community (including cable). IETF discusses technical issues. Carrier ENUM does not use any new technology. The carriers or the associations/organizations the carriers participate are the ones to address Carrier ENUM issues. The carrier community should jointly agree on one common tree to be used by Carrier ENUM. James -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: Monday, June 14, 2004 1:35 AM To: Yu, James Cc: 'richard.stastny at oefeg.at'; 'sdlind at att.com'; 'richard at shockey.us'; 'enum at ietf.org'; 'mah at eunet.at'; 'paf at cisco.com' Subject: Re: [Enum] User ENUM vs Operator ENUM yes, i seeing trends that people wants to restrict their enum dns to only certain parties whom they have established relationship. we can debate whether that is a good thing or not, but suppose they want to, i am not sure we can do it using enum/dns at all... james Yu, James wrote: > One example/use of carrier ENUM is to retrieve the routing number/prefix for > a ported phone number. End User ENUM will not have this NAPTR RR (end user > will not have the knowledge to put in the info.). > > As Richard mentioned, carriers use carrier ENUM for inter-carrier > communication/routing (e.g., identify the MMSC for a mobile phone number or > the SIP URI for receing incoming INVITEs). So carrier ENUM contains NAPTR > RRs for the phone numbers served by the carriers. A carrier can put in the > service info. only for the phone numbers it serves. In end user ENUM, an > end user can put service info. associated with many carriers and/or > non-carrier service providers (e.g., those who don't assign phone numbers to > their subscribers). > > General public may not access NAPTR RRs in carrier ENUM. Access control can > be applied to carrier ENUM to block unauthored access. Also the access can > be retricted to private-IP networks if the carrier community decide so > (e.g., carrier ENUM's DNS servers can only be accessed via private-IP > networks such as the GRX in GSM/GPRS and the CRX that is discussed among the > CDMA carriers. > > James > -------------------------- > Sent from my BlackBerry Wireless Handheld > > > -----Original Message----- > From: Stastny Richard > To: Lind, Steven D, ALABS ; Richard Shockey > ; enum at ietf.org > CC: jseng at pobox.org.sg ; mah at eunet.at ; > paf at cisco.com > Sent: Sat Jun 12 05:45:05 2004 > Subject: [Enum] User ENUM vs Operator ENUM > > Steve wrote: > > >>As to your proposed agenda item 1, I believe that the direct should be: > > >>1a: What are the issues/problems that need to be addressed? >>1b: What are the reasons that "Public" ENUM can't solve them? > > >>I've never gotten any answers on those questions from my European > > colleagues that seem to be more involved in the >"Carrier" ENUM activities > on that side of the pond. > > You are correct insofar that your "European colleagues" are more involved > in "Carrier" (infrastructure, operator) > ENUM activities, because ETSI is trying to write a TS on this issue. > > Sorry for answering a bit late, but I was yesterday at a meeting on this > issue hosted by a Telco operator, > which implies that one is incommunicado Internet-wise ;-) > > A short recap of the status: > > On one side you have User ENUM, which means this is End-user to End-user on > the > Internet. This implies that the calling user has direct access to the data > in the DNS and > also can do something with the retrieved data. It also implies that the > called user > has direct or indirect managing access to the data in the DNS, especially he > is provided > by his VoIP SP with a public accessible URI. It also means that you may use > the information > provided in DNS for establishing communication, but if you know the URI you > also > be able to establish the communication without using ENUM. ENUM is only > necessary > to establish communication form the PSTN because you cannot enter a URI. It > also > implies that there is zero termination charge to reach the called party. > User ENUM > should be implemented in e164.arpa, but could also be implemented in other > trees. > If in all trees the rule is obeyed that only the entity having the right to > use > the E.164 number in the first place is the domain name holder, a later > merging of the trees is not a problem. > > > On the other side you have operator ENUM: Operator ENUM is used to route > calls between operators - as the name implies, and NOT end-user. So operator > ENUM is all about linking controlled VoIP islands together. Other buzzword > coming into my > mind is walled-garden, termination charges, hiding of end-user > information, session border controllers, NGN, cable-networks, IMS, 3GPP, MMS > routing > etc.. > > User ENUM and operator ENUM are orthogonal to each other regarding opt-in > numbers, because operator ENUM can really be considered as part ot the PSTN. > For opt-in ENUM entries, one looks first in User ENUM, and if no entry is > found, he looks in a (or more) Operator ENUM trees, and finally as a last > resort > he dumps the call to the "real" PSTN. Done correctly, he should find the > information > in operator ENUM finally always, especially if no conventional PSTN exists > in 5-10 years. > > On hack in this is the now created ENUM-enabled number ranges which can only > be resolved in User ENUM. > > For operator ENUM the same applies as for User ENUM: > If in all trees the rule is obeyed that only the entity having the right to > use > the E.164 number in the first place is the domain name holder, a later > merging of the trees is not a problem (but see high-jacking below). > The only difference here is that > the domain name holder in this case is the operator, because there > is nor opt-in from the user, which also implies that either the information > is not in a public DNS, not in a public accessible DNS, or if in a public > accessible DNS, the information does not disclose any "privacy" information. > > This means you may find in a domain related to a number e.g. > +4319793321 only NAPTRs in the form e.g. > sip:+4319793321 at provider.net, which is in essencey > all what operator ENUM is about: > finding the operator or service provider hosting the number. > > One word about high-jacking of numbers: in User ENUM high-jacking > is an issue because the number exists on the PSTN and on the Internet, > at least for opt-in numbers (not for ENUM-enabled numbers). > > In operator ENUM high-jacking of numbers would not be a problem, > if zero-termination would apply and also if calls would only be routed > to the destination network (no transit function). > > This means, if everybody would put in operater ENUM only the numbers > he is hosting (and why should he put in other numbers, because he cannot > terminate it), as said above, the whole could start out with 10 differnt > trees, > but merging trees would not be a problem, because there would be > no "domain name disputes". > > There is only one problem with this: operator ENUM created by > con-federations > will also be used for transit routing: > > Take the following (virtual) example: US-cable operators aggree to use > a common "private" database to route calls between numbers hosted by > these cable operators directly between also privatly agreed upon IP-based > Point of interconnect. All other calls will be routed to the "PSTN". > > Now one UK-cable operator joins the club. The easiest thing to do is to > route > ALL calls to +44 to this cable operator via the PoI of this UK operator. So > ENUM > is used to find the terminating network (for the numbers the UK operator is > hosting himself, and as a transit (bypass) network for all other UK-numbers. > One could call this legal high-jacking ;-) > > The problem only starts here of another UK operator is joining the club > or if two trees are merged. > > To summarize: > > -User ENUM and operator ENUM are in principle > orthogonal and may co-exists. > > -Starting with more than one tree in both of them is not optimal, but > causes problems later when merging only if number or number-ranges > are high-jacked (legally or illegally). So having a parking tree besides > e164.arpa for user ENUM is NOT a problem if some minum rules > are obeyed > > If User ENUM or Operator ENUM finally survives is not decided > by ENUM, it will be decided in the battle between NGN vs Internet > (or Zero termination vs Termination charges) > > best regards > Richard > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Tue, 15 Jun 2004 10:07:02 -0400 From: James Seng Date: Tue, 15 Jun 2004 10:07:02 -0400 To: enum at ietf.org Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <4F29BE4689992A4B994A440C3EC924DB012D5645@stntexch01.cis.neustar.com> Message-ID: <200406152158.05353.jseng@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R On 15 June 2004 pm 21:35, Yu, James wrote: > Access control is a way to limited access to the service info. in carrier > ENUM if the carrier community does not want the general public to access > that info. Whether and how to do it are implementation issues. This > subject is certainly not one we need to discuss here. why not? ops have always been discussed in ietf. > Also retrieving the service info. for a TN from Carrier ENUM does not mean > the call/message/transaction processing may continue. of cos. but *that is* outside the scope of ENUM if we crawl higher and look at other interoperability issues. james _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 15 Jun 2004 10:09:40 -0400 From: Richard Shockey Date: Tue, 15 Jun 2004 10:09:40 -0400 To: "Clive D.W. Feather" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: Message-ID: <6.1.0.6.2.20040615095259.03f20ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 06:44 AM 6/15/2004, Clive D.W. Feather wrote: Jim Reid said: > I must be missing something. For (user or operator or enterprise) ENUM > to fly, there has to be a single. consistent name space. That name > space can be different depending on where you look from. Many > organisations already do this with their DNS data. The technique is > called split DNS. What you see for VeryBigCompany.com depends on > whether you're on the public internet or on VeryBigCompany's net or > even on a net for one of VeryBigCompany's business partners. But it's a kludge, and it won't do everything that Operator ENUM will need. > The same model could be used for e164.arpa: eg a telco or > enterprise has its own e164.arpa tree for internal use only. Why not put Operator ENUM in op.e164.arpa? Use the same layout as for public ENUM. Because carriers do not want to expose their internal routing data to the global internet. The essential distinguishing feature of public vs infrastructure ENUM is its visibality. If consumers or enterprises, for what ever reason OPT-OUT of e164.arpa , or the politics cant be fixed as in the case of +1, then we are collectively stuck with default PSTN routing indefinitely and that is not acceptable. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 15 Jun 2004 10:24:56 -0400 From: "Stastny Richard" Date: Tue, 15 Jun 2004 10:24:56 -0400 To: "Jim Reid" Subject: RE: AW: [Enum] Please start thinking about agenda items forIETFSanDiego etc Message-ID: <06CF906FE3998C4E944213062009F162443762@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R > Jim wrote: > Suppose I'm a developer of some ENUM-aware VoIP application that talks > to SIP servers. I sell this to telcos, enterprises and end users. How > is the software to know which domain name to use depending on where my > customers are using it today? And might use it tomorrow, which could > be somewhere different... > [Richard>] One hint would be to enter the root in the options ;-) more sophisticated, you could do it similar to the IX66, where you may enter the root to be used per number range. BTW, split DNS is one valid option in a specific scenario of Infrastructure ENUM where you have different entries within your network (e.g pointers to end users) and in the shared DNS, (e.g. pointer to gateways aka session border controllers). But there are other scenarios also Richard This is a message from outlook direct, so you should be able to read it;-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Tue, 15 Jun 2004 12:34:39 -0400 From: "Peter Williams" Date: Tue, 15 Jun 2004 12:34:39 -0400 To: enum at ietf.org Subject: Re: [Enum] User ENUM vs Operator ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R James, The nature of ENUM - as a telematic service - has strong parallels to EDI, and PKI/VPNs in its likely provider-centered adoption practices. As a white pages-style directory service mapping PSDN and PSTN NSAPs to names in name spaces manged by late 1980s-style name servers, it obviously has strong parallels to Steve Kille's & other's X.500 efforts (and Marshall/Einar's NADF efforts just outside of IETF) in the 1990s. In all these cases, we have experience of the operational and adoption arcs. When rescoping the WG work targets for ENUM, now, we may be able to articulate a rationale for any new work by specifically asking: so what is the consensus on expected ENUM deployment and operations, today - and compare these goals to the experience from the parallels? There is a strong tradition in certain large US companies that standards making is always about market making. The investment made to get a standard adopted requires payoff - in the form of capturing a large market, all in one go. This tradition has become more prevalent in IETF over the last 10 years! as the IETF has adapted to the business investment climate it necessarily operates in. If one structures the standards right, one can protect the future revenue stream of such a capture - by creating barrier's to entry in the operational phase. Structuring proprietary management processes abound standards adopting the provider/supplier architectural design pattern is one such technique: proprietary security is another: enabling bilateral fee arrangement and token counting are a third. Management, security and billing are the commercial value-adds - that properly justify future service fees - that are worth protecting, today. In my view, if adoption depends on standardizing elements currently deemed out of scope, we standardize them. Looking at the current scoping of a WG and the practices of defending that scope is one way of understanding the (entirely legitimate) motivations of the commercial players - and their assumed models of adoption and deployment. While these models may be right for a portending provider's business, they may not be right for wider community goals. In setting WG items, we have to consider arguments wider than the advocacy of the large companies. I reiterated my position in the opening of this memo ( as someone who has a certain anguish about his historical role in fixing the un-IETF (but perfecty legitimate) behaviour of VeriSign in internet-style standards making, and as someone who sees evidence of others engaged (quite properly) in technical marketing via standards). What I am unclear on is the answer to the question, given the merits of the ENUM discovery technology. Many of the ENUM characteristics suggest that provider-centered, proprietary backroom management and security regimes may be the right thing to do. If we go this operations route, we must do so knowingly and openly, however. From: James Seng To: enum at ietf.org CC: "'enum at ietf.org'" , "Yu, James" Subject: Re: [Enum] User ENUM vs Operator ENUM Date: Tue, 15 Jun 2004 21:58:05 +0800 On 15 June 2004 pm 21:35, Yu, James wrote: > Access control is a way to limited access to the service info. in carrier > ENUM if the carrier community does not want the general public to access > that info. Whether and how to do it are implementation issues. This > subject is certainly not one we need to discuss here. why not? ops have always been discussed in ietf. > Also retrieving the service info. for a TN from Carrier ENUM does not mean > the call/message/transaction processing may continue. of cos. but *that is* outside the scope of ENUM if we crawl higher and look at other interoperability issues. james _______________________________________________ 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 Tue, 15 Jun 2004 14:48:12 -0400 From: Mike Hammer Date: Tue, 15 Jun 2004 14:48:12 -0400 To: "Peter Williams" Message-ID: <4.3.2.7.2.20040615141031.00b0f1e8@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter, Speaking of operational and inter-operability issues, assignment of blocks of numbers to service providers and the marketing "stickiness" of users not want to change their phone numbers was only recently alleviated by number portability in the PSTN and mobile networks. ENUM inherits this issue when they use E.164 numbering scheme. Yet, I keep hearing on this list references to handling of blocks of numbers. Although these numbers can be hierarchically structured, the reality may be more like batches of random numbers. The probability is that a number block of any size will diminish as the number of service providers (operators) increases. I would hope that the probability that numbers will frequently migrate, increasing the possibility that every other number in a sequence belongs to a different user or service provider, will be a prime consideration for the administration and operation of the ENUM directory structure(s?). I am not very confident of this at the moment, but hope to be shown that number portability in ENUM is not an issue. Mike At 09:23 AM 6/15/2004 -0700, Peter Williams wrote: James, The nature of ENUM - as a telematic service - has strong parallels to EDI, and PKI/VPNs in its likely provider-centered adoption practices. As a white pages-style directory service mapping PSDN and PSTN NSAPs to names in name spaces manged by late 1980s-style name servers, it obviously has strong parallels to Steve Kille's & other's X.500 efforts (and Marshall/Einar's NADF efforts just outside of IETF) in the 1990s. In all these cases, we have experience of the operational and adoption arcs. When rescoping the WG work targets for ENUM, now, we may be able to articulate a rationale for any new work by specifically asking: so what is the consensus on expected ENUM deployment and operations, today - and compare these goals to the experience from the parallels? There is a strong tradition in certain large US companies that standards making is always about market making. The investment made to get a standard adopted requires payoff - in the form of capturing a large market, all in one go. This tradition has become more prevalent in IETF over the last 10 years! as the IETF has adapted to the business investment climate it necessarily operates in. If one structures the standards right, one can protect the future revenue stream of such a capture - by creating barrier's to entry in the operational phase. Structuring proprietary management processes abound standards adopting the provider/supplier architectural design pattern is one such technique: proprietary security is another: enabling bilateral fee arrangement and token counting are a third. Management, security and billing are the commercial value-adds - that properly justify future service fees - that are worth protecting, today. In my view, if adoption depends on standardizing elements currently deemed out of scope, we standardize them. Looking at the current scoping of a WG and the practices of defending that scope is one way of understanding the (entirely legitimate) motivations of the commercial players - and their assumed models of adoption and deployment. While these models may be right for a portending provider's business, they may not be right for wider community goals. In setting WG items, we have to consider arguments wider than the advocacy of the large companies. I reiterated my position in the opening of this memo ( as someone who has a certain anguish about his historical role in fixing the un-IETF (but perfecty legitimate) behaviour of VeriSign in internet-style standards making, and as someone who sees evidence of others engaged (quite properly) in technical marketing via standards). What I am unclear on is the answer to the question, given the merits of the ENUM discovery technology. Many of the ENUM characteristics suggest that provider-centered, proprietary backroom management and security regimes may be the right thing to do. If we go this operations route, we must do so knowingly and openly, however. From: James Seng To: enum at ietf.org CC: "'enum at ietf.org'" , "Yu, James" Subject: Re: [Enum] User ENUM vs Operator ENUM Date: Tue, 15 Jun 2004 21:58:05 +0800 On 15 June 2004 pm 21:35, Yu, James wrote: > Access control is a way to limited access to the service info. in carrier > ENUM if the carrier community does not want the general public to access > that info. Whether and how to do it are implementation issues. This > subject is certainly not one we need to discuss here. why not? ops have always been discussed in ietf. > Also retrieving the service info. for a TN from Carrier ENUM does not mean > the call/message/transaction processing may continue. of cos. but *that is* outside the scope of ENUM if we crawl higher and look at other interoperability issues. james _______________________________________________ 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, 16 Jun 2004 00:43:35 -0400 From: "Stastny Richard" Date: Wed, 16 Jun 2004 00:43:35 -0400 To: "Mike Hammer" Subject: AW: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162443767@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Since (at least in User ENUM aka e164.arpa) the should be the domain name holder of the domain corresponding to the E.164 number and therefor should be able to modify the contents of his domain, he may change the URIs pointing to his service providers, what could be understood as number portability (changing his SP). He may also transfer the domain from one ENUM provider to another This only works if the delegations are done (sorry Patrik, this was the main reason for the Tiers) directly from Tier 1 (the national level to the Tier 2 (the level containing the NAPTRs) Since NP is not an issue between countries ;-), this grouping is possible (also for national policies). There could be a Tier1a and 1b for various reasons (e.g +1) or a grouping according to differnt number types e.g. 800 numbers will always be 800 numbers. So NP is not an issue in User ENUM. It is an issue in Infrastructure ENUM because operators again want to have block delegations for simple routing to gateways and hiding of information. Although in some countries NP is only necessary for "public available telephony services" (PATS) and most VoIP services are non-PATS (this terminology is EU centric) = ECS (electronic communications services), we should provide for NP from the beginning to avoid later hazzles. We should also not forget the block allocation was the number 1 reason for number exhaust. If new number ranges used for VoIP are handed out with block size 1 there will be more numbers available then now in use. Richard -----UrsprĂngliche Nachricht----- Von: Mike Hammer [mailto:mhammer at cisco.com] Gesendet: Di 15.06.2004 20:25 An: Peter Williams; jseng at pobox.org.sg; enum at ietf.org Cc: Betreff: Re: [Enum] User ENUM vs Operator ENUM Peter, Speaking of operational and inter-operability issues, assignment of blocks of numbers to service providers and the marketing "stickiness" of users not want to change their phone numbers was only recently alleviated by number portability in the PSTN and mobile networks. ENUM inherits this issue when they use E.164 numbering scheme. Yet, I keep hearing on this list references to handling of blocks of numbers. Although these numbers can be hierarchically structured, the reality may be more like batches of random numbers. The probability is that a number block of any size will diminish as the number of service providers (operators) increases. I would hope that the probability that numbers will frequently migrate, increasing the possibility that every other number in a sequence belongs to a different user or service provider, will be a prime consideration for the administration and operation of the ENUM directory structure(s?). I am not very confident of this at the moment, but hope to be shown that number portability in ENUM is not an issue. Mike At 09:23 AM 6/15/2004 -0700, Peter Williams wrote: >James, > >The nature of ENUM - as a telematic service - has strong parallels to EDI, >and PKI/VPNs in its likely provider-centered adoption practices. As a >white pages-style directory service mapping PSDN and PSTN NSAPs to names >in name spaces manged by late 1980s-style name servers, it obviously has >strong parallels to Steve Kille's & other's X.500 efforts (and >Marshall/Einar's NADF efforts just outside of IETF) in the 1990s. In all >these cases, we have experience of the operational and adoption arcs. When >rescoping the WG work targets for ENUM, now, we may be able to articulate >a rationale for any new work by specifically asking: so what is the >consensus on expected ENUM deployment and operations, today - and compare >these goals to the experience from the parallels? > >There is a strong tradition in certain large US companies that standards >making is always about market making. The investment made to get a >standard adopted requires payoff - in the form of capturing a large >market, all in one go. This tradition has become more prevalent in IETF >over the last 10 years! as the IETF has adapted to the business investment >climate it necessarily operates in. > >If one structures the standards right, one can protect the future revenue >stream of such a capture - by creating barrier's to entry in the >operational phase. Structuring proprietary management processes abound >standards adopting the provider/supplier architectural design pattern is >one such technique: proprietary security is another: enabling bilateral >fee arrangement and token counting are a third. Management, security and >billing are the commercial value-adds - that properly justify future >service fees - that are worth protecting, today. > >In my view, if adoption depends on standardizing elements currently deemed >out of scope, we standardize them. Looking at the current scoping of a WG >and the practices of defending that scope is one way of understanding the >(entirely legitimate) motivations of the commercial players - and their >assumed models of adoption and deployment. While these models may be right >for a portending provider's business, they may not be right for wider >community goals. In setting WG items, we have to consider arguments wider >than the advocacy of the large companies. > >I reiterated my position in the opening of this memo ( as someone who has >a certain anguish about his historical role in fixing the un-IETF (but >perfecty legitimate) behaviour of VeriSign in internet-style standards >making, and as someone who sees evidence of others engaged (quite >properly) in technical marketing via standards). What I am unclear on is >the answer to the question, given the merits of the ENUM discovery >technology. Many of the ENUM characteristics suggest that >provider-centered, proprietary backroom management and security regimes >may be the right thing to do. If we go this operations route, we must do >so knowingly and openly, however. > > > >>From: James Seng >>To: enum at ietf.org >>CC: "'enum at ietf.org'" , "Yu, James" >>Subject: Re: [Enum] User ENUM vs Operator ENUM >>Date: Tue, 15 Jun 2004 21:58:05 +0800 >> >>On 15 June 2004 pm 21:35, Yu, James wrote: >> > Access control is a way to limited access to the service info. in carrier >> > ENUM if the carrier community does not want the general public to access >> > that info. Whether and how to do it are implementation issues. This >> > subject is certainly not one we need to discuss here. >> >>why not? ops have always been discussed in ietf. >> >> > Also retrieving the service info. for a TN from Carrier ENUM does not mean >> > the call/message/transaction processing may continue. >> >>of cos. but *that is* outside the scope of ENUM if we crawl higher and look >>at other interoperability issues. >> >>james >> >>_______________________________________________ >>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 Kim.Fullbrook@O2.COM Wed, 16 Jun 2004 11:38:32 -0400 From: "Fullbrook Kim (UK)" Date: Wed, 16 Jun 2004 11:38:32 -0400 To: "'enum at ietf.org> Subject: [Enum] GRX ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: GRX ENUM Status: R A previous message mentioned the use of ENUM on the GSM GRX network for routing MMS messages.  Can anyone comment on the extent to which this is in use ?  The latest version of GSMA document IR.52 mentions the use of ENUM in MMS but it's on a fairly localised level rather than anything GRX-wide. Kim. -----Original Message----- From: Yu, James [mailto:james.yu at neustar.biz] Sent: 12 June 2004 15:26 To: 'richard.stastny at oefeg.at'; 'sdlind at att.com'; 'richard at shockey.us'; 'enum at ietf.org' Cc: 'jseng at pobox.org.sg'; 'mah at eunet.at'; 'paf at cisco.com' Subject: Re: [Enum] User ENUM vs Operator ENUM One example/use of carrier ENUM is to retrieve the routing number/prefix for a ported phone number.  End User ENUM will not have this NAPTR RR (end user will not have the knowledge to put in the info.). As Richard mentioned, carriers use carrier ENUM for inter-carrier communication/routing (e.g., identify the MMSC for a mobile phone number or the SIP URI for receing incoming INVITEs).  So carrier ENUM contains NAPTR RRs for the phone numbers served by the carriers.  A carrier can put in the service info. only for the phone numbers it serves.  In end user ENUM, an end user can put service info. associated with many carriers and/or non-carrier service providers (e.g., those who don't assign phone numbers to their subscribers). General public may not access NAPTR RRs in carrier ENUM.  Access control can be applied to carrier ENUM to block unauthored access.  Also the access can be retricted to private-IP networks if the carrier community decide so (e.g., carrier ENUM's DNS servers can only be accessed via private-IP networks such as the GRX in GSM/GPRS and the CRX that is discussed among the CDMA carriers. James -------------------------- Sent from my BlackBerry Wireless Handheld ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 james.yu@neustar.biz Wed, 16 Jun 2004 13:13:49 -0400 From: "Yu, James" Date: Wed, 16 Jun 2004 13:13:49 -0400 To: "'Fullbrook Kim (UK)'" Subject: RE: [Enum] GRX ENUM Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D565D@stntexch01.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Title: GRX ENUM Status: R Kim,   No, it is just a possibility because there is no carrier ENUM infrastructure in place for the carriers yet.   James -----Original Message-----From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM]Sent: Wednesday, June 16, 2004 5:41 AMTo: 'enum at ietf.org'Subject: [Enum] GRX ENUM A previous message mentioned the use of ENUM on the GSM GRX network for routing MMS messages.  Can anyone comment on the extent to which this is in use ?  The latest version of GSMA document IR.52 mentions the use of ENUM in MMS but it's on a fairly localised level rather than anything GRX-wide. Kim. -----Original Message----- From: Yu, James [mailto:james.yu at neustar.biz] Sent: 12 June 2004 15:26 To: 'richard.stastny at oefeg.at'; 'sdlind at att.com'; 'richard at shockey.us'; 'enum at ietf.org' Cc: 'jseng at pobox.org.sg'; 'mah at eunet.at'; 'paf at cisco.com' Subject: Re: [Enum] User ENUM vs Operator ENUM One example/use of carrier ENUM is to retrieve the routing number/prefix for a ported phone number.  End User ENUM will not have this NAPTR RR (end user will not have the knowledge to put in the info.). As Richard mentioned, carriers use carrier ENUM for inter-carrier communication/routing (e.g., identify the MMSC for a mobile phone number or the SIP URI for receing incoming INVITEs).  So carrier ENUM contains NAPTR RRs for the phone numbers served by the carriers.  A carrier can put in the service info. only for the phone numbers it serves.  In end user ENUM, an end user can put service info. associated with many carriers and/or non-carrier service providers (e.g., those who don't assign phone numbers to their subscribers). General public may not access NAPTR RRs in carrier ENUM.  Access control can be applied to carrier ENUM to block unauthored access.  Also the access can be retricted to private-IP networks if the carrier community decide so (e.g., carrier ENUM's DNS servers can only be accessed via private-IP networks such as the GRX in GSM/GPRS and the CRX that is discussed among the CDMA carriers. James -------------------------- Sent from my BlackBerry Wireless Handheld ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 KMcCandless@verisign.com Wed, 16 Jun 2004 18:20:38 -0400 From: "McCandless, Kevin" Date: Wed, 16 Jun 2004 18:20:38 -0400 To: "'enum at ietf.org Subject: RE: AW: [Enum] Please start thinking about agenda items for IETF San Diego etc Message-ID: <318266A4431BC549B4C4D6FD3EA6E24D01F6DD6F@ove1wnexm01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Also, EPP for E.164 numbers was documented by the ENUM forum as a protocol for registration. The adoption of the EPP and completion to RFC will help. > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Allison Mankin > Sent: Friday, June 11, 2004 11:26 AM > To: enum at ietf.org > Cc: shollenbeck at verisign.com; Richard Shockey > Subject: Re: AW: [Enum] Please start thinking about agenda > items for IETF San Diego etc > > > On the epp-e164 point, even before provreg was closed, the model > preferred was for applications of EPP to be produced by their > WGs rather than by provreg, if possible. ENUM adopted the epp-e164 > document as a WG item some time ago, and it is quite right for the > group to give it a thorough expert discussion now. > > Allison > > _______________________________________________ > 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 james.f.baskin@verizon.com Wed, 16 Jun 2004 18:36:52 -0400 From: james.f.baskin@verizon.com Date: Wed, 16 Jun 2004 18:36:52 -0400 To: enum at ietf.org Subject: [Enum] Re: User ENUM vs Operator ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Tue, 15 Jun 2004 at 16:33:09 -0400, Richard Stastny wrote: > >Since (at least in User ENUM aka e164.arpa) the should >be the domain name holder of the domain corresponding to >the E.164 number and therefor should be able to modify the >contents of his domain, he may change the URIs pointing >to his service providers, what could be understood as number >portability (changing his SP). He may also transfer the domain >from one ENUM provider to another > RFC 3761 states: Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations. Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world. Nothing in RFC3761 distinguishes categories such as end user or carrier. I believe it is incorrect to equate e164.arpa with "user ENUM." What Richard describes, above, might be a description of the policy for a particular domain, but the policy could be very different in other domains. A policy could be developed that provides for both user-controlled and carrier-controlled (infrastructure) NAPTRs in the same domain. There has been talk about user/public ENUM and Infrastructure ENUM (iENUM) being orthogonal, with the conclusion that they must be handled in separate domains. I don't see the logic in such a conclusion. If, for example, a different Enumservice were registered for iENUM, then an iENUM NAPTR could easily coexist with user-specified NAPTRs for other registered Enumservices in a single ENUM tree -- no split DNS, no other undesirable DNS options needed. (Question: Would it be possible for one NAPTR to exist in a particular level of the ENUM tree along with NS records pointing to a lower level that contains additional NAPTRs for different Enumservices? (E.g., to allow a user to control the domain where those additional NAPTRs reside.)) Please forgive me if I have used incorrect terminology or if the suggestion violates some rule of DNS operation. Flame me, but also tell me where I have gone wrong. >This only works if the delegations are done (sorry Patrik, this >was the main reason for the Tiers) directly from Tier 1 (the >national level to the Tier 2 (the level containing the NAPTRs) > NAPTRs are not restricted to a particular level, are they?. >Since NP is not an issue between countries ;-), this grouping >is possible (also for national policies). There could be a Tier1a >and 1b for various reasons (e.g +1) or a grouping according >to differnt number types e.g. 800 numbers will always be >800 numbers. > Number portability can be an issue for every number regardless of the origin of the "call." A receiving service provider may need to determine where to deliver the call based on porting information. But if the NAPTRs associated with a number in ENUM always relate to the current end-user assignee, then as far as ENUM is concerned, porting is not a technical issue. It is taken care of in the registration process. >So NP is not an issue in User ENUM. It is an issue >in Infrastructure ENUM because operators again >want to have block delegations for simple routing >to gateways and hiding of information. > >Although in some countries NP is only necessary >for "public available telephony services" (PATS) and >most VoIP services are non-PATS (this terminology is >EU centric) = ECS (electronic communications services), >we should provide for NP from the beginning to avoid >later hazzles. > A VoIP service may be considered non-PATS in some places, but aren't most of those using proprietary (non-E.164) naming schemes? I would be surprised if many countries would allow assignment of E.164 numbers for VoIP in a non-portable manner in the long term. I guess this is what Richard is implying. (I would also guess that most countries will insist that VoIP services using E.164 numbers should be dialable from the PSTN, without the originating or intermediate carriers needing to do an ENUM query, but that isn't a discussion for this list.) >We should also not forget the block allocation was the >number 1 reason for number exhaust. If new number ranges >used for VoIP are handed out with block size 1 there will >be more numbers available then now in use. > We are in agreement here. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Wed, 16 Jun 2004 19:55:54 -0400 From: "Conroy, Lawrence (SMTP)" Date: Wed, 16 Jun 2004 19:55:54 -0400 To: "McCandless, Kevin" Subject: Re: AW: [Enum] Please start thinking about agenda items for IETF In-Reply-To: <318266A4431BC549B4C4D6FD3EA6E24D01F6DD6F@ove1wnexm01.vcorp.ad.vrsn.com> Message-ID: <5219ECD4-BFEF-11D8-8D6A-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Kevin, folks, Scott has already intimated that this is likely to be implemented. I haven't seen any comments that the Schema is incorrect; unless I've missed something, there haven't been any objections to this going forward. What I have seen is some confusion over who exactly would use this; ENUMF may be atypical in their view (not of EPP, but of EPP-164). all the best, Lawrence On 16 Jun 2004, at 22:21, McCandless, Kevin wrote: Also, EPP for E.164 numbers was documented by the ENUM forum as a protocol for registration. The adoption of the EPP and completion to RFC will help. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 17 Jun 2004 05:00:44 -0400 From: "Stastny Richard" Date: Thu, 17 Jun 2004 05:00:44 -0400 To: Subject: RE: [Enum] Re: User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162443771@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R James Baskin wrote: > On Tue, 15 Jun 2004 at 16:33:09 -0400, Richard Stastny wrote: > > > >Since (at least in User ENUM aka e164.arpa) the should > >be the domain name holder of the domain corresponding to > >the E.164 number and therefor should be able to modify the > >contents of his domain, he may change the URIs pointing > >to his service providers, what could be understood as number > >portability (changing his SP). He may also transfer the domain > >from one ENUM provider to another > > > RFC 3761 states: > > Holders of E.164 numbers which want to be listed in DNS > should contact the appropriate zone administrator according to the > policy which is attached to the zone. One should start looking for > this information by examining the SOA resource record associated with > the zone, just like in normal DNS operations. > Of course, as with other domains, policies for such listings will be > controlled on a subdomain basis and may differ in different parts of > the world. > > > Nothing in RFC3761 distinguishes categories such as end user or carrier. > I believe it is incorrect to equate e164.arpa with "user ENUM." > What Richard describes, above, might be a description of the policy for > a particular domain, but the policy could be very different in other > domains. > A policy could be developed that provides for both user-controlled and > carrier-controlled (infrastructure) NAPTRs in the same domain. > [Richard>] It is true that RFC3761 does allow for user and carrier ENUM implementations, but 1. all other bodies (ITU-T, ETSI and all other For a dealing with e164.arpa assumed (maybe wrongly) that the end-user is in control of the domain corresponding to his E.164 number and they assumed also that e164.arpa is opt-in (both for calling and called user, to use PSTN terminology) 2. Opt-in for the calling user also means that the end-user may query ENUM by himself and gets a useful result back (e.g featuring a Snom or an IX66). If you mix now user and carrier ENUM in the same domain, looking up a E.164 number in e164.arpa will be a lottery. With some country codes or even operators you get a useful result back, in other you don't. I cannot imagine that you can sell this confusion to a user. But there are other problems too (see below) > There has been talk about user/public ENUM and Infrastructure ENUM > (iENUM) being orthogonal, with the conclusion that they must be handled > in separate domains. I don't see the logic in such a conclusion. If, > for example, a different Enumservice were registered for iENUM, then > an iENUM NAPTR could easily coexist with user-specified NAPTRs for > other registered Enumservices in a single ENUM tree -- no split DNS, > no other undesirable DNS options needed. [Richard>] I do not think that this can work. Even if the structure is the same (every fully qualified number exists in the tree), you would have two domain name holders: the user and the operator Q1: who decides on the Nameserver operator, especially if the user is or is wanting to operate his own NS (a company) Q2: Who is admistrating the access right Q2: how do you distinguish between ENUM and iENUM NAPTRs (different services, different flags, ...?) What is worse is that user ENUM and infrastructure ENUM may require different structures. Operators like block delegations. The whole idea is a nightmare administratively. > > (Question: Would it be possible for one NAPTR to exist in a particular > level > of the ENUM tree along with NS records pointing to a lower level that > contains additional NAPTRs for different Enumservices? (E.g., to allow > a user to control the domain where those additional NAPTRs reside.)) > > Please forgive me if I have used incorrect terminology or if the > suggestion > violates some rule of DNS operation. Flame me, but also tell me where > I have gone wrong. [Richard>] No need to flame, the issue is tricky and it took us a while to find this out. The answer is yes and no. The basic problem is: you may place NAPTRs anywhere in the tree together with NS records (at delegation points), but you just do not see them. The good thing (?): you may not control the domain, if at least one Delegation is made. The bad thing: you may not define default NAPTRs for the number range (easily). The reason is: if you query a FQDN und this FQDN does exist, you get the NAPTRs back in the FQDN, you never see the NAPTR above. Example: you query +43 1 797284032 (my office extension), you get back a NAPTR. If there is also a NAPTR in +43 1 7972840, you just do not see it (note: I am using E.164 numbers in this example to stay sane, the reader may convert this to 0.4.8.2.7.9.7.1.3.4.e164.arpa on his own ;-) What is even worse: if you query +43 1 797284077 (a not existing extension, you get back NXDOMAIN. It would be nice at least in this case to get back the NAPTR in +43 1 7972840, but DNS does not do this. The only way to get back a NAPTR in this case would be to put in a wildcard NAPTR in +43 1 7972840 and do no other delegations. This could be used for routing of whole numbering blocks as long as not ONE single number is delegated (e.g. ported) somewhere else. Thanks to Jim Reed we found another solution: you may put in a normal NAPTR there and if you get back an NXDOMAIN for +43 1 797284077, you get also back in the response the enclosing zone, which would be in this case +43 1 7972840. Now you may do a second query for this domain and may get the NAPTR. > > >This only works if the delegations are done (sorry Patrik, this > >was the main reason for the Tiers) directly from Tier 1 (the > >national level to the Tier 2 (the level containing the NAPTRs) > > > NAPTRs are not restricted to a particular level, are they?. > > >Since NP is not an issue between countries ;-), this grouping > >is possible (also for national policies). There could be a Tier1a > >and 1b for various reasons (e.g +1) or a grouping according > >to differnt number types e.g. 800 numbers will always be > >800 numbers. > > > Number portability can be an issue for every number regardless of > the origin of the "call." A receiving service provider may need > to determine where to deliver the call based on porting information. > But if the NAPTRs associated with a number in ENUM always relate > to the current end-user assignee, then as far as ENUM is concerned, > porting is not a technical issue. It is taken care of in the > registration process. [Richard>] Again yes and no: In user ENUM you are correct, because the user is selecting (porting) the application service provider. (but if he changes registrar and NS Provider, this also may be considered as "porting" = domain transfer) With carrier ENUM this is different. Porting would imply that The ENUM entry changes and since the carrier is also the domain name holder changes, this would also imply a domain transfer. There are ideas not to force NP on VoIP number ranges, but this sure will come sooner or later (why not?). So if you start with block delegations and wildcards, you run into problems as soon as the first number ports out (the above described functionality may be a solution to this problem). Onward routing and anchor providers are not a good idea to be introduced on IP. > > >So NP is not an issue in User ENUM. It is an issue > >in Infrastructure ENUM because operators again > >want to have block delegations for simple routing > >to gateways and hiding of information. > > > >Although in some countries NP is only necessary > >for "public available telephony services" (PATS) and > >most VoIP services are non-PATS (this terminology is > >EU centric) = ECS (electronic communications services), > >we should provide for NP from the beginning to avoid > >later hazzles. > > > A VoIP service may be considered non-PATS in some places, > but aren't most of those using proprietary (non-E.164) naming > schemes? [Richard>] No, most of them are using spezial number ranges defined for VoIP. The ones you are talking about (e.g. FWD) are not even considered non-PATS (non-non-PATS?) >I would be surprised if many countries would allow > assignment of E.164 numbers for VoIP in a non-portable manner > in the long term. [Richard>] agree, see above >I guess this is what Richard is implying. > (I would also guess that most countries will insist that VoIP > services using E.164 numbers should be dialable from the PSTN, > without the originating or intermediate carriers needing to do > an ENUM query, but that isn't a discussion for this list.) [Richard>] just for completeness: there are two types of number ranges currently deployed for VoIP: 1. block assignment and routed to the PoI of the assignee (if portable, you need an IN LNP query on the PSTN). This numbers do not need to be in ENUM. 2. ENUM enabled numbers: the whole number range needs only to be routed on the PSTN to the "nearest" so-called generic gateway The gateway queries ENUM and routes the call further. Any GW can be used. In Austria such a number range has been assigned already (+43 780). The advantage here is that if you have such a gateway in your originating network, you may route ALL such number ranges via this gateway. Regards Richard > > >We should also not forget the block allocation was the > >number 1 reason for number exhaust. If new number ranges > >used for VoIP are handed out with block size 1 there will > >be more numbers available then now in use. > > > We are in agreement here. > > Jim > > > > _______________________________________________ > 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, 17 Jun 2004 06:01:45 -0400 From: Jim Reid Date: Thu, 17 Jun 2004 06:01:45 -0400 To: james.f.baskin at verizon.com Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: Message-ID: <11173.1087465985@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "james" == james f baskin writes: james> Nothing in RFC3761 distinguishes categories such as end james> user or carrier. I believe it is incorrect to equate james> e164.arpa with "user ENUM." What Richard describes, above, james> might be a description of the policy for a particular james> domain, but the policy could be very different in other james> domains. A policy could be developed that provides for james> both user-controlled and carrier-controlled james> (infrastructure) NAPTRs in the same domain. How could that be implemented in the DNS? It's a only lookup service and doesn't have any hooks for implementing policy. james> There has been talk about user/public ENUM and james> Infrastructure ENUM (iENUM) being orthogonal, with the james> conclusion that they must be handled in separate domains. james> I don't see the logic in such a conclusion. If, for james> example, a different Enumservice were registered for iENUM, james> then an iENUM NAPTR could easily coexist with james> user-specified NAPTRs for other registered Enumservices in james> a single ENUM tree -- no split DNS, no other undesirable james> DNS options needed. You are mistaken. Different NAPTRs (or whatever) could exist in a zone and be controlled/manipulated by different entities. But it would be a nightmare to set up and administer. [Try making something like BIND9's update-policy{} work for 100M+ numbers each with tens of NAPTR records all of which require fine-grained control.] And there would be massive privacy implications for both the providers and the end user. For instance if my mobile telco has introduced a NAPTR for my GSM which says "no inbound calls while Jim's overseas", this will be visible to everyone in the DNS. So any ENUM-aware burglar's been told "come on round Jim's house because there's nobody home". Similarly, a telco might not be allowed by law or regulation to publish the fact they provide service for a given number. And even if they were, no telco would want to advertise that information to their competitors. Another concern is user ENUM is going to have to be opt-in. The number doesn't go in the tree unless the "owner" consents. Operator or infrastructure ENUM has to work for every active number, including those people with unlisted numbers, test codes, preminum rate and free numbers, etc, etc. That means there can be no opt-in principle at work there. I fail to see how these mutually exclusive principles can be satisfied by having a single, public tree for both. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Thu, 17 Jun 2004 06:29:38 -0400 From: "Fullbrook Kim (UK)" Date: Thu, 17 Jun 2004 06:29:38 -0400 To: "'enum at ietf.org> Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] User ENUM vs Operator ENUM Status: R I would support the assertion below.  Saying the same thing in another way, there are basic privacy concerns about putting "personal" information such as SIP URIs and telephone numbers in the public DNS and for those of us in the European Union this has to be "opt in".  On the other hand certain telephony services might rely on everyone having their ENUM information available in the DNS.  If someone opts out because of privacy concerns the service breaks for that customer.  The implication is that only Carrier ENUM - where this personal information is not publicly available - is going to be viable. Even then there are questions over how someone could do a V-o-IP call from their PC on the Internet at home and make a successful call without running into these privacy concerns if the called party has not "opted in". Sorry if this is going over any old ground but I'm fairly new to ENUM. Kim. -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: 17 June 2004 10:53 To: james.f.baskin at verizon.com Cc: enum at ietf.org Subject: Re: [Enum] Re: User ENUM vs Operator ENUM (Edited) Another concern is user ENUM is going to have to be opt-in. The number doesn't go in the tree unless the "owner" consents. Operator or infrastructure ENUM has to work for every active number, including those people with unlisted numbers, test codes, preminum rate and free numbers, etc, etc. That means there can be no opt-in principle at work there. I fail to see how these mutually exclusive principles can be satisfied by having a single, public tree for both. ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 ag@ag-projects.com Thu, 17 Jun 2004 07:02:15 -0400 From: Adrian Georgescu Date: Thu, 17 Jun 2004 07:02:15 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R There are some ways by which privacy concerns may be addressed. An example would be the use of anonymous addresses stored in ENUM and real addresses set as aliases pointing to those in the application servers, both SIP or EMAIL servers support redirection. Adrian On Jun 17, 2004, at 12:19 PM, Fullbrook Kim (UK) wrote: I would support the assertion below.  Saying the same thing in another way, there are basic privacy concerns about putting "personal" information such as SIP URIs and telephone numbers in the public DNS and for those of us in the European Union this has to be "opt in".  On the other hand certain telephony services might rely on everyone having their ENUM information available in the DNS.  If someone opts out because of privacy concerns the service breaks for that customer.  The implication is that only Carrier ENUM - where this personal information is not publicly available - is going to be viable. Even then there are questions over how someone could do a V-o-IP call from their PC on the Internet at home and make a successful call without running into these privacy concerns if the called party has not "opted in". Sorry if this is going over any old ground but I'm fairly new to ENUM. Kim. -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: 17 June 2004 10:53 To: james.f.baskin at verizon.com Cc: enum at ietf.org Subject: Re: [Enum] Re: User ENUM vs Operator ENUM (Edited) Another concern is user ENUM is going to have to be opt-in. The number doesn't go in the tree unless the "owner" consents. Operator or infrastructure ENUM has to work for every active number, including those people with unlisted numbers, test codes, preminum rate and free numbers, etc, etc. That means there can be no opt-in principle at work there. I fail to see how these mutually exclusive principles can be satisfied by having a single, public tree for both. ======================================================== This electronic message contains information from the mmO2 plc Group 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 Richard.Stastny@oefeg.at Thu, 17 Jun 2004 07:49:08 -0400 From: "Stastny Richard" Date: Thu, 17 Jun 2004 07:49:08 -0400 To: "Fullbrook Kim (UK)" Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F1622B0637@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Considering the latest discussions and also looking at what ENUM currently is used for, the original idea of having all communications via one number does not seem to hold anymore. 1. ENUM is mainly used for voice calls or telephony related services (e.g. SMS/MMS) 2. the one number idea for all types of communications does not even hold for VoIP, because currently folks are collecting phone numbers like stamps. 2a. The idea of a personal numbers also does not seem to fly because everybody wants a geographic number, either where he lives or friends/family live. The whole business will of course be obsolete when distance will go away on the PSTN or the PSTN will go away. Then one number will be enough. So ENUM is currently reduced to an IN service giving you a "routing number" to the sip proxy - in Internet terminology only the domain part of the sip URI is relevant. The user part is then only for internal use and either may be anonymized or even better just be the E.164 number itself. So if an ENUM entry for number +431797284032 is only pointing to sip:+431797284032 at asterisk.iphone.at the only information disclosed is my provider and that the number exists. Even this could be hidden with a wildcard and a regexp. On the other hand, spammers on the PSTN just dial one number after the other. Additional services then need to be negotiated, either within sip or more comfortable between Personal User Agents as proposed with UCI. Even the negotiation protocol used could be negotiated. The only enumservice needed for this is the already proposed 'srs' service resolution service with a sip (or h323 URI). In this case also the distinction between user and carrier ENUM is not necessary anymore, because then ENUM is linked to the SRS provider and ENUM would not be opt-in anymore (at least for E.164 numbers existing only on the Internet). The user still may point from his SRS service to different sip, mail, etc providers. I propose this issue to be discussed either in the ENUM WG or the proposed iENUM BoF. Note: iENUM IMHO can only work generalized for all services if this is implemented. Richard -----Original Message----- From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] Sent: Thursday, June 17, 2004 12:20 PM To: 'enum at ietf.org' Subject: RE: [Enum] User ENUM vs Operator ENUM I would support the assertion below.  Saying the same thing in another way, there are basic privacy concerns about putting "personal" information such as SIP URIs and telephone numbers in the public DNS and for those of us in the European Union this has to be "opt in".  On the other hand certain telephony services might rely on everyone having their ENUM information available in the DNS.  If someone opts out because of privacy concerns the service breaks for that customer.  The implication is that only Carrier ENUM - where this personal information is not publicly available - is going to be viable. Even then there are questions over how someone could do a V-o-IP call from their PC on the Internet at home and make a successful call without running into these privacy concerns if the called party has not "opted in". Sorry if this is going over any old ground but I'm fairly new to ENUM. Kim. -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: 17 June 2004 10:53 To: james.f.baskin at verizon.com Cc: enum at ietf.org Subject: Re: [Enum] Re: User ENUM vs Operator ENUM (Edited) Another concern is user ENUM is going to have to be opt-in. The number doesn't go in the tree unless the "owner" consents. Operator or infrastructure ENUM has to work for every active number, including those people with unlisted numbers, test codes, preminum rate and free numbers, etc, etc. That means there can be no opt-in principle at work there. I fail to see how these mutually exclusive principles can be satisfied by having a single, public tree for both. ======================================================== This electronic message contains information from the mmO2 plc Group 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 jim@rfc1035.com Thu, 17 Jun 2004 09:15:31 -0400 From: Jim Reid Date: Thu, 17 Jun 2004 09:15:31 -0400 To: "Stastny Richard" Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <06CF906FE3998C4E944213062009F1622B0637@oefeg-s02.oefeg.loc> Message-ID: <11434.1087477169@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: Richard> Considering the latest discussions and also looking at Richard> what ENUM currently is used for, the original idea of Richard> having all communications via one number does not seem to Richard> hold anymore. Richard> 1. ENUM is mainly used for voice calls or telephony Richard> related services (e.g. SMS/MMS) This may be true today, but I feel it misses the bigger picture. The real power of ENUM comes from the flexibility of NAPTR records and what they can represent. ENUM is just a way of transforming someone's phone number into a bunch of NAPTRs that can do just about anything. So a phone number effectively becomes an access mechanism for anything that can be expressed as an URI: ie pretty much anything. IMO it's unwise to get into a mindset that ENUM is just about voice or VoIP or telephony services. ENUM shouldn't be constrained to only these things. [Just like how IP datagrams weren't restricted to only getting carried over the ARPAnet or even ethernets.] The real innovation in ENUM will be when people come up with new services and applications that use NAPTRs in ways we've not yet imagined. Richard> 2. the one number idea for all types of communications Richard> does not even hold for VoIP, because currently folks are Richard> collecting phone numbers like stamps. This may be true, but so what? People collect email addresses like stamps too. This doesn't the diminish the need for a consistent way of reaching someone by email. If anything, it brings that need into sharp focus. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 17 Jun 2004 09:37:38 -0400 From: "Stastny Richard" Date: Thu, 17 Jun 2004 09:37:38 -0400 To: "Jim Reid" Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162443775@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid(!) writes: > > >>>>> "Richard" == Stastny Richard writes: > > Richard> Considering the latest discussions and also looking at > Richard> what ENUM currently is used for, the original idea of > Richard> having all communications via one number does not seem to > Richard> hold anymore. > > Richard> 1. ENUM is mainly used for voice calls or telephony > Richard> related services (e.g. SMS/MMS) > > This may be true today, but I feel it misses the bigger picture. The > real power of ENUM comes from the flexibility of NAPTR records and > what they can represent. ENUM is just a way of transforming someone's > phone number into a bunch of NAPTRs that can do just about anything. > So a phone number effectively becomes an access mechanism for anything > that can be expressed as an URI: ie pretty much anything. > > IMO it's unwise to get into a mindset that ENUM is just about voice or > VoIP or telephony services. ENUM shouldn't be constrained to only these > things. [Just like how IP datagrams weren't restricted to only getting > carried over the ARPAnet or even ethernets.] The real innovation in > ENUM will be when people come up with new services and applications > that use NAPTRs in ways we've not yet imagined. > [Richard>] I fully agree, but you know I always was open for both approaches. This is also why I oppose the idea to merge iENUM and user ENUM in one tree, because then the operators will take over and the user may not be able to add own NAPTRs. I also do not see a privacy problem if a hotel or company is putting a NAPTR in pointing to their webpage or the geoloc of their place. IETF always insisted on the end-to-end principle and for a good reason, although there had been many attempts to break this. The Internet would not be what it is today. BTW, some people say if we would today start the Internet, it would never happen. Privacy and security should be provided, but also the user has some responsibility. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Thu, 17 Jun 2004 14:05:10 -0400 From: "Peter Williams" Date: Thu, 17 Jun 2004 14:05:10 -0400 To: Richard.Stastny at oefeg.at Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R IETF always insisted on the end-to-end principle and for a good reason, although there had been many attempts to break this. The Internet would not be what it is today. BTW, some people say if we would today start the Internet, it would never happen. Privacy and security should be provided, but also the user has some responsibility. In the X.500 secure directory experiments, we had a 'phone number to fully distributed directory reference(s)" service. It was a side-effect of using a fully-inverted structure for the data set - where every attribute was an local index. The entire lookup algorithm was generalized - take an attribute, and find out the (always local) set of references to entries, some of which may be mastered elsewhere, and some of which may be cached locally. NAPTRS, DSEs, whatever. In one fun experiment, as you wandered through the campus buildings, a sensor would track your location, and have the PABX forward your incoming call to the nearest extension. The X.500 directory was the underlying technique for representing this entirely local set of knowledge - linking one reference system to another. The phone/PABX company/administrator was not involved in any way - other than as the provider of unique, stable numeric identifiers, linked to a (possiby changing) physical location of the phone terminal. The phone switch/router was a client of the external end-end directory, not a registration database. I.e. the directory layered ontop of the registrations. Now, as we know managing end-end public and large hub-spoke directories is hard - the accuracy problem being the hardest issue of all. And we all know the outcome of the IETF's X.500 adventure, and we all know that the only corporate critical, managed directories that are scaling AND getting adopted are based on LAN-discovery technology for saccess point knowledge distribution and trusted relationship setup (for secure services), rather than centrallised registration and administration. (Thanks Microsoft - you did it right, where many others did it wrong!) But, its in the convergence of directory practies where ENUM has its place and opportunity in the internet, I feel. While academically, its a cute theory about SIP/T.323 references (secure and insecure) and their discovery (trustworthy and not), its also about merging two cultures - the highly accurate PSTN directories and managed registration world, and the Internet's ability to enable third-parties to develop and deploy wide-area innovations ON TOP of that infrastructure without hindrance. What we have to contend with in IETF is that the registration business companies appear to wish to control ENUM deployment models through standards, WG scopes, etc - and they have fixed notions (and ongoing commercial wars) about the way those future management processes should work (given profit - a legitimate goal). While they properly represent the carrier community, (much to my chagrin) even VeriSign ignores its roots in end-end auto-managed PKI and focuses on centralized (and covert escrowed) mandatory registrations. I.E. the very property (end-end, auto-managing systems - like unregistered SSL certs) which is necessary for the next internet service adoption phenomenon to occur, is the one that is being downplayed or even ignored. We have to see evidence of strong end-end ENUM adoption for ENUM to proceed up the standards track. The easiest way of generating this would be for the carrier/registration lobby to show it supports this pattern - perhaps even that it actively fosters its deployment and adoption. 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 mhammer@cisco.com Thu, 17 Jun 2004 14:12:11 -0400 From: Mike Hammer Date: Thu, 17 Jun 2004 14:12:11 -0400 To: "Fullbrook Kim (UK)" Subject: RE: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: <4.3.2.7.2.20040617131603.00b67e18@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Ummm... I think I missed the discussion about opt-in on the IP address space. If that sounds strange, it shouldn't. The point is that any address space to be useful, it is reachable one way or the other. As those with IP addresses, telephone numbers, and email addresses are painfully aware, having an "unlisted" address does not stop trouble-makers from either: a) war-dialing/scanning to find you, or b) collecting names/numbers/addresses the minute you communicate with others. At least to some extent, an E.164 number is somewhat anonymous and give little information other than perhaps what large geographic region you are located in, and even that is not always accurate. I think that the privacy laws and application should focus on the really important things to keep private. I don't think the E.164 domains/ENUM should be part of that. The real issue for privacy is how much information is in the public directory and how does one access that. Much that should be private could fall into the domain of Presence, where anyone can SUBSCRIBE, but individual policies decide whether to even answer or not, and if so, with what information. Best to keep Presence and ENUM orthogonal. If you don't want to opt-in to ENUM (to include being in private carrier ENUM), don't waste an E.164 number on an IP endpoint. Mike At 11:19 AM 6/17/2004 +0100, Fullbrook Kim (UK) wrote: I would support the assertion below. Saying the same thing in another way, there are basic privacy concerns about putting "personal" information such as SIP URIs and telephone numbers in the public DNS and for those of us in the European Union this has to be "opt in". On the other hand certain telephony services might rely on everyone having their ENUM information available in the DNS. If someone opts out because of privacy concerns the service breaks for that customer. The implication is that only Carrier ENUM - where this personal information is not publicly available - is going to be viable. Even then there are questions over how someone could do a V-o-IP call from their PC on the Internet at home and make a successful call without running into these privacy concerns if the called party has not "opted in". Sorry if this is going over any old ground but I'm fairly new to ENUM. Kim. -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: 17 June 2004 10:53 To: james.f.baskin at verizon.com Cc: enum at ietf.org Subject: Re: [Enum] Re: User ENUM vs Operator ENUM (Edited) Another concern is user ENUM is going to have to be opt-in. The number doesn't go in the tree unless the "owner" consents. Operator or infrastructure ENUM has to work for every active number, including those people with unlisted numbers, test codes, preminum rate and free numbers, etc, etc. That means there can be no opt-in principle at work there. I fail to see how these mutually exclusive principles can be satisfied by having a single, public tree for both. ---------- ======================================================== This electronic message contains information from the mmO2 plc Group 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 jseng@pobox.org.sg Thu, 17 Jun 2004 19:46:15 -0400 From: James Seng Date: Thu, 17 Jun 2004 19:46:15 -0400 To: enum at ietf.org Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: <11173.1087465985@gromit.rfc1035.com> Message-ID: <200406180731.07167.jseng@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R On 17 June 2004 pm 17:53, Jim Reid wrote: > How could that be implemented in the DNS? It's a only lookup service > and doesn't have any hooks for implementing policy. then shouldnt we consider how it can be done? there are specific requests for ACL in ENUM. So either we meet the user requirements or the users look for something else. > Another concern is user ENUM is going to have to be opt-in. The number > doesn't go in the tree unless the "owner" consents. Operator or > infrastructure ENUM has to work for every active number, including > those people with unlisted numbers, test codes, preminum rate and free > numbers, etc, etc. That means there can be no opt-in principle at work > there. I fail to see how these mutually exclusive principles can be > satisfied by having a single, public tree for both. I think we should not consider protecting the "privacy" of an SIP/H.323 identifiers, and thats what we put into ENUM. What we do need to protect are the user identity-information that is associated to the ENUM or SIP/H.323 identifiers. This is analogous to the 'private number' concept, where you dont get published in a yellowpage but calling your number (by pure luck or wardialing) will still reach you nevertheless. -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Thu, 17 Jun 2004 19:57:52 -0400 From: Jeff Williams Date: Thu, 17 Jun 2004 19:57:52 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: <40D24699.69417BFE@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Yes you are going over old ground here, but also ground that is and has been contentious as well as not solved. I agree with your concern and evaluation in your remarks below. However many on this forum do not believe stakeholders/users should be able to have opt-in or any control of their own privacy regarding ENUM or for that matter DNS data records that are related... Fullbrook Kim (UK) wrote: > I would support the assertion below. Saying the same thing in > another way, > there are basic privacy concerns about putting "personal" information > such > as SIP URIs and telephone numbers in the public DNS and for those of > us in > the European Union this has to be "opt in". On the other hand certain > > telephony services might rely on everyone having their ENUM > information > available in the DNS. If someone opts out because of privacy concerns > the > service breaks for that customer. The implication is that only > Carrier ENUM > - where this personal information is not publicly available - is going > to be > viable. Even then there are questions over how someone could do a > V-o-IP > call from their PC on the Internet at home and make a successful call > without running into these privacy concerns if the called party has > not > "opted in". > > Sorry if this is going over any old ground but I'm fairly new to ENUM. > > Kim. > > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: 17 June 2004 10:53 > To: james.f.baskin at verizon.com > Cc: enum at ietf.org > Subject: Re: [Enum] Re: User ENUM vs Operator ENUM > > (Edited) > > Another concern is user ENUM is going to have to be opt-in. The number > > doesn't go in the tree unless the "owner" consents. Operator or > infrastructure ENUM has to work for every active number, including > those people with unlisted numbers, test codes, preminum rate and free > > numbers, etc, etc. That means there can be no opt-in principle at work > > there. I fail to see how these mutually exclusive principles can be > satisfied by having a single, public tree for both. > > > > - > --------------------------------------------------------------------- > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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. > ======================================================== > > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Thu, 17 Jun 2004 19:57:54 -0400 From: James Seng Date: Thu, 17 Jun 2004 19:57:54 -0400 To: enum at ietf.org Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: <200406180749.15996.jseng@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R When people talks about privacy, we must understand what specifically are you trying to protect? In the aspect of privacy, there are a concept of roles and identity. Each person have multiple roles which they are associated with others, each role is associated to an identity, which may have a set of communication identitiers. For example, in the role of IETFer, I am known as (James Seng) and I uses a set of communication identifiers like this email address, phone/enum +6596387085, etc. In the role of IDA staff, I am known as AD(ENAT) and I use another set of communication identifiers (which i wont disclose here). In the role of as a patient to my doctor, I may go by another name or patient ID, uses another set of communication identitifers. I may have other roles and identity which I dont want to disclose. Privacy is invaded when it is possible to identify you from a identity of one role with another role, ie, if you are able to use my email address, to track to my name James Seng in the role as an IETFer and get accesss to my information in other roles (ie as a patient to my doc). Now, looking at what we put into NAPTR RR. It is basically a # (an identifier) associated with a SIP/H323 address (another identifier). A NAPTR RR that points 5.4.3.2.1.e164.arpa to sip:12345 at sip.company.com does not say anything about the person nor the role. ENUM is *not a yellowpage*. It shouldn't tell you the name of the person, who he is, what his title, etc etc. We must understand (and able to explain to the privacy advocates) that a mappings of communication identifiers does not violate privacy, as much as telcos route phone call to you no matter who calls you or how they got the number. ps: Of course, there are concerns where people can query your ENUM hence obtain your SIP address to hassle you. This is very much like a concern about telemarketing wardialing your private number. Sorry, but the telcos cant do it and neither can ENUM. -James Seng On 17 June 2004 pm 18:19, Fullbrook Kim (UK) wrote: > I would support the assertion below. Saying the same thing in another way, > there are basic privacy concerns about putting "personal" information such > as SIP URIs and telephone numbers in the public DNS and for those of us in > the European Union this has to be "opt in". On the other hand certain > telephony services might rely on everyone having their ENUM information > available in the DNS. If someone opts out because of privacy concerns the > service breaks for that customer. The implication is that only Carrier > ENUM - where this personal information is not publicly available - is going > to be viable. Even then there are questions over how someone could do a > V-o-IP call from their PC on the Internet at home and make a successful > call without running into these privacy concerns if the called party has > not "opted in". > > Sorry if this is going over any old ground but I'm fairly new to ENUM. > > Kim. > > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: 17 June 2004 10:53 > To: james.f.baskin at verizon.com > Cc: enum at ietf.org > Subject: Re: [Enum] Re: User ENUM vs Operator ENUM > > (Edited) > > Another concern is user ENUM is going to have to be opt-in. The number > doesn't go in the tree unless the "owner" consents. Operator or > infrastructure ENUM has to work for every active number, including > those people with unlisted numbers, test codes, preminum rate and free > numbers, etc, etc. That means there can be no opt-in principle at work > there. I fail to see how these mutually exclusive principles can be > satisfied by having a single, public tree for both. > > > > ----------------------------------------------------------------------- > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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 jwkckid1@ix.netcom.com Thu, 17 Jun 2004 21:43:15 -0400 From: Jeff Williams Date: Thu, 17 Jun 2004 21:43:15 -0400 To: James Seng Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: <40D25F45.501AD630@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James and all, Much of what you state below in your remarks is true AS YOU STATED IT. But does not necessarily in any meaningful way address the whole of any ENUM using individual.. [ Specifics below James's comments/remarks ] James Seng wrote: > When people talks about privacy, we must understand what specifically are you > trying to protect? > > In the aspect of privacy, there are a concept of roles and identity. Each > person have multiple roles which they are associated with others, each role > is associated to an identity, which may have a set of communication > identitiers. Yes, and concept roles as well as identity must be in the hands of the user or in other words the users choice of what, how, whom and under what conditions both concept roles and specific identity information is decimated or available to anyone... > > > For example, in the role of IETFer, I am known as (James Seng) and I uses a > set of communication identifiers like this email address, phone/enum > +6596387085, etc. In the role of IDA staff, I am known as AD(ENAT) and I use > another set of communication identifiers (which i wont disclose here). In the > role of as a patient to my doctor, I may go by another name or patient ID, > uses another set of communication identitifers. I may have other roles and > identity which I dont want to disclose. > > Privacy is invaded when it is possible to identify you from a identity of one > role with another role, ie, if you are able to use my email address, to track > to my name James Seng in the role as an IETFer and get accesss to my > information in other roles (ie as a patient to my doc). Not a very good example here James. But one that is in the extreme in regards to role vs identity. If you or anyone chooses not to be readily identified by role to your name via sip, than you or anyone should have that choice and level of control. Under the current proposed scheme for ENUM DNS records, you don't have that control, hence tracking and stalking is indeed not only possible but likely and damage that can occur from said tracking/stalking can be translated into identity theft far to easily and without the user even knowing in time to limit or prevent damage to themselves... That is unexceptable and will no doubt be many times challenged in courts of law. Why than allow for such a risk to any user if additional protection can be technically effected to prevent or severely limit such occurrences?? > > > Now, looking at what we put into NAPTR RR. It is basically a # (an identifier) > associated with a SIP/H323 address (another identifier). A NAPTR RR that > points 5.4.3.2.1.e164.arpa to sip:12345 at sip.company.com does not say anything > about the person nor the role. Oh yes it does! It says that in your example that 12345 at sip.company.com is associated to an individual whom has a identity by a name. As company.com a domain name, is registered to a person and that person has a name, as well as all WHOIS records must now list a real persons correct name, than tracking further to other information about that individual person is easy from there forward. Hence adequate protections are not provided yet could easily be. Why aren't they? > > > ENUM is *not a yellowpage*. It shouldn't tell you the name of the person, who > he is, what his title, etc etc. We must understand (and able to explain to > the privacy advocates) that a mappings of communication identifiers does not > violate privacy, as much as telcos route phone call to you no matter who > calls you or how they got the number. > > > ps: Of course, there are concerns where people can query your ENUM hence > obtain your SIP address to hassle you. This is very much like a concern about > telemarketing wardialing your private number. Sorry, but the telcos cant do > it and neither can ENUM. Again incorrect, Telco's often provide agencies of various sorts as well as other individuals regularly. It is only that they often don't admit doing so and leave no record of doing so... > > > -James Seng > > On 17 June 2004 pm 18:19, Fullbrook Kim (UK) wrote: > > I would support the assertion below. Saying the same thing in another way, > > there are basic privacy concerns about putting "personal" information such > > as SIP URIs and telephone numbers in the public DNS and for those of us in > > the European Union this has to be "opt in". On the other hand certain > > telephony services might rely on everyone having their ENUM information > > available in the DNS. If someone opts out because of privacy concerns the > > service breaks for that customer. The implication is that only Carrier > > ENUM - where this personal information is not publicly available - is going > > to be viable. Even then there are questions over how someone could do a > > V-o-IP call from their PC on the Internet at home and make a successful > > call without running into these privacy concerns if the called party has > > not "opted in". > > > > Sorry if this is going over any old ground but I'm fairly new to ENUM. > > > > Kim. > > > > -----Original Message----- > > From: Jim Reid [mailto:jim at rfc1035.com] > > Sent: 17 June 2004 10:53 > > To: james.f.baskin at verizon.com > > Cc: enum at ietf.org > > Subject: Re: [Enum] Re: User ENUM vs Operator ENUM > > > > (Edited) > > > > Another concern is user ENUM is going to have to be opt-in. The number > > doesn't go in the tree unless the "owner" consents. Operator or > > infrastructure ENUM has to work for every active number, including > > those people with unlisted numbers, test codes, preminum rate and free > > numbers, etc, etc. That means there can be no opt-in principle at work > > there. I fail to see how these mutually exclusive principles can be > > satisfied by having a single, public tree for both. > > > > > > > > ----------------------------------------------------------------------- > > > > ======================================================== > > This electronic message contains information from the mmO2 plc Group > > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 18 Jun 2004 04:52:21 -0400 From: Jim Reid Date: Fri, 18 Jun 2004 04:52:21 -0400 To: James Seng Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: <200406180731.07167.jseng@pobox.org.sg> Message-ID: <13086.1087547695@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "James" == James Seng writes: >> How could that be implemented in the DNS? It's a only lookup >> service and doesn't have any hooks for implementing policy. James> then shouldnt we consider how it can be done? there are James> specific requests for ACL in ENUM. So either we meet the James> user requirements or the users look for something else. Yes, this is something the WG should consider IMO. Though it may be better if the WG looked at policy recommendations rather than how the policy gets implemented. James> I think we should not consider protecting the "privacy" of James> an SIP/H.323 identifiers, and thats what we put into James> ENUM. What we do need to protect are the user James> identity-information that is associated to the ENUM or James> SIP/H.323 identifiers. Hmmm. I think it would be wise to try and find out what could and should be protected before deciding what will be protected. Different countries have different approaches to privacy and data protection issues. A couple of ccTLDs have recently started a jihad in the dnsext WG about the privacy issues surrounding NSEC records for Secure DNS. [These allow the zone to be walked.] They are concerned about compilation copyright on the zone data and I suspect this issue might raise its ugly head in the context of ENUM. Even though zone enumeration is trivial with or without NSEC records. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Fri, 18 Jun 2004 04:59:16 -0400 From: James Seng Date: Fri, 18 Jun 2004 04:59:16 -0400 To: Jim Reid Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: <13086.1087547695@gromit.rfc1035.com> Message-ID: <40D2ABC1.40308@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R preciesly. dumping of zone files is a concerns generic to all DNS, so not just for ENUM. we in the ENUM WG, must be absolutely clear what can be done, what cannot be done, and how to explain why some thing just cannot be done (and actually it doesn't really matters) -James Seng Jim Reid wrote: "James" == James Seng writes: >> How could that be implemented in the DNS? It's a only lookup >> service and doesn't have any hooks for implementing policy. James> then shouldnt we consider how it can be done? there are James> specific requests for ACL in ENUM. So either we meet the James> user requirements or the users look for something else. Yes, this is something the WG should consider IMO. Though it may be better if the WG looked at policy recommendations rather than how the policy gets implemented. James> I think we should not consider protecting the "privacy" of James> an SIP/H.323 identifiers, and thats what we put into James> ENUM. What we do need to protect are the user James> identity-information that is associated to the ENUM or James> SIP/H.323 identifiers. Hmmm. I think it would be wise to try and find out what could and should be protected before deciding what will be protected. Different countries have different approaches to privacy and data protection issues. A couple of ccTLDs have recently started a jihad in the dnsext WG about the privacy issues surrounding NSEC records for Secure DNS. [These allow the zone to be walked.] They are concerned about compilation copyright on the zone data and I suspect this issue might raise its ugly head in the context of ENUM. Even though zone enumeration is trivial with or without NSEC records. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 18 Jun 2004 04:59:22 -0400 From: Jim Reid Date: Fri, 18 Jun 2004 04:59:22 -0400 To: James Seng Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <200406180749.15996.jseng@pobox.org.sg> Message-ID: <13107.1087548548@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "James" == James Seng writes: James> When people talks about privacy, we must understand what James> specifically are you trying to protect? Indeed. That's still unclear. James> ENUM is *not a yellowpage*. It shouldn't tell you the name James> of the person, who he is, what his title, etc etc. We must James> understand (and able to explain to the privacy advocates) James> that a mappings of communication identifiers does not James> violate privacy, as much as telcos route phone call to you James> no matter who calls you or how they got the number. This is naive. Once someone has an ENUM zone delegated to them, we have no idea what may be put there. With or without the user's consent. Clueless users (ie the overwhelming majority) will no doubt delegate zone content management to their service provider. The SP may do nasty things to lock out competitors but could also be publishing data that the customer considers private without the customer being aware that's happening. There are plenty of parallels for this. For instance the bozos who get supermarket loyalty cards don't realise their buying habits and lifestyle are getting analysed or the extent of the data mining that goes on. James> ps: Of course, there are concerns where people can query James> your ENUM hence obtain your SIP address to hassle you. This James> is very much like a concern about telemarketing wardialing James> your private number. Sorry, but the telcos cant do it and James> neither can ENUM. That's beside the point. If you someone puts their email address into their ENUM zone -- not an unreasonable thing to do -- they may not be aware that their address will be trivially harvested by spambots. Or how about the example I gave yesterday where I put something in my zone to reject inbound calls to my GSM number because I won't pay international roaming when I'm overseas? In other words, Jim's house is empty, so any burglars can come on down. There's a *lot* more to ENUM's privacy considerations than the advertisement (or not) of a phone number. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 18 Jun 2004 05:54:54 -0400 From: Jeff Williams Date: Fri, 18 Jun 2004 05:54:54 -0400 To: Jim Reid Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: <13086.1087547695@gromit.rfc1035.com> Message-ID: <40D2D26F.99FAF161@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, The IETF should be developing technical methods not just RFC's to meet current demand and future expected demand that will allow for different policies for DNS and this includes ENUM. Yes I have been spouting this idea for many years, and have been rebuffed many times as a result for who knows what real reasons... Jim Reid wrote: > >>>>> "James" == James Seng writes: > > >> How could that be implemented in the DNS? It's a only lookup > >> service and doesn't have any hooks for implementing policy. > > James> then shouldnt we consider how it can be done? there are > James> specific requests for ACL in ENUM. So either we meet the > James> user requirements or the users look for something else. > > Yes, this is something the WG should consider IMO. Though it may be > better if the WG looked at policy recommendations rather than how the > policy gets implemented. > > James> I think we should not consider protecting the "privacy" of > James> an SIP/H.323 identifiers, and thats what we put into > James> ENUM. What we do need to protect are the user > James> identity-information that is associated to the ENUM or > James> SIP/H.323 identifiers. > > Hmmm. I think it would be wise to try and find out what could and > should be protected before deciding what will be protected. Different > countries have different approaches to privacy and data protection > issues. A couple of ccTLDs have recently started a jihad in the dnsext > WG about the privacy issues surrounding NSEC records for Secure > DNS. [These allow the zone to be walked.] They are concerned about > compilation copyright on the zone data and I suspect this issue might > raise its ugly head in the context of ENUM. Even though zone > enumeration is trivial with or without NSEC records. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 18 Jun 2004 05:59:13 -0400 From: Jeff Williams Date: Fri, 18 Jun 2004 05:59:13 -0400 To: James Seng Subject: Re: [Enum] Re: User ENUM vs Operator ENUM In-Reply-To: <13086.1087547695@gromit.rfc1035.com> Message-ID: <40D2D2E1.16F2827E@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James and all, "Can't be done" is not in my technical vocabulary. If there is a will it can be done... James Seng wrote: > preciesly. dumping of zone files is a concerns generic to all DNS, so > not just for ENUM. > > we in the ENUM WG, must be absolutely clear what can be done, what > cannot be done, and how to explain why some thing just cannot be done > (and actually it doesn't really matters) > > -James Seng > > Jim Reid wrote: > > >>>>>>"James" == James Seng writes: > > > > > > >> How could that be implemented in the DNS? It's a only lookup > > >> service and doesn't have any hooks for implementing policy. > > > > James> then shouldnt we consider how it can be done? there are > > James> specific requests for ACL in ENUM. So either we meet the > > James> user requirements or the users look for something else. > > > > Yes, this is something the WG should consider IMO. Though it may be > > better if the WG looked at policy recommendations rather than how the > > policy gets implemented. > > > > James> I think we should not consider protecting the "privacy" of > > James> an SIP/H.323 identifiers, and thats what we put into > > James> ENUM. What we do need to protect are the user > > James> identity-information that is associated to the ENUM or > > James> SIP/H.323 identifiers. > > > > Hmmm. I think it would be wise to try and find out what could and > > should be protected before deciding what will be protected. Different > > countries have different approaches to privacy and data protection > > issues. A couple of ccTLDs have recently started a jihad in the dnsext > > WG about the privacy issues surrounding NSEC records for Secure > > DNS. [These allow the zone to be walked.] They are concerned about > > compilation copyright on the zone data and I suspect this issue might > > raise its ugly head in the context of ENUM. Even though zone > > enumeration is trivial with or without NSEC records. > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 18 Jun 2004 06:03:19 -0400 From: Jeff Williams Date: Fri, 18 Jun 2004 06:03:19 -0400 To: Jim Reid Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <13107.1087548548@gromit.rfc1035.com> Message-ID: <40D2D439.E5243B62@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, Well said Jim and exactly what I have tried to point out to James and others regarding ENUM as well as DNS or Whois records... Yet bulk look ups are highly sought by some segments of the corp. world for reasons that are not always accurately given as the real reason. Hence protection of the individual user must take precedence unless law enforcement has proper legal paperwork prior to accessing such information regarding individual users data. Jim Reid wrote: > >>>>> "James" == James Seng writes: > > James> When people talks about privacy, we must understand what > James> specifically are you trying to protect? > > Indeed. That's still unclear. > > James> ENUM is *not a yellowpage*. It shouldn't tell you the name > James> of the person, who he is, what his title, etc etc. We must > James> understand (and able to explain to the privacy advocates) > James> that a mappings of communication identifiers does not > James> violate privacy, as much as telcos route phone call to you > James> no matter who calls you or how they got the number. > > This is naive. Once someone has an ENUM zone delegated to them, we > have no idea what may be put there. With or without the user's > consent. Clueless users (ie the overwhelming majority) will no doubt > delegate zone content management to their service provider. The SP may > do nasty things to lock out competitors but could also be publishing > data that the customer considers private without the customer being > aware that's happening. There are plenty of parallels for this. For > instance the bozos who get supermarket loyalty cards don't realise > their buying habits and lifestyle are getting analysed or the extent > of the data mining that goes on. > > James> ps: Of course, there are concerns where people can query > James> your ENUM hence obtain your SIP address to hassle you. This > James> is very much like a concern about telemarketing wardialing > James> your private number. Sorry, but the telcos cant do it and > James> neither can ENUM. > > That's beside the point. If you someone puts their email address into > their ENUM zone -- not an unreasonable thing to do -- they may not be > aware that their address will be trivially harvested by spambots. Or > how about the example I gave yesterday where I put something in my > zone to reject inbound calls to my GSM number because I won't pay > international roaming when I'm overseas? In other words, Jim's house > is empty, so any burglars can come on down. There's a *lot* more to > ENUM's privacy considerations than the advertisement (or not) of a > phone number. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 18 Jun 2004 08:53:54 -0400 From: "Stastny Richard" Date: Fri, 18 Jun 2004 08:53:54 -0400 To: "Jim Reid" Subject: RE: [Enum] User ENUM vs Operator ENUM Message-ID: <06CF906FE3998C4E944213062009F162443778@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R > Jim Reid wrote: > That's beside the point. If you someone puts their email address into > their ENUM zone -- not an unreasonable thing to do -- they may not be > aware that their address will be trivially harvested by spambots. Or > how about the example I gave yesterday where I put something in my > zone to reject inbound calls to my GSM number because I won't pay > international roaming when I'm overseas? In other words, Jim's house > is empty, so any burglars can come on down. There's a *lot* more to > ENUM's privacy considerations than the advertisement (or not) of a > phone number. > [Richard>] This privacy discussion on ENUM always gets paranoic. As Wazlawik said: "You cannot not communicate" If you live in a real world, and want to communicate with Others, you always have to disclose privacy information. Take your GSM example: Turning on my mobile in London also discloses to anybody calling me that I am not at home, because of the ring-tone. In Hongkong they even sold a feature hiding China ring-tone. So if somebody puts an entry in ENUM, he wants to communicate. If he does not want to communicate, he should not put the information in. If he only puts a URI with the same or any number in, he is only disclosing that the number exists. This also can be found out by an automatic dialler, so what? Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 18 Jun 2004 09:10:32 -0400 From: Jim Reid Date: Fri, 18 Jun 2004 09:10:32 -0400 To: "Stastny Richard" Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <06CF906FE3998C4E944213062009F162443778@oefeg-s02.oefeg.loc> Message-ID: <13442.1087563602@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: Richard> So if somebody puts an entry in ENUM, he wants to Richard> communicate. If he does not want to communicate, he Richard> should not put the information in. If he only puts a URI Richard> with the same or any number in, he is only disclosing Richard> that the number exists. This also can be found out by an Richard> automatic dialler, so what? You and I know that. Someone like my mother won't. I think the WG can't simply ignore the privacy concerns that ENUM creates. This doesn't mean all of these concerns have to be solved: that's probably impossible. I do think the WG should produce some sort of document on the privacy issues, even if it's just to say "if you stick NAPTRs into your zone, this might release more information than you realise and that might result in unexpected, possibly unpleasant consequences". _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 18 Jun 2004 10:35:30 -0400 From: Mike Hammer Date: Fri, 18 Jun 2004 10:35:30 -0400 To: Jim Reid Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: Message-ID: <4.3.2.7.2.20040618100135.00b1d9d0@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I agree with the concept that making a phone number available, in and of itself, is not a privacy violation. What this thread seems to indicate is that other information can further be mapped from that through information technology (IT) means. I find the fact that people compile data on you to define a picture of who you are before they are willing to do business with you a fact of life, that like it or not, has always been, even before IT existed. It may be data that the operator needs to deliver your service. If you don't like that, find another operator. The issue seems to be that IT makes compiling this information so much easier by entities that 1) you don't know and don't want to know, and 2) without one's permission. This begs the question: Should the process at some point in the search require the searcher to submit a request, get an immediate "your request has been received" and maybe later get an affirmative response with details once the user whose record is attempting to be accessed has had a chance to approve release of further data? Without going into further detail, the answer may be simply to have the ENUM record point to the subscription address of the user, who then uses these presence-based mechanisms to decide what to release to the requester. So, I guess the question I am raising is whether this is a cross-WG issue? That is, if privacy becomes an issue, should ENUM not attempt to re-invent the same mechanisms that SIMPLE is defining? Mike At 02:00 PM 6/18/2004 +0100, Jim Reid wrote: >>>>> "Richard" == Stastny Richard writes: Richard> So if somebody puts an entry in ENUM, he wants to Richard> communicate. If he does not want to communicate, he Richard> should not put the information in. If he only puts a URI Richard> with the same or any number in, he is only disclosing Richard> that the number exists. This also can be found out by an Richard> automatic dialler, so what? You and I know that. Someone like my mother won't. I think the WG can't simply ignore the privacy concerns that ENUM creates. This doesn't mean all of these concerns have to be solved: that's probably impossible. I do think the WG should produce some sort of document on the privacy issues, even if it's just to say "if you stick NAPTRs into your zone, this might release more information than you realise and that might result in unexpected, possibly unpleasant consequences". _______________________________________________ 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 Kim.Fullbrook@O2.COM Fri, 18 Jun 2004 10:42:24 -0400 From: "Fullbrook Kim (UK)" Date: Fri, 18 Jun 2004 10:42:24 -0400 To: "'enum at ietf.org> Subject: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Status: R >> If you live in a real world, and want to communicate with >> Others, you always have to disclose privacy information. I see the underlying issue here being where and how widely that private information is disclosed. Drawing an analogy with basic PSTN landline service.  I'm not sure how it is in other countries but here in the UK you can choose to have your name and phone number included in the regional phone book or you can choose not to (and pay some money not to, but that's a different issue). If you're in the phone book any marketing company can look up your name & number and phone you up to try to sell you something.  (We also have an "opt out" system in the UK to stop unsolicited commercial phone calls but even though it should cut out these calls it does not always work). If I'm concerned about privacy I have a choice about opting out of the phone book and I can be careful who I give my business card to.  Here I am the customer and have control over privacy.  The danger is that an open ENUM DNS is a freely accessible "phone book" and I believe that Telecomms Regulators, especially in the EU would look unfavourably on this. Particularly if Presence and related messaging information was put in there - already we know that IM spam (spim) is a menace. There would have to be access controls and quickly the question becomes: why should anyone display their details except for businesses advertising in a Yellow Pages directory ? To me this is a completely different issue to that of "war dialling" phone numbers which you can never stop, except perhaps make more difficult by adding time delays or cost. The point is whether as a telecomms company you make available a list of your customers irrespective of the naming & addressing scheme used, because having a list means you are making life easier for the spammers and other undesirables. Sorry if this last point upsets someone but the only way forward which acknowledges privacy concerns seems to be "Operator ENUM" and not implementing open "User ENUM". ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 Richard.Stastny@oefeg.at Fri, 18 Jun 2004 11:37:58 -0400 From: "Stastny Richard" Date: Fri, 18 Jun 2004 11:37:58 -0400 To: "Fullbrook Kim (UK)" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1622B0641@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >Sorry if this last point upsets someone but the only way forward which >acknowledges privacy concerns seems to be "Operator ENUM" and not >implementing open "User ENUM". All discussions on ENUM is always ending with privacy issues and it is always circling around the same issues. So lets start over again: I originally said that User ENUM and iENUM are orthogonal, which means that the question is not User ENUM OR iENUM, but User ENUM AND iENUM. User ENUM is even better then the phone book, it is not opt-out, it is opt-in. I also do not like the approach all this privacy advocates have arguing you know this and I know this, but all others are morons and have to be protected. If you consider this further, nobody should be allowed anymore to connect his PC to the big, bad Internet because of course you and I know how to set up a firewall, but all other are morons and do not know how to do this. You finally end up removing all toothpicks in restaurants because somebody may not stick it in his mouth but in his ears or eyes, even if you print a warning on the wrapper not to do so, and then he may sue you. BTW, there is a warning in the RFC and there is also the privacy draft from our co-chair. Richard -----Original Message----- From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] Sent: Friday, June 18, 2004 4:20 PM To: 'enum at ietf.org' Subject: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) >> If you live in a real world, and want to communicate with >> Others, you always have to disclose privacy information. I see the underlying issue here being where and how widely that private information is disclosed. Drawing an analogy with basic PSTN landline service.  I'm not sure how it is in other countries but here in the UK you can choose to have your name and phone number included in the regional phone book or you can choose not to (and pay some money not to, but that's a different issue). If you're in the phone book any marketing company can look up your name & number and phone you up to try to sell you something.  (We also have an "opt out" system in the UK to stop unsolicited commercial phone calls but even though it should cut out these calls it does not always work). If I'm concerned about privacy I have a choice about opting out of the phone book and I can be careful who I give my business card to.  Here I am the customer and have control over privacy.  The danger is that an open ENUM DNS is a freely accessible "phone book" and I believe that Telecomms Regulators, especially in the EU would look unfavourably on this. Particularly if Presence and related messaging information was put in there - already we know that IM spam (spim) is a menace. There would have to be access controls and quickly the question becomes: why should anyone display their details except for businesses advertising in a Yellow Pages directory ? To me this is a completely different issue to that of "war dialling" phone numbers which you can never stop, except perhaps make more difficult by adding time delays or cost. The point is whether as a telecomms company you make available a list of your customers irrespective of the naming & addressing scheme used, because having a list means you are making life easier for the spammers and other undesirables. Sorry if this last point upsets someone but the only way forward which acknowledges privacy concerns seems to be "Operator ENUM" and not implementing open "User ENUM". ======================================================== This electronic message contains information from the mmO2 plc Group 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 jseng@pobox.org.sg Fri, 18 Jun 2004 11:54:44 -0400 From: James Seng Date: Fri, 18 Jun 2004 11:54:44 -0400 To: enum at ietf.org Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <200406182345.54699.jseng@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R Repeat after me: ENUM is not a yellowpage. On 18 June 2004 pm 22:19, Fullbrook Kim (UK) wrote: > >> If you live in a real world, and want to communicate with > >> Others, you always have to disclose privacy information. > > I see the underlying issue here being where and how widely that private > information is disclosed. > > Drawing an analogy with basic PSTN landline service. I'm not sure how it > is in other countries but here in the UK you can choose to have your name > and phone number included in the regional phone book or you can choose not > to (and pay some money not to, but that's a different issue). If you're in > the phone book any marketing company can look up your name & number and > phone you up to try to sell you something. (We also have an "opt out" > system in the UK to stop unsolicited commercial phone calls but even though > it should cut out these calls it does not always work). > > If I'm concerned about privacy I have a choice about opting out of the > phone book and I can be careful who I give my business card to. Here I am > the customer and have control over privacy. The danger is that an open > ENUM DNS is a freely accessible "phone book" and I believe that Telecomms > Regulators, especially in the EU would look unfavourably on this. > Particularly if Presence and related messaging information was put in there > - already we know that IM spam (spim) is a menace. There would have to be > access controls and quickly the question becomes: why should anyone display > their details except for businesses advertising in a Yellow Pages directory > ? > > To me this is a completely different issue to that of "war dialling" phone > numbers which you can never stop, except perhaps make more difficult by > adding time delays or cost. The point is whether as a telecomms company you > make available a list of your customers irrespective of the naming & > addressing scheme used, because having a list means you are making life > easier for the spammers and other undesirables. Sorry if this last point > upsets someone but the only way forward which acknowledges privacy concerns > seems to be "Operator ENUM" and not implementing open "User ENUM". > > > > > ----------------------------------------------------------------------- > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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 clive@demon.net Fri, 18 Jun 2004 12:50:30 -0400 From: "Clive D.W. Feather" Date: Fri, 18 Jun 2004 12:50:30 -0400 To: Jim Reid Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: <20040615104409.GA9951@finch-staff-1.thus.net> Message-ID: <20040618163724.GH44298@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid said: > Clive> But it's a kludge, and it won't do everything that Operator > Clive> ENUM will need. > > Please elaborate. What are the things Operator ENUM will need that > can't be achieved with a private instance of e164.arpa but could be > achieved with some other domain name? The ability to conveniently and easily have both Operator-owned and User-owned records for the same phone number. The split DNS would be a nightmare for this. Far better to put them into separate trees. > Just because the domain name for > Operator and User ENUM could/should be the same IMO, it doesn't follow > that they have to use the same infrastructure or administrative models. You seem to be assuming that the operators will never need to see the user records. You are wrong. > Yes, split DNS is a kludge. But there doesn't seem to be a better > solution IMO. Separate trees is a better solution. > Clive> Why not put Operator ENUM in op.e164.arpa? Use the same > Clive> layout as for public ENUM. > > Suppose I'm a developer of some ENUM-aware VoIP application that talks > to SIP servers. I sell this to telcos, enterprises and end users. How > is the software to know which domain name to use depending on where my > customers are using it today? And might use it tomorrow, which could > be somewhere different... It's part of configuring the software, of course. You aren't going to hardwire e164.arpa into the code, are you? Apart from anything else, the ability to change the base of the tree will be vital for testing purposes. -- 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 clive@demon.net Fri, 18 Jun 2004 12:50:35 -0400 From: "Clive D.W. Feather" Date: Fri, 18 Jun 2004 12:50:35 -0400 To: Richard Shockey Subject: Re: AW: [Enum] Please start thinking about agenda items for IETFSanDiego etc In-Reply-To: Message-ID: <20040618163909.GI44298@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard Shockey said: >>> The same model could be used for e164.arpa: eg a telco or >>> enterprise has its own e164.arpa tree for internal use only. >> Why not put Operator ENUM in op.e164.arpa? Use the same layout as for >> public ENUM. > Because carriers do not want to expose their internal routing data to the > global internet. What's that got to do with it? Putting it into a different tree doesn't mean they have to expose it. On the contrary, it makes hiding the Operator ENUM data *easier*. > The essential distinguishing feature of public vs infrastructure ENUM is > its visibality. Wrong. The essential distinguishing feature is what the data is used for. > If consumers or enterprises, for what ever reason OPT-OUT of e164.arpa , or > the politics cant be fixed as in the case of +1, then we are collectively > stuck with default PSTN routing indefinitely and that is not acceptable. And that has nothing to do with separate trees. -- 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 jwkckid1@ix.netcom.com Sat, 19 Jun 2004 01:23:49 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 01:23:49 -0400 To: Stastny Richard Subject: Re: [Enum] User ENUM vs Operator ENUM In-Reply-To: <06CF906FE3998C4E944213062009F162443778@oefeg-s02.oefeg.loc> Message-ID: <40D3E54C.3BEB9EFE@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > > Jim Reid wrote: > > That's beside the point. If you someone puts their email address into > > their ENUM zone -- not an unreasonable thing to do -- they may not be > > aware that their address will be trivially harvested by spambots. Or > > how about the example I gave yesterday where I put something in my > > zone to reject inbound calls to my GSM number because I won't pay > > international roaming when I'm overseas? In other words, Jim's house > > is empty, so any burglars can come on down. There's a *lot* more to > > ENUM's privacy considerations than the advertisement (or not) of a > > phone number. > > > [Richard>] > This privacy discussion on ENUM always gets paranoic. Yes it often does. Unfortunately the paranoia is often on the side of those that don't wish to take the responsibility or taking the available steps in protecting private information using already available technical means, to put it simply. > > > As Wazlawik said: "You cannot not communicate" > > If you live in a real world, and want to communicate with > Others, you always have to disclose privacy information. Terms like "Always" and "Never" are absolutes. They are not reasonable to be used in the real world and a world where technically available means to protect personal and private information such as an ENUM number listing in DNS records is easily possible and can be done. > > > Take your GSM example: Turning on my mobile in London also > discloses to anybody calling me that I am not at home, because > of the ring-tone. In Hongkong they even sold a feature hiding > China ring-tone. And my cell phone that I have for China I can set the caller-id to on or off and in doing so protect my privacy at that level. > > > So if somebody puts an entry in ENUM, he wants to communicate. > If he does not want to communicate, he should not put the information > in. This is overly simplistic and incorrect as stated. Any ENUM entry can be "not listed" as to available to operator access or anyone else's access to that data element. > If he only puts a URI with the same or any number in, he is > only disclosing that the number exists. This also can be found > out by an automatic dialler, so what? > > Richard > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 19 Jun 2004 01:32:27 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 01:32:27 -0400 To: "Fullbrook Kim (UK)" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40D3E898.EAD0F7CC@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Fullbrook Kim (UK) wrote: > >> If you live in a real world, and want to communicate with > >> Others, you always have to disclose privacy information. > > I see the underlying issue here being where and how widely that > private > information is disclosed. Yes this is indeed part of the issue. But only part. Those that wish to control your privacy level is being undermined using a lack of willingness and policy making of technical standards tracks. > > > Drawing an analogy with basic PSTN landline service. I'm not sure how > it is > in other countries but here in the UK you can choose to have your name > and > phone number included in the regional phone book or you can choose not > to > (and pay some money not to, but that's a different issue). This is also true in the US and many other countries. > If you're in the > phone book any marketing company can look up your name & number and > phone > you up to try to sell you something. (We also have an "opt out" > system in > the UK to stop unsolicited commercial phone calls but even though it > should > cut out these calls it does not always work). In the US we also now have a similar option. Yet is seems with some within the IETF with ENUM and VOIP, there is a resistance to allow for stakeholders/users to make that sort of decision for themselves indicating that either users are not really able to make such decisions for themselves and still utilize the technology of ENUM and VOIP or that the laziness of really not very difficult technical capability or providing for non-listed ENUM numbers as part of the standard proposed. > > > If I'm concerned about privacy I have a choice about opting out of the > phone > book and I can be careful who I give my business card to. Here I am > the > customer and have control over privacy. The danger is that an open > ENUM DNS > is a freely accessible "phone book" and I believe that Telecomms > Regulators, > especially in the EU would look unfavourably on this. And the US as well and a number of other western nations such as Canada will also look very unfavorably upon not having the same of similar ability to opt-out with ENUM. > Particularly if > Presence and related messaging information was put in there - already > we > know that IM spam (spim) is a menace. There would have to be access > controls > and quickly the question becomes: why should anyone display their > details > except for businesses advertising in a Yellow Pages ? Good question. > > > To me this is a completely different issue to that of "war dialling" > phone > numbers which you can never stop, except perhaps make more difficult > by > adding time delays or cost. The point is whether as a telecomms > company you > make available a list of your customers irrespective of the naming & > addressing scheme used, because having a list means you are making > life > easier for the spammers and other undesirables. Sorry if this last > point > upsets someone but the only way forward which acknowledges privacy > concerns > seems to be "Operator ENUM" and not implementing open "User ENUM". > > > > > - > --------------------------------------------------------------------- > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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. > ======================================================== > > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 19 Jun 2004 01:40:56 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 01:40:56 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1622B0641@oefeg-s02.oefeg.loc> Message-ID: <40D3E9E4.FD583ADC@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > >Sorry if this last point upsets someone but the only way forward which >acknowledges privacy concerns seems to be "Operator ENUM" and not >implementing open "User ENUM". > > All discussions on ENUM is always ending with privacy issues and > it is always circling around the same issues. > > So lets start over again: > > I originally said that User ENUM and iENUM are > orthogonal, which means that the question is not User ENUM OR > iENUM, but User ENUM AND iENUM. > > User ENUM is even better then the phone book, it is not opt-out, > it is opt-in. And this to a very great degree is what is wrong with the standards track with ENUM. Both opt-in and Opt-out should be incorporated. > > > I also do not like the approach all this privacy advocates > have arguing you know this and I know this, but all others > are morons and have to be protected. > > If you consider this further, nobody should be allowed > anymore to connect his PC to the big, bad Internet because > of course you and I know how to set up a firewall, but all > other are morons and do not know how to do this. Firewalls are by no means a good protection in some to many specific intrusions of privacy. > > > You finally end up removing all toothpicks in restaurants > because somebody may not stick it in his mouth but in his ears > or eyes, even if you print a warning on the wrapper not to do > so, and then he may sue you. > > BTW, there is a warning in the RFC and there is also the > privacy draft from our co-chair. > > Richard > > -----Original Message----- > From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] > Sent: Friday, June 18, 2004 4:20 PM > To: 'enum at ietf.org' > Subject: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > >> If you live in a real world, and want to communicate with > >> Others, you always have to disclose privacy information. > I see the underlying issue here being where and how widely that private information is disclosed. > Drawing an analogy with basic PSTN landline service. I'm not sure how it is in other countries but here in the UK you can choose to have your name and phone number included in the regional phone book or you can choose not to (and pay some money not to, but that's a different issue). If you're in the phone book any marketing company can look up your name & number and phone you up to try to sell you something. (We also have an "opt out" system in the UK to stop unsolicited commercial phone calls but even though it should cut out these calls it does not always work). > If I'm concerned about privacy I have a choice about opting out of the phone book and I can be careful who I give my business card to. Here I am the customer and have control over privacy. The danger is that an open ENUM DNS is a freely accessible "phone book" and I believe that Telecomms Regulators, especially in the EU would look unfavourably on this. Particularly if Presence and related messaging information was put in there - already we know that IM spam (spim) is a menace. There would have to be access controls and quickly the question becomes: why should anyone display their details except for businesses advertising in a Yellow Pages directory ? > To me this is a completely different issue to that of "war dialling" phone numbers which you can never stop, except perhaps make more difficult by adding time delays or cost. The point is whether as a telecomms company you make available a list of your customers irrespective of the naming & addressing scheme used, because having a list means you are making life easier for the spammers and other undesirables. Sorry if this last point upsets someone but the only way forward which acknowledges privacy concerns seems to be "Operator ENUM" and not implementing open "User ENUM". > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 19 Jun 2004 01:40:57 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 01:40:57 -0400 To: James Seng Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40D3EA59.830F24E6@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James and all, Right! It is becoming if the current standards track goes on unchecked, the White Pages and you as a user MUST be listed in it. James Seng wrote: > Repeat after me: ENUM is not a yellowpage. > > On 18 June 2004 pm 22:19, Fullbrook Kim (UK) wrote: > > >> If you live in a real world, and want to communicate with > > >> Others, you always have to disclose privacy information. > > > > I see the underlying issue here being where and how widely that private > > information is disclosed. > > > > Drawing an analogy with basic PSTN landline service. I'm not sure how it > > is in other countries but here in the UK you can choose to have your name > > and phone number included in the regional phone book or you can choose not > > to (and pay some money not to, but that's a different issue). If you're in > > the phone book any marketing company can look up your name & number and > > phone you up to try to sell you something. (We also have an "opt out" > > system in the UK to stop unsolicited commercial phone calls but even though > > it should cut out these calls it does not always work). > > > > If I'm concerned about privacy I have a choice about opting out of the > > phone book and I can be careful who I give my business card to. Here I am > > the customer and have control over privacy. The danger is that an open > > ENUM DNS is a freely accessible "phone book" and I believe that Telecomms > > Regulators, especially in the EU would look unfavourably on this. > > Particularly if Presence and related messaging information was put in there > > - already we know that IM spam (spim) is a menace. There would have to be > > access controls and quickly the question becomes: why should anyone display > > their details except for businesses advertising in a Yellow Pages directory > > ? > > > > To me this is a completely different issue to that of "war dialling" phone > > numbers which you can never stop, except perhaps make more difficult by > > adding time delays or cost. The point is whether as a telecomms company you > > make available a list of your customers irrespective of the naming & > > addressing scheme used, because having a list means you are making life > > easier for the spammers and other undesirables. Sorry if this last point > > upsets someone but the only way forward which acknowledges privacy concerns > > seems to be "Operator ENUM" and not implementing open "User ENUM". > > > > > > > > > > ----------------------------------------------------------------------- > > > > ======================================================== > > This electronic message contains information from the mmO2 plc Group > > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 19 Jun 2004 02:33:44 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 02:33:44 -0400 To: enum Subject: [Enum] Privacy Demands Could Hamper Cell Phone Directory - Is ENUM facing the same? Message-ID: <40D3F727.8256A86B@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R All, As Kim had made reference to in one of her earlier posts it seems that perhaps and IMHO even likely that ENUM may be facing a serious challenge to what the current standards track seems to be indicating as the cell phone directory effort is. See:http://www.mobilepipeline.com/showArticle.jhtml?articleID=22100693 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 19 Jun 2004 09:15:39 -0400 From: "Stastny Richard" Date: Sat, 19 Jun 2004 09:15:39 -0400 To: "Jeff Williams" Subject: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jeff Williams writes: >And this to a very great degree is what is wrong with the standards >track with ENUM. Both opt-in and Opt-out should be incorporated. They did. The ENUM protocol as defined in IETF can be implemented in both ways, athough NOT in the same tree, because the both options are mutually exclusive. Let me explain: Opt-in means that at the beginning nobody is in and the end-user decides if he wants to be in to get this service. This is the case with User ENUM, which is an add-on service. The underlying service is his phone service and this phone service is working regadless if he is in ENUM or not (with the exception of ENUM-enable numbers, which are operating only if you are in User ENUM, but nobody is forced to use these numbers) The end-user has the additional choice how much information he discloses: the minimum requirement is the number itself and the operator, if he puts in e.g. sip:+43xxx at provider.net. Additional information between caller and callee may be exchanges via negotiation between servers (as in SIP) or Personal User Agents as proposed in UCI. The end-user may also decide on his discretion to put in more information as he likes, especially a company. Opt-out would mean that everybody is in and the end-user decides not to be in. If a provider decides to implement the basic communication service based on ENUM, he MUST put all users using this service in ENUM. Using ENUM for a service is currently also opt-in, but for the provider as a whole with all of his numbers. There is no opt-out for the individual end-user. This is called Infrastructure ENUM. It uses ENUM technology, but in separate tree. It is opt-in currently because there is still the PSTN around to reach providers not in Infrastructure ENUM by default. If the PSTN ceases to exists at some point of time, another default method need to be defined if E.164 numbering is still around. This may be ENUM or maybe not. Up to this point of time, different trees may be used by different groups of service providers (confederation), this is already happening. A service provider may even participate in different trees at the same time. These trees may either be trees only accessible by participants of the confederation (either in extranets or with access control), but not on the public Internet, or if accessible by the public, the information is either not accessible, encrypted or useless for the normal end-user. There is also a difference between the information contained in the trees. In User ENUM the information points to end-points, giving one ore more URIs where the end-user has his services. Different NAPTRs may point to different service providers. The domain name holder is the end-user. In Infrastructure ENUM the entry points in principle to the destination network providing the service for this number. The domain name holder is the service provider. All this together precludes User ENUM and Infrastructure ENUM to be in the same tree (even the delegation structure may be differnent). Of course User ENUM and Infrastructure ENUM may co-exist, any user listed in one or more Infrastructure trees may also request an entry in User ENUM. The provider may also offer to the calling customer a service in such a way that first User ENUM queried and then Infrastructure ENUM. This is already implemented in some SIP servers and works. (Note: why should the provider do this? Because the user may do this by himself also. It is kinda carrier selection ;-) ETSI is currently drafting a TS 102 055 on Infrastructure ENUM explaining all these issues. BTW: there is one complication emerging at the moment: Confederations also want Infrastructure ENUM to be used for routing of transit calls, e.g. an provider is publishing number ranges in a confederation tree he is serving on the PSTN with his gateways. This is in principle feasable, but will cause serious problems in the future, especially if two confederations decide to merge there trees. If one numbers are entered by providers which are assigned to them, no conflicts could arise if trees are merged. If numbers are entered by providers not assigned to them, this will cause policy problems and conflicts. These conflicts cannot be resolved in ENUM, because it is not designed for it. Other protocols like TRIP or OSP should be used for this. Richard: To Jeff: You know what my problem with all privacy advocates is? They are trespassing my privacy by trying to limit my freedom of decision, including my human right to make idiotic decisions ;-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Sat, 19 Jun 2004 10:18:26 -0400 From: "Christian de Larrinaga" Date: Sat, 19 Jun 2004 10:18:26 -0400 To: "Fullbrook Kim (UK)" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Fullbrook Kim (UK)Sent: 18 June 2004 15:20 >the only way forward which acknowledges privacy concerns seems to be "Operator ENUM" and >not implementing open "User ENUM". Well perhaps for your company but I don't believe this is a general observation applicable to all. Privacy concerns as other operational issues differ between Operator and direct user usage of ENUM. These stem from the different ambitions for ENUM use and of course the existant regulatory frameworks that govern operators and of users themselves. Christian de Larrinaga _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 19 Jun 2004 11:22:21 -0400 From: "Stastny Richard" Date: Sat, 19 Jun 2004 11:22:21 -0400 To: Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F162443780@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Christian de Larrinaga [mailto:cdel at firsthand.net] writes: >Fullbrook Kim (UK)Sent: 18 June 2004 15:20 >>the only way forward which acknowledges privacy concerns seems to be >>"Operator ENUM" and not implementing open "User ENUM". >Well perhaps for your company but I don't believe this is a general >observation applicable to all. >Privacy concerns as other operational issues differ between Operator and >direct user usage of ENUM. These stem from the different ambitions for ENUM >use and of course the existant regulatory frameworks that govern operators >and of users themselves. Fully agree And to Kim: how and by whom should this decision be made? IETF is not involved in this dicussion policy-wise and could "decide" by humming only anyway; there is no voting. Regulators can only decide on user ENUM by not opting in for their country. Regulators have no say in infrastructure ENUM, because this is a sole decision of the providers joining a confederation. Confeds could also choose any tree they jointly decide upon, it is not necessary to do it in a TLD. .tel is a mock attack. BTW: this could be an advantage for Infrastructure ENUM, so regulators watch out ;-) So let's implement both and let the market decide. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sat, 19 Jun 2004 12:18:09 -0400 From: Richard Shockey Date: Sat, 19 Jun 2004 12:18:09 -0400 To: enum at ietf.org Subject: [Enum] A note from your chairs on the Agenda for IETF 60 including this discussion on Carrier ENUM Message-ID: <6.1.0.6.2.20040618111142.022fe280@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R The chairs and the AD'd have had several communications on what should be the next steps for this discussion. It was our collective consensus that giving timing and the availability of slots it would not be a practical idea to attempt to schedule a separate BOF on the discussion of Carrier ENUM. Consequently what we propose to do is split the 2 hour meeting time into 2 1 hour parts. (I was unable to secure one of the 2 1/2 hour slots). The first hour will be devoted to normal business including the discussion items we have already identified which Patrik and I will chair in the normal manner. The second hour will then shift to a discussion of Carrier - Infrastructure ENUM ( what ever you want to call it ) That discussion will be led by James Seng and Richard Stastny with myself providing continuity and context to the existing work. Individuals wishing to make formal ID contributions and or requesting time to speak on Carrier ENUM discussions are requested to get your ID documentation in a soon a possible and request time from the mini-BOF chairs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 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 home_pw@msn.com Sat, 19 Jun 2004 12:39:37 -0400 From: "Peter Williams" Date: Sat, 19 Jun 2004 12:39:37 -0400 To: jwkckid1 at ix.netcom.com Subject: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard: To Jeff: You know what my problem with all privacy advocates is? They are trespassing my privacy by trying to limit my freedom of decision, including my human right to make idiotic decisions ;-) You perhaps not living in the US, where many corporate privacy policies exist (in fact are essentially mandated, with those who violate their required freedom of choice of publish or not being punished by their insurers). While policy publication is effecitvely mandator, the policies are based on a big lie - one that actively deceives most users. Liberty and Freedom having different meanings in Europe from US: privacy is libertarian ideal protected by rights in the US, but you must assert them in the US for them to have any value. You must assert the expectation of privacy, and maintain evidence of the currency of that expectation to deter your counterarguer from asserting laches - the doctrine that make your older assertion valueless at the time the telco (or other party) violates its own rules. If for example you do not read the privacy policy of //.com, you cannot assert your process rights to hold the company accountable to its policy - assuming the policy has any accountability rules to start with. And how many American users read it? Thus, how many Americans have any recourse in practice? This is privacy marketing at its best. Perfectly reasonable way of making money ; sell the assurance of privacy, but provide 20% functionality for 80% of users. So lets see what we can do better in IETF, for the wider internet culture that also addresses European and Asian ways of thinking about privacy - which may have different obligations. E2U maps {numeric descriptor -> set of URIs.} where the tel class URI allows one to rewrite the descriptor, and thus restart the resolver at a new discovery point better turned to the architecture of that redirected numbering scheme. And the URI can include https URLs, where the agent initiating privacyE2U can access a W3C capability/privacy policy in (Signed) XML, and the agent can access the SSL-layers negotiation of telematic communication requirements via the certificates exhanged in a realtime handshake with the user's policy server, according to IETF standards. Having established these parameters, neither XML or SSL need to be used further in delivering an actual telematic service once the E2U service completes. So, we have in ENUM, via URI/URL resolution, all the mechanism we need for 2 layer privacy enhancement of ENUM (PEEM WG?). SO lets start thinking about this for the BOF. We have via the W3C work the means of showing and involving users in setting up the privacy practices for a T.323 conference, so there n expectation and restriction policies can be resolved as a part of the DNS-based E2U discovery process; and we have the secure handshake of SSL which identifies the security association requirements than can parameterize the T.120 proxies the users invoke subsequently in order to commute the numeric descriptor into an actual telematic session via an instance of infrastructure ENUM for T.120 switches. Peter. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 19 Jun 2004 13:20:46 -0400 From: "Stastny Richard" Date: Sat, 19 Jun 2004 13:20:46 -0400 To: "Peter Williams" Subject: AW: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F162443783@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R NO, I am not living in the US. I will need some time to parse what you are proposing, just a question upfront: are you serious? I first thought you are proposing to route each call to an US citizen through a lawyer (CFtoL) e.g. if I call you I get an annoncement: "Talk to my lawyer first" On the other hand I like your idea to replace US lawyers by BOTs ;-) regards Richard -----UrsprĂngliche Nachricht----- Von: Peter Williams [mailto:home_pw at msn.com] Gesendet: Sa 19.06.2004 18:31 An: Stastny Richard; jwkckid1 at ix.netcom.com Cc: enum at ietf.org Betreff: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) >Richard: >To Jeff: You know what my problem with all privacy advocates is? > >They are trespassing my privacy by trying to limit my freedom of decision, >including my human right to make idiotic decisions ;-) > You perhaps not living in the US, where many corporate privacy policies exist (in fact are essentially mandated, with those who violate their required freedom of choice of publish or not being punished by their insurers). While policy publication is effecitvely mandator, the policies are based on a big lie - one that actively deceives most users. Liberty and Freedom having different meanings in Europe from US: privacy is libertarian ideal protected by rights in the US, but you must assert them in the US for them to have any value. You must assert the expectation of privacy, and maintain evidence of the currency of that expectation to deter your counterarguer from asserting laches - the doctrine that make your older assertion valueless at the time the telco (or other party) violates its own rules. If for example you do not read the privacy policy of //.com, you cannot assert your process rights to hold the company accountable to its policy - assuming the policy has any accountability rules to start with. And how many American users read it? Thus, how many Americans have any recourse in practice? This is privacy marketing at its best. Perfectly reasonable way of making money ; sell the assurance of privacy, but provide 20% functionality for 80% of users. So lets see what we can do better in IETF, for the wider internet culture that also addresses European and Asian ways of thinking about privacy - which may have different obligations. E2U maps {numeric descriptor -> set of URIs.} where the tel class URI allows one to rewrite the descriptor, and thus restart the resolver at a new discovery point better turned to the architecture of that redirected numbering scheme. And the URI can include https URLs, where the agent initiating privacyE2U can access a W3C capability/privacy policy in (Signed) XML, and the agent can access the SSL-layers negotiation of telematic communication requirements via the certificates exhanged in a realtime handshake with the user's policy server, according to IETF standards. Having established these parameters, neither XML or SSL need to be used further in delivering an actual telematic service once the E2U service completes. So, we have in ENUM, via URI/URL resolution, all the mechanism we need for 2 layer privacy enhancement of ENUM (PEEM WG?). SO lets start thinking about this for the BOF. We have via the W3C work the means of showing and involving users in setting up the privacy practices for a T.323 conference, so there n expectation and restriction policies can be resolved as a part of the DNS-based E2U discovery process; and we have the secure handshake of SSL which identifies the security association requirements than can parameterize the T.120 proxies the users invoke subsequently in order to commute the numeric descriptor into an actual telematic session via an instance of infrastructure ENUM for T.120 switches. Peter. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sat, 19 Jun 2004 16:22:59 -0400 From: Richard Shockey Date: Sat, 19 Jun 2004 16:22:59 -0400 To: enum at ietf.org Subject: Re: [Enum] A note from your chairs on the Agenda for IETF 60 including this discussion on Carrier ENUM - Addendum In-Reply-To: <6.1.0.6.2.20040618111142.022fe280@joy.songbird.com> Message-ID: <6.1.0.6.2.20040619160657.034e9ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At The second hour will then shift to a discussion of Carrier - Infrastructure ENUM ( what ever you want to call it ) That discussion will be led by James Seng and Richard Stastny with myself providing continuity and context to the existing work. Individuals wishing to make formal ID contributions and or requesting time to speak on Carrier ENUM discussions are requested to get your ID documentation in a soon a possible and request time from the mini-BOF chairs. I should have added to this note that the Carrier ENUM mini-BOF should be limited to a discussion of : 1. The problem statement. To this end I'm reminded of Steve Lind's succinct proposal 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? 2. Requirements for a solution without a specific recommendation on what that technology may or may not be appropriate. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 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, 19 Jun 2004 18:03:39 -0400 From: "Stastny Richard" Date: Sat, 19 Jun 2004 18:03:39 -0400 To: "Richard Shockey" Subject: RE: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: <06CF906FE3998C4E944213062009F162443786@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain >1a: What are the issues/problems that need to be addressed? >1b: What are the reasons that "Public" ENUM can't solve them? Status: R Regarding "Public" ENUM, I would like to ask that the list agrees on the following common understanding of "Public" ENUM: Based on the following already mentioned statement in RFC3761 "Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the policy which is attached to the zone." 1. NAPTRs in "Public" DNS shall be accessible, retrievable and interpretable by anybody without restriction. 2 currently most zone policies define the holder of the E.164 number as the end-user, 3. therefore it is the end-users decision to be listed in ENUM (opt-in); or at least his approval is required. 4. the end-user has either direct or indirect influence on the content of the NAPTRs If there is a requirement to implement ENUM in a different way by any entity or confederation of entities, especially with a different policy incompatible with the policy of the appropriate zone administrator (in e164.arpa in most cases the ITU-T and the NRAs), this may be done in any kind of different tree and is called operator, carrier or infrastructure ENUM (it would also be nice to agree on one name) I could offer to present the current European (ETSI) position if I am given a 10 min slot. >2. Requirements for a solution without a specific recommendation on what >that technology may or may not be appropriate. I cannot completely parse this sentence, could anybody elaborate please: Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Sa 19.06.2004 22:15 An: enum at ietf.org Cc: James Seng; Stastny Richard; paf at cisco.com Betreff: Re: [Enum] A note from your chairs on the Agenda for IETF 60 including this discussion on Carrier ENUM - Addendum At >The second hour will then shift to a discussion of Carrier - >Infrastructure ENUM ( what ever you want to call it ) That discussion will >be led by James Seng and Richard Stastny with myself providing continuity >and context to the existing work. > >Individuals wishing to make formal ID contributions and or requesting time >to speak on Carrier ENUM discussions are requested to get your ID >documentation in a soon a possible and request time from the mini-BOF chairs. > I should have added to this note that the Carrier ENUM mini-BOF should be limited to a discussion of : 1. The problem statement. To this end I'm reminded of Steve Lind's succinct proposal 1a: What are the issues/problems that need to be addressed? 1b: What are the reasons that "Public" ENUM can't solve them? 2. Requirements for a solution without a specific recommendation on what that technology may or may not be appropriate. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 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 jwkckid1@ix.netcom.com Sat, 19 Jun 2004 22:57:12 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 22:57:12 -0400 To: Stastny Richard Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <40D513E2.5DC19B87@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > Jeff Williams writes: > >And this to a very great degree is what is wrong with the standards > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > They did. The ENUM protocol as defined in IETF can be implemented > in both ways, athough NOT in the same tree, because the both options > are mutually exclusive. You again misunderstood what I said. That may be my fault however. So I will try to be more precise. The user should be able to have either opt-in or opt-out regardless of which tree. And that in the current protocol is not provided for, and easily could be. > > > Let me explain: Opt-in means that at the beginning nobody is in and the > end-user decides if he wants to be in to get this service. This is the case > with User ENUM, which is an add-on service. Yes I already knew this, so this exercise is not necessary... > The underlying service > is his phone service and this phone service is working regadless if > he is in ENUM or not (with the exception of ENUM-enable numbers, > which are operating only if you are in User ENUM, but nobody is > forced to use these numbers) Again yes I also already knew this as well. And here is one of the problem areas in the current standards track protocol. If you do not choose as a User ENUM to use these numbers you effectively do not have ENUM capability which is a trap that is by design, and bad design at that, to pressure any user to use these numbers and therefore expose themselves to privacy violations or intrusion of various sorts unnecessarily. > > > The end-user has the additional choice how much information he > discloses: the minimum requirement is the number itself and the > operator, if he puts in e.g. sip:+43xxx at provider.net. Yes and the minimum requirement is another area where the user is exposed to privacy intrusions as he/she need need not have to have the number disclosed or even listed or viewable in DNS records, but still available to law enforcement agencies upon notification of the user in advance. > Additional > information between caller and callee may be exchanges via > negotiation between servers (as in SIP) or Personal User Agents > as proposed in UCI. The end-user may also decide on his discretion > to put in more information as he likes, especially a company. This I also already knew. And the proposed UCI is a bit too loosely worded as to whom decides what the user can direct his/her "personal agent" to disclose and whether any restrictions are at the users discretion. Hence exposing the user to potential further damage should said personal agent decide without prior consent, such disclosures... > > > Opt-out would mean that everybody is in and the end-user decides not > to be in. If a provider decides to implement the basic communication service > based on ENUM, he MUST put all users using this service in ENUM Yes, and this I also already knew and again exposes unnecessarily the user to potential privacy intrusions of obvious and already discussed various sorts. > > > Using ENUM for a service is currently also opt-in, but for the provider as > a whole with all of his numbers. There is no opt-out for the individual > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > but in separate tree. It is opt-in currently because there is still the PSTN around > to reach providers not in Infrastructure ENUM by default. If the PSTN ceases > to exists at some point of time, another default method need to be defined if > E.164 numbering is still around. This may be ENUM or maybe not. Yes again exactly right, and I already knew as well as demonstrates that anti-privacy bigots do not wish of users to have opt-out for reasons that are of a political and philosophical nature which may or may not be shared by some of many users and also not in concert with EU's for instance, laws. > > > Up to this point of time, different trees may be used by different groups > of service providers (confederation), this is already happening. A service > provider may even participate in different trees at the same time. > > These trees may either be trees only accessible by participants of the > confederation (either in extranets or with access control), but not > on the public Internet, or if accessible by the public, the information > is either not accessible, encrypted or useless for the normal end-user. > > There is also a difference between the information contained in > the trees. > > In User ENUM the information points to end-points, > giving one ore more URIs where the end-user has his services. > Different NAPTRs may point to different service providers. > The domain name holder is the end-user. Right, and as the user does not own his/her domain name currently he/she is exposed to others making many privacy and security decisions for him/her depending on the service agreement the provider has or may change from time to time. > > > In Infrastructure ENUM the entry points in principle to > the destination network providing the service for this number. > The domain name holder is the service provider. Right if and when the Domain Name holder is also the service provider which would not be the case in most instances... > > > All this together precludes User ENUM and Infrastructure > ENUM to be in the same tree (even the delegation structure > may be differnent). > > Of course User ENUM and Infrastructure ENUM may co-exist, > any user listed in one or more Infrastructure trees may also > request an entry in User ENUM. The provider may also offer > to the calling customer a service in such a way that first User > ENUM queried and then Infrastructure ENUM. This is already > implemented in some SIP servers and works. (Note: why should > the provider do this? Because the user may do this by himself also. > It is kinda carrier selection ;-) > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > explaining all these issues. Yes I have seen early parts of this draft.. > > > BTW: there is one complication emerging at the moment: > Confederations also want Infrastructure ENUM to be used > for routing of transit calls, e.g. an provider is publishing number > ranges in a confederation tree he is serving on the PSTN with his > gateways. This is in principle feasable, but will cause serious problems > in the future, especially if two confederations decide to merge there > trees. If one numbers are entered by providers which are assigned > to them, no conflicts could arise if trees are merged. Agreed that there could be some problems in the instances where said confederations are merged for some reason or another such as a business merger or buyout. But again they can be overcome without intruding either previous confederations users discretion regarding any privacy exposures. > > > If numbers are entered by providers not assigned to them, this > will cause policy problems and conflicts. These conflicts cannot > be resolved in ENUM, because it is not designed for it. Other > protocols like TRIP or OSP should be used for this. > > Richard: > To Jeff: You know what my problem with all privacy advocates is? > > They are trespassing my privacy by trying to limit my freedom of decision, > including my human right to make idiotic decisions ;-) Hummm? Well I honestly don't see how such a situation is relevant or even possible. Freedom to choose is also a part of protecting anyone's privacy. Idiotic decisions by someone that does so for others, knowingly of that or those persons is a responsibility of great gravity sometimes. For oneself, and only effecting oneself, idiotic decisions are of course expectable however damaging to oneself only, they may be... Ask yourself, do you NEED access to my ENUM number? Does any network operator NEED unrestricted access to my ENUM number? Would access of any sort or at any level to any number other individuals, regardless of supposed status or position not have the increasing potential of the domain name holders ENUM number not expose him/her to potential if not eventual definite abuses of various sorts, some being of a life threatening nature? I believe the answer to this question to definitely be, YES. And THAT is not expectable and preventable if the current ENUM standards track/protocol incorporates at least most of the exposures now known and have been known for some time... Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 19 Jun 2004 23:42:29 -0400 From: Jeff Williams Date: Sat, 19 Jun 2004 23:42:29 -0400 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F162443786@oefeg-s02.oefeg.loc> Message-ID: <40D5202E.9EEF4C17@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > >1a: What are the issues/problems that need to be addressed? > >1b: What are the reasons that "Public" ENUM can't solve them? > > Regarding "Public" ENUM, I would like to ask that the list agrees > on the following common understanding of "Public" ENUM: > > Based on the following already mentioned statement in RFC3761 > > "Holders of E.164 numbers which want to be listed in DNS > should contact the appropriate zone administrator according > to the policy which is attached to the zone." Yes and this indicates that the zone management will be making this decision, with or without the consent of the users or any single user. Therefore this is insufficient, which I have been trying to get across here... Oh, and BTW, a "Consensus" is also not appropriate for which the zone management to declare without being able to demonstrate that a "Consensus" is accompanied by a vote of the participating zone users... > > > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > interpretable by anybody without restriction. This needs to be changed for obvious privacy reasons. > > 2 currently most zone policies define the holder of the E.164 > number as the end-user, Most, but not all. And all is what is needed.. > > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > or at least his approval is required. No that is not what is said or even inferred... > > 4. the end-user has either direct or indirect influence on > the content of the NAPTRs Direct is necessary. > > > If there is a requirement to implement ENUM in a different way > by any entity or confederation of entities, especially with a > different policy incompatible with the policy of the appropriate > zone administrator (in e164.arpa in most cases the ITU-T and the > NRAs), this may be done in any kind of different tree and is > called operator, carrier or infrastructure ENUM (it would > also be nice to agree on one name) > > I could offer to present the current European (ETSI) position > if I am given a 10 min slot. > > >2. Requirements for a solution without a specific recommendation on what > >that technology may or may not be appropriate. > > I cannot completely parse this sentence, could anybody > elaborate please: I really couldn't either... > > > Richard > > -----UrsprĂĽngliche Nachricht----- > Von: Richard Shockey [mailto:richard at shockey.us] > Gesendet: Sa 19.06.2004 22:15 > An: enum at ietf.org > Cc: James Seng; Stastny Richard; paf at cisco.com > Betreff: Re: [Enum] A note from your chairs on the Agenda for IETF 60 including this discussion on Carrier ENUM - Addendum > > > > At > > >The second hour will then shift to a discussion of Carrier - > >Infrastructure ENUM ( what ever you want to call it ) That discussion will > >be led by James Seng and Richard Stastny with myself providing continuity > >and context to the existing work. > > > >Individuals wishing to make formal ID contributions and or requesting time > >to speak on Carrier ENUM discussions are requested to get your ID > >documentation in a soon a possible and request time from the mini-BOF chairs. > > > > > I should have added to this note that the Carrier ENUM mini-BOF should be > limited to a discussion of : > > 1. The problem statement. To this end I'm reminded of Steve Lind's succinct > proposal > > 1a: What are the issues/problems that need to be addressed? > 1b: What are the reasons that "Public" ENUM can't solve them? > > 2. Requirements for a solution without a specific recommendation on what > that technology may or may not be appropriate. > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Sun, 20 Jun 2004 14:39:26 -0400 From: Richard Shockey Date: Sun, 20 Jun 2004 14:39:26 -0400 To: Jeff Williams Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F162443786@oefeg-s02.oefeg.loc> Message-ID: <6.1.0.6.2.20040620133951.0322bec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > >1a: What are the issues/problems that need to be addressed? > >1b: What are the reasons that "Public" ENUM can't solve them? > > Regarding "Public" ENUM, I would like to ask that the list agrees > on the following common understanding of "Public" ENUM: > > Based on the following already mentioned statement in RFC3761 > > "Holders of E.164 numbers which want to be listed in DNS > should contact the appropriate zone administrator according > to the policy which is attached to the zone." Yes and this indicates that the zone management will be making this decision, with or without the consent of the users or any single user. Therefore this is insufficient, which I have been trying to get across here... Oh, and BTW, a "Consensus" is also not appropriate for which the zone management to declare without being able to demonstrate that a "Consensus" is accompanied by a vote of the participating zone users... Zone administration in the context of 3761 is the nation-state national regulatory authority period ..end of story. That is the way it is in order to preserve and protect the integrity of the ITU E.164 numbering plan. It will not change, ergo further discussion of this matter is a waste of electrons. > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > interpretable by anybody without restriction. This needs to be changed for obvious privacy reasons. You are obviously not familiar with Internet 101. the DNS is the DNS. All DNS data is available to all DNS users at all times regardless and without restriction. There are is NO AA in the DNS. Policy in the context SIP is controlled by the edge proxy's not the DNS. > > 2 currently most zone policies define the holder of the E.164 > number as the end-user, Most, but not all. And all is what is needed.. again this is a nation-state issue in the context of 3761 you really need to read the documents > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > or at least his approval is required. No that is not what is said or even inferred... certainly not in 3761 but if you would _read_ the various administration and policy documents coming out of various national ENUM Forums this would be self evident. I think Mr Stastny initial definition of Public ENUM is quite good and in the usual manner I'll probably steal most of it for various PPT slides. :-) As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I would prefer Carrier TN to URI translation mechanisms. One can begin by defining what we think Carrier "ENUM" is. Problem Statement: As the Internet becomes the predominant transport and routing mechanism for various forms of communications there needs to be a consistent, authoritative and reliable mechanism by which service providers can privately and reliably exchange Telephone Number to URI translations for all Telephone Numbers for which they have service control. Classic Telephone Number to PSTN routing mechanisms are well understood and the exchange of such inter-carrier data is well defined in the various SS7 and Number Portability mechanisms. Were service providers not able to exchange routing information no service would ever connect to another. The requirements of a Carrier TN to URI translation mechanism requires that the data be completely authenticated by the SP for ALL endpoints under its service control so that the aggregate inter-carrier database of all TN to URI translations is considered authoritative and reliable. Since the data is designed to permit optimized inter-carrier routing and nothing else, there is no requirement that the data be globally accessible or visible. In fact for security and privacy reasons reasons the exact opposite is true. What seems to be clear that in the absence of authoritative, authenticated and reliable inter-carrier TN to URI database for voice communications services the default routing mechanism is the PSTN and for any number of reasons that is not a good idea in the long run. ENUM RFC 3761 defined one mechanism by which TN to URI translations could be accomplished for the General Case of Internet users using the DNS as the query-response mechanism. National Regulatory Authorities have generally defined the administrative policies and procedures surrounding 3761 as being OPT-IN for consumers, therefore the e164.arpa database may not be complete. And as a side bar, there are still significant problems in delegating various portions of the e164.arpa tree as of this date. The Carrier TN 2 URI service is clearly another case for a different set of users that has a different set of requirements which _may _require a different technical query-response solution. This problem is much more roughly analogous to the problem of route announcements in BGP than the DNS (probably bad analogy) . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 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 Sun, 20 Jun 2004 16:32:20 -0400 From: "Stastny Richard" Date: Sun, 20 Jun 2004 16:32:20 -0400 To: "Richard Shockey" Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: <06CF906FE3998C4E944213062009F16244378A@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R So given Steven questions, my "User ENUM" definitions and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM", I want to try to give an answer to question 1b first, before I address 1a a: within User ENUM there exist privacy issues. set-up properly these issues do not exist in "Carrier ENUM", because either the information is not accessible or not usable by end-users. Note: all privacy issues with ENUM should thereore be discussed in the first half of the meeting, not in the mini-BoF on "Carrier ENUM" b. "User ENUM" is end-to-end and therefore opt-in - Service providers wanting to deploy a routing of calls between their networks avoiding the PSTN as interconnect need a tool on the Internet to achieve this goal. (This tool is also necessary if no PSTN exists anymore ;-) - They may choose to use the technology as defined in RFC3761 at al. - To achieve this they have to include ALL E.164 numbers assigend to them and they in turn assigned to the end-users they are providing service for (anybody an idea of a better wording?) so opt-in is not possible. - confederations of service providers may choose any domain in the DNS as root for their tree, they may even choose a "private DNS" - If a service provider populates the tree only with E.164 numbers assigned to him, a later merging of trees is trivial, because no overlaps exist. - currently also nor additional requirements on the ENUM protocol are known. If there are, please come forward now. Warning: the above definition is only valid if "carrier ENUM" is only used for routing to destination service providers hosting the numbers they hold in the tree. So 1a: What are the issues/problems that need to be addressed? Recently some requirements have been discussed to use ENUM and especially "carrier ENUM" for additional purposes,e.g. routing to transit providers if they also provide gateways to the PSTN. Although this is in principle possible with ENUM, this is not recommended because it may cause conflicts in domain ownerships and make it impossible to merge trees later. Since in most cases routing to the PSTN is involved, this immediately raises the question of settlement and alternative routes. ENUM as it is now is not providing these functions, one should use TRIP or OSP for this. The mini-BoF may discuss this issue and may come to a conclusion. (reject the isuue or extend ENUM) Richard -----UrsprĂngliche Nachricht----- Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: So 20.06.2004 20:35 An: Jeff Williams; Stastny Richard Cc: enum at ietf.org Betreff: Re: [Enum] Carrier ENUM mini-BoF Agenda > > > > >1a: What are the issues/problems that need to be addressed? > > >1b: What are the reasons that "Public" ENUM can't solve them? > > > > Regarding "Public" ENUM, I would like to ask that the list agrees > > on the following common understanding of "Public" ENUM: > > > > Based on the following already mentioned statement in RFC3761 > > > > "Holders of E.164 numbers which want to be listed in DNS > > should contact the appropriate zone administrator according > > to the policy which is attached to the zone." > > Yes and this indicates that the zone management will be making >this decision, with or without the consent of the users or any single >user. Therefore this is insufficient, which I have been trying to >get across here... Oh, and BTW, a "Consensus" is also not >appropriate for which the zone management to declare without >being able to demonstrate that a "Consensus" is accompanied >by a vote of the participating zone users... Zone administration in the context of 3761 is the nation-state national regulatory authority period ..end of story. That is the way it is in order to preserve and protect the integrity of the ITU E.164 numbering plan. It will not change, ergo further discussion of this matter is a waste of electrons. > > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > > interpretable by anybody without restriction. > > This needs to be changed for obvious privacy reasons. You are obviously not familiar with Internet 101. the DNS is the DNS. All DNS data is available to all DNS users at all times regardless and without restriction. There are is NO AA in the DNS. Policy in the context SIP is controlled by the edge proxy's not the DNS. > > > > 2 currently most zone policies define the holder of the E.164 > > number as the end-user, > > Most, but not all. And all is what is needed.. again this is a nation-state issue in the context of 3761 you really need to read the documents > > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > > or at least his approval is required. > > No that is not what is said or even inferred... certainly not in 3761 but if you would _read_ the various administration and policy documents coming out of various national ENUM Forums this would be self evident. I think Mr Stastny initial definition of Public ENUM is quite good and in the usual manner I'll probably steal most of it for various PPT slides. :-) As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I would prefer Carrier TN to URI translation mechanisms. One can begin by defining what we think Carrier "ENUM" is. Problem Statement: As the Internet becomes the predominant transport and routing mechanism for various forms of communications there needs to be a consistent, authoritative and reliable mechanism by which service providers can privately and reliably exchange Telephone Number to URI translations for all Telephone Numbers for which they have service control. Classic Telephone Number to PSTN routing mechanisms are well understood and the exchange of such inter-carrier data is well defined in the various SS7 and Number Portability mechanisms. Were service providers not able to exchange routing information no service would ever connect to another. The requirements of a Carrier TN to URI translation mechanism requires that the data be completely authenticated by the SP for ALL endpoints under its service control so that the aggregate inter-carrier database of all TN to URI translations is considered authoritative and reliable. Since the data is designed to permit optimized inter-carrier routing and nothing else, there is no requirement that the data be globally accessible or visible. In fact for security and privacy reasons reasons the exact opposite is true. What seems to be clear that in the absence of authoritative, authenticated and reliable inter-carrier TN to URI database for voice communications services the default routing mechanism is the PSTN and for any number of reasons that is not a good idea in the long run. ENUM RFC 3761 defined one mechanism by which TN to URI translations could be accomplished for the General Case of Internet users using the DNS as the query-response mechanism. National Regulatory Authorities have generally defined the administrative policies and procedures surrounding 3761 as being OPT-IN for consumers, therefore the e164.arpa database may not be complete. And as a side bar, there are still significant problems in delegating various portions of the e164.arpa tree as of this date. The Carrier TN 2 URI service is clearly another case for a different set of users that has a different set of requirements which _may _require a different technical query-response solution. This problem is much more roughly analogous to the problem of route announcements in BGP than the DNS (probably bad analogy) . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 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 jwkckid1@ix.netcom.com Sun, 20 Jun 2004 20:56:27 -0400 From: Jeff Williams Date: Sun, 20 Jun 2004 20:56:27 -0400 To: Stastny Richard Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F16244378A@oefeg-s02.oefeg.loc> Message-ID: <40D64B0D.D46C49C9@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > So given Steven questions, my "User ENUM" definitions > and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM", > > I want to try to give an answer to question 1b first, before I address 1a > > a: within User ENUM there exist privacy issues. > set-up properly these issues do not exist in "Carrier ENUM", > because either the information is not accessible or not usable > by end-users. > Note: all privacy issues with ENUM should thereore be discussed > in the first half of the meeting, not in the mini-BoF on "Carrier ENUM" Good point. > > > b. "User ENUM" is end-to-end and therefore opt-in > - Service providers wanting to deploy a routing of calls > between their networks avoiding the PSTN as interconnect > need a tool on the Internet to achieve this goal. (This > tool is also necessary if no PSTN exists anymore ;-) I knew this was coming. No tool is needed. I suspect you knew that before stating the above. However a chance in the standards track is needed, which I also suspect you know and knew before stating the above is some standard or expected level of good privacy protection is to be inclusive for User ENUM. I can however understand Carriers not liking such privacy protections for User ENUM given potential business plans or even existing business plans... > > > - They may choose to use the technology as defined > in RFC3761 at al. I doubt that once that RFC3761 is understood by more and more users they as users will... > > > - To achieve this they have to include ALL E.164 numbers assigend > to them and they in turn assigned to the end-users they > are providing service for (anybody an idea of a better wording?) > so opt-in is not possible. Yes defined in this skewed way opt-in is not possible which is what I have been saying all along for a couple of years now. Yet opt-in is being demanded and as such will need to be provided for. > > > - confederations of service providers may choose any domain in > the DNS as root for their tree, they may even choose a "private DNS" > > - If a service provider populates the tree only with E.164 numbers > assigned to him, a later merging of trees is trivial, because no overlaps > exist. > - currently also nor additional requirements on the ENUM protocol > are known. If there are, please come forward now. > > Warning: the above definition is only valid if "carrier ENUM" is > only used for routing to destination service providers hosting the > numbers they hold in the tree. > > So > 1a: What are the issues/problems that need to be addressed? > > Recently some requirements have been discussed to use > ENUM and especially "carrier ENUM" for additional > purposes,e.g. routing to transit providers if they also > provide gateways to the PSTN. > > Although this is in principle possible with ENUM, this > is not recommended because it may cause conflicts in > domain ownerships and make it impossible to merge > trees later. > > Since in most cases routing to the PSTN is involved, > this immediately raises the question of settlement and > alternative routes. > > ENUM as it is now is not providing these functions, one > should use TRIP or OSP for this. > > The mini-BoF may discuss this issue and may come > to a conclusion. (reject the isuue or extend ENUM) > > Richard > > -----UrsprĂĽngliche Nachricht----- > Von: Richard Shockey [mailto:richard at shockey.us] > Gesendet: So 20.06.2004 20:35 > An: Jeff Williams; Stastny Richard > Cc: enum at ietf.org > Betreff: Re: [Enum] Carrier ENUM mini-BoF Agenda > > > > > > > > > > >1a: What are the issues/problems that need to be addressed? > > > >1b: What are the reasons that "Public" ENUM can't solve them? > > > > > > Regarding "Public" ENUM, I would like to ask that the list agrees > > > on the following common understanding of "Public" ENUM: > > > > > > Based on the following already mentioned statement in RFC3761 > > > > > > "Holders of E.164 numbers which want to be listed in DNS > > > should contact the appropriate zone administrator according > > > to the policy which is attached to the zone." > > > > Yes and this indicates that the zone management will be making > >this decision, with or without the consent of the users or any single > >user. Therefore this is insufficient, which I have been trying to > >get across here... Oh, and BTW, a "Consensus" is also not > >appropriate for which the zone management to declare without > >being able to demonstrate that a "Consensus" is accompanied > >by a vote of the participating zone users... > > > Zone administration in the context of 3761 is the nation-state national > regulatory authority period ..end of story. That is the way it is in order > to preserve and protect the integrity of the ITU E.164 numbering plan. It > will not change, ergo further discussion of this matter is a waste of > electrons. > > > > > > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > > > interpretable by anybody without restriction. > > > > This needs to be changed for obvious privacy reasons. > > You are obviously not familiar with Internet 101. the DNS is the > DNS. All DNS data is available to all DNS users at all times regardless and > without restriction. There are is NO AA in the DNS. Policy in the context > SIP is controlled by the edge proxy's not the DNS. > > > > > > > > > 2 currently most zone policies define the holder of the E.164 > > > number as the end-user, > > > > Most, but not all. And all is what is needed.. > > > again this is a nation-state issue in the context of 3761 you really need > to read the documents > > > > > > > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > > > or at least his approval is required. > > > > No that is not what is said or even inferred... > > certainly not in 3761 but if you would _read_ the various administration > and policy documents coming out of various national ENUM Forums this would > be self evident. > > > I think Mr Stastny initial definition of Public ENUM is quite good and in > the usual manner I'll probably steal most of it for various PPT slides. :-) > > As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I > would prefer Carrier TN to URI translation mechanisms. > > One can begin by defining what we think Carrier "ENUM" is. > > Problem Statement: As the Internet becomes the predominant transport and > routing mechanism for various forms of communications there needs to be a > consistent, authoritative and reliable mechanism by which service providers > can privately and reliably exchange Telephone Number to URI translations > for all Telephone Numbers for which they have service control. > > Classic Telephone Number to PSTN routing mechanisms are well understood and > the exchange of such inter-carrier data is well defined in the various SS7 > and Number Portability mechanisms. Were service providers not able to > exchange routing information no service would ever connect to another. > > The requirements of a Carrier TN to URI translation mechanism requires that > the data be completely authenticated by the SP for ALL endpoints under its > service control so that the aggregate inter-carrier database of all TN to > URI translations is considered authoritative and reliable. > > Since the data is designed to permit optimized inter-carrier routing and > nothing else, there is no requirement that the data be globally accessible > or visible. In fact for security and privacy reasons reasons the exact > opposite is true. > > What seems to be clear that in the absence of authoritative, > authenticated and reliable inter-carrier TN to URI database for voice > communications services the default routing mechanism is the PSTN and for > any number of reasons that is not a good idea in the long run. > > ENUM RFC 3761 defined one mechanism by which TN to URI translations could > be accomplished for the General Case of Internet users using the DNS as the > query-response mechanism. National Regulatory Authorities have generally > defined the administrative policies and procedures surrounding 3761 as > being OPT-IN for consumers, therefore the e164.arpa database may not be > complete. And as a side bar, there are still significant problems in > delegating various portions of the e164.arpa tree as of this date. > > The Carrier TN 2 URI service is clearly another case for a different set of > users that has a different set of requirements which _may _require a > different technical query-response solution. This problem is much more > roughly analogous to the problem of route announcements in BGP than the DNS > (probably bad analogy) . > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sun, 20 Jun 2004 21:02:18 -0400 From: Jeff Williams Date: Sun, 20 Jun 2004 21:02:18 -0400 To: Richard Shockey Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F162443786@oefeg-s02.oefeg.loc> Message-ID: <40D64C81.903B4B50@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, Richard: I have read all the relevant documents. Richard Shockey wrote: > > > > > > > >1a: What are the issues/problems that need to be addressed? > > > >1b: What are the reasons that "Public" ENUM can't solve them? > > > > > > Regarding "Public" ENUM, I would like to ask that the list agrees > > > on the following common understanding of "Public" ENUM: > > > > > > Based on the following already mentioned statement in RFC3761 > > > > > > "Holders of E.164 numbers which want to be listed in DNS > > > should contact the appropriate zone administrator according > > > to the policy which is attached to the zone." > > > > Yes and this indicates that the zone management will be making > >this decision, with or without the consent of the users or any single > >user. Therefore this is insufficient, which I have been trying to > >get across here... Oh, and BTW, a "Consensus" is also not > >appropriate for which the zone management to declare without > >being able to demonstrate that a "Consensus" is accompanied > >by a vote of the participating zone users... > > Zone administration in the context of 3761 is the nation-state national > regulatory authority period ..end of story. That is the way it is in order > to preserve and protect the integrity of the ITU E.164 numbering plan. It > will not change, ergo further discussion of this matter is a waste of > electrons. > > > > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > > > interpretable by anybody without restriction. > > > > This needs to be changed for obvious privacy reasons. > > You are obviously not familiar with Internet 101. the DNS is the > DNS. All DNS data is available to all DNS users at all times regardless and > without restriction. There are is NO AA in the DNS. Policy in the context > SIP is controlled by the edge proxy's not the DNS. > > > > > > > 2 currently most zone policies define the holder of the E.164 > > > number as the end-user, > > > > Most, but not all. And all is what is needed.. > > again this is a nation-state issue in the context of 3761 you really need > to read the documents > > > > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > > > or at least his approval is required. > > > > No that is not what is said or even inferred... > > certainly not in 3761 but if you would _read_ the various administration > and policy documents coming out of various national ENUM Forums this would > be self evident. > > I think Mr Stastny initial definition of Public ENUM is quite good and in > the usual manner I'll probably steal most of it for various PPT slides. :-) > > As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I > would prefer Carrier TN to URI translation mechanisms. > > One can begin by defining what we think Carrier "ENUM" is. > > Problem Statement: As the Internet becomes the predominant transport and > routing mechanism for various forms of communications there needs to be a > consistent, authoritative and reliable mechanism by which service providers > can privately and reliably exchange Telephone Number to URI translations > for all Telephone Numbers for which they have service control. > > Classic Telephone Number to PSTN routing mechanisms are well understood and > the exchange of such inter-carrier data is well defined in the various SS7 > and Number Portability mechanisms. Were service providers not able to > exchange routing information no service would ever connect to another. > > The requirements of a Carrier TN to URI translation mechanism requires that > the data be completely authenticated by the SP for ALL endpoints under its > service control so that the aggregate inter-carrier database of all TN to > URI translations is considered authoritative and reliable. > > Since the data is designed to permit optimized inter-carrier routing and > nothing else, there is no requirement that the data be globally accessible > or visible. In fact for security and privacy reasons reasons the exact > opposite is true. > > What seems to be clear that in the absence of authoritative, > authenticated and reliable inter-carrier TN to URI database for voice > communications services the default routing mechanism is the PSTN and for > any number of reasons that is not a good idea in the long run. > > ENUM RFC 3761 defined one mechanism by which TN to URI translations could > be accomplished for the General Case of Internet users using the DNS as the > query-response mechanism. National Regulatory Authorities have generally > defined the administrative policies and procedures surrounding 3761 as > being OPT-IN for consumers, therefore the e164.arpa database may not be > complete. And as a side bar, there are still significant problems in > delegating various portions of the e164.arpa tree as of this date. > > The Carrier TN 2 URI service is clearly another case for a different set of > users that has a different set of requirements which _may _require a > different technical query-response solution. This problem is much more > roughly analogous to the problem of route announcements in BGP than the DNS > (probably bad analogy) . > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 21 Jun 2004 00:47:30 -0400 From: "Peter Williams" Date: Mon, 21 Jun 2004 00:47:30 -0400 To: richard at shockey.us Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Zone administration in the context of 3761 is the nation-state national regulatory authority period ..end of story. That is the way it is in order to preserve and protect the integrity of the ITU E.164 numbering plan. It will not change, ergo further discussion of this matter is a waste of electrons. Lets be more careful, and perhaps more informative and precise. Can you cite the IS<->ITU-T agreement pertaining to this specific issue, please. For example, are you saying that all carrier ENUM registrations/listings performed out for all US telco carriers (PSTSN and regulated VoIP) must be handled by ***** company? Becuase they happen to have won an ICANN bid for registering _host_ domain names, beneath .us? Is ICANN secretly regulating infrastructure ENUM now? There are various formal arrangements between IETF/IS and ITU, most of them being informal arrangements concerning shared committee work, overlap, and enabling ITU to reference certain grades of IETF documents when issuing international standards under the authority of the UN. If the ENUM WG's engineering deliberations are subject to specific rules both for standards making, and for any and all operations, and it is not mentioned or referenced in the RFC being cited and sicussed as the source of the undersatnding about public ENUM, we HAVE to fix this. This is VERY serious omission. BIG RED FLAG. On the issue itself, versus WG procedure and quality of standards: we must remember that DNS is but one place where users/carriers may list the already registered E.164 numeric descriptor name form, as a new name - one formulated using the IETF standardized name form for domain names. Integrity and listing rules for this name form pertain to DNS adminsitration, not ITU-T: period. Who issues E.164 names per se is not relevant to IETF, particularly. In certain special zones, e.g. .arpa, DARPA program managers in IETF WGs have the authority to use US government authority for research purposes, and possibly purposes advancing matters handled normally by the US State Dept - e.g. interaction with an international organization such as ITU, under international (not US) law. I suspect most of us would be happy that we get a government agency used to negotiating engineering issues in ISO/ITU on our side, once such issues start to impact or constrain the engineering activities. > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > interpretable by anybody without restriction. This needs to be changed for obvious privacy reasons. You are obviously not familiar with Internet 101. the DNS is the DNS. All DNS data is available to all DNS users at all times regardless and without restriction. There are is NO AA in the DNS. Policy in the context SIP is controlled by the edge proxy's not the DNS. > > 2 currently most zone policies define the holder of the E.164 > number as the end-user, Most, but not all. And all is what is needed.. again this is a nation-state issue in the context of 3761 you really need to read the documents > 3. therefore it is the end-users decision to be listed in ENUM (opt-in); > or at least his approval is required. No that is not what is said or even inferred... certainly not in 3761 but if you would _read_ the various administration and policy documents coming out of various national ENUM Forums this would be self evident. I think Mr Stastny initial definition of Public ENUM is quite good and in the usual manner I'll probably steal most of it for various PPT slides. :-) As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I would prefer Carrier TN to URI translation mechanisms. One can begin by defining what we think Carrier "ENUM" is. Problem Statement: As the Internet becomes the predominant transport and routing mechanism for various forms of communications there needs to be a consistent, authoritative and reliable mechanism by which service providers can privately and reliably exchange Telephone Number to URI translations for all Telephone Numbers for which they have service control. Classic Telephone Number to PSTN routing mechanisms are well understood and the exchange of such inter-carrier data is well defined in the various SS7 and Number Portability mechanisms. Were service providers not able to exchange routing information no service would ever connect to another. The requirements of a Carrier TN to URI translation mechanism requires that the data be completely authenticated by the SP for ALL endpoints under its service control so that the aggregate inter-carrier database of all TN to URI translations is considered authoritative and reliable. Since the data is designed to permit optimized inter-carrier routing and nothing else, there is no requirement that the data be globally accessible or visible. In fact for security and privacy reasons reasons the exact opposite is true. What seems to be clear that in the absence of authoritative, authenticated and reliable inter-carrier TN to URI database for voice communications services the default routing mechanism is the PSTN and for any number of reasons that is not a good idea in the long run. ENUM RFC 3761 defined one mechanism by which TN to URI translations could be accomplished for the General Case of Internet users using the DNS as the query-response mechanism. National Regulatory Authorities have generally defined the administrative policies and procedures surrounding 3761 as being OPT-IN for consumers, therefore the e164.arpa database may not be complete. And as a side bar, there are still significant problems in delegating various portions of the e164.arpa tree as of this date. The Carrier TN 2 URI service is clearly another case for a different set of users that has a different set of requirements which _may _require a different technical query-response solution. This problem is much more roughly analogous to the problem of route announcements in BGP than the DNS (probably bad analogy) . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Mon, 21 Jun 2004 01:07:56 -0400 From: "Peter Williams" Date: Mon, 21 Jun 2004 01:07:56 -0400 To: Richard.Stastny at oefeg.at Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R From: Jeff Williams To: Stastny Richard CC: enum at ietf.org, Richard Shockey Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda Date: Sun, 20 Jun 2004 19:42:26 -0700 Stastny and all, Stastny Richard wrote: > So given Steven questions, my "User ENUM" definitions > and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM", > > I want to try to give an answer to question 1b first, before I address 1a > > a: within User ENUM there exist privacy issues. > set-up properly these issues do not exist in "Carrier ENUM", > because either the information is not accessible or not usable > by end-users. > Note: all privacy issues with ENUM should thereore be discussed > in the first half of the meeting, not in the mini-BoF on "Carrier ENUM" Good point. This is not appropriate, in my view. The reasoning is very flawed. There is a relationship between holder of the E.164 and the ENUM provider. While end-users may be unable to gain access to the marketing information derived from the providers analyis of the transactions for a given ENUM name, listing beneath e164.arpa (or elsewhere), the provider may seek to sell this information about the holder to value-added resellers, folk sellling additional telematic services, etc etc. This is quite typical in the US, and is what the US privacy policy apparatus is designed to codify, and disclose (even if it provides little in the way of enfocement) - so subscribers are at least notified of the possible arrangements that may impact their wider use of telematics. Remember to distinguish between privacy, and security folks. Providing wonderful access conrol security by DNS or procedural means has no relevance to the privacy issues which we mut address in our engineering work on a public lookup service. Privacy is about information reuse, and disclousre of the possible reuses by all involved parties, including providers. In many cases, the most blatant privacy abuses do NORMALLY not involve the end-users directly: they involve selling information about end-users by providers and others with whom the end-user has no contractual relationships. Remember, it took IETF over 15 years of hard work to privacy-enhace our email standards, with CA policy disclosures etc. We bridged complex legal work about digital signatures and CAs, and simple crypto work. And it took us over 10 years to secure IPSEC. If if takes as long to privacy enhance or secure ENUM protocols, so be it. Peter. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 21 Jun 2004 01:22:02 -0400 From: Jeff Williams Date: Mon, 21 Jun 2004 01:22:02 -0400 To: Peter Williams Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: Message-ID: <40D6892A.9C5E4C1B@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter, and all, Peter Williams wrote: > > > > > >Zone administration in the context of 3761 is the nation-state national > >regulatory authority period ..end of story. That is the way it is in order > >to preserve and protect the integrity of the ITU E.164 numbering plan. It > >will not change, ergo further discussion of this matter is a waste of > >electrons. > > Lets be more careful, and perhaps more informative and precise. > > Can you cite the IS<->ITU-T agreement pertaining to this specific issue, > please. For example, are you saying that all carrier ENUM > registrations/listings performed out for all US telco carriers (PSTSN and > regulated VoIP) must be handled by ***** company? Becuase they happen to > have won an ICANN bid for registering _host_ domain names, beneath .us? I think Richard was trying to say this in his own terms/words. Of course the US does not always and recently rarely adheres to ITU agreements or proposals as many were not made in cooperation with DOC/NTIA or NIST for a couple of examples. > > > Is ICANN secretly regulating infrastructure ENUM now? ICANN is certainly attempting to have some influence. To the extent that industry or commercial and non-commercial entities will be accepting remains inconclusive. Some will and some won't but the IP GNSO constituency is attempting to garner more and more Commercial organizations in becoming more accepting... > > > There are various formal arrangements between IETF/IS and ITU, most of them > being informal arrangements concerning shared committee work, overlap, and > enabling ITU to reference certain grades of IETF documents when issuing > international standards under the authority of the UN. If the ENUM WG's > engineering deliberations are subject to specific rules both for standards > making, and for any and all operations, and it is not mentioned or > referenced in the RFC being cited and sicussed as the source of the > undersatnding about public ENUM, we HAVE to fix this. This is VERY serious > omission. BIG RED FLAG. I agree, a very big red flag... > > > On the issue itself, versus WG procedure and quality of standards: > > we must remember that DNS is but one place where users/carriers may list the > already registered E.164 numeric descriptor name form, as a new name - one > formulated using the IETF standardized name form for domain names. Integrity > and listing rules for this name form pertain to DNS adminsitration, not > ITU-T: period. Who issues E.164 names per se is not relevant to IETF, > particularly. > > In certain special zones, e.g. .arpa, DARPA program managers in IETF WGs > have the authority to use US government authority for research purposes, and > possibly purposes advancing matters handled normally by the US State Dept - > e.g. interaction with an international organization such as ITU, under > international (not US) law. I suspect most of us would be happy that we get > a government agency used to negotiating engineering issues in ISO/ITU on our > side, once such issues start to impact or constrain the engineering > activities. > > > > > > > > >> > 1. NAPTRs in "Public" DNS shall be accessible, retrievable and > >> > interpretable by anybody without restriction. > >> > >> This needs to be changed for obvious privacy reasons. > > > >You are obviously not familiar with Internet 101. the DNS is the > >DNS. All DNS data is available to all DNS users at all times regardless and > >without restriction. There are is NO AA in the DNS. Policy in the context > >SIP is controlled by the edge proxy's not the DNS. > > > > > > > >> > > >> > 2 currently most zone policies define the holder of the E.164 > >> > number as the end-user, > >> > >> Most, but not all. And all is what is needed.. > > > > > >again this is a nation-state issue in the context of 3761 you really need > >to read the documents > > > > > > > > > >> > 3. therefore it is the end-users decision to be listed in ENUM > >>(opt-in); > >> > or at least his approval is required. > >> > >> No that is not what is said or even inferred... > > > >certainly not in 3761 but if you would _read_ the various administration > >and policy documents coming out of various national ENUM Forums this would > >be self evident. > > > > > >I think Mr Stastny initial definition of Public ENUM is quite good and in > >the usual manner I'll probably steal most of it for various PPT slides. :-) > > > >As for Carrier ENUM. (maybe we should stop calling it ENUM) Personally I > >would prefer Carrier TN to URI translation mechanisms. > > > >One can begin by defining what we think Carrier "ENUM" is. > > > >Problem Statement: As the Internet becomes the predominant transport and > >routing mechanism for various forms of communications there needs to be a > >consistent, authoritative and reliable mechanism by which service providers > >can privately and reliably exchange Telephone Number to URI translations > >for all Telephone Numbers for which they have service control. > > > >Classic Telephone Number to PSTN routing mechanisms are well understood and > >the exchange of such inter-carrier data is well defined in the various SS7 > >and Number Portability mechanisms. Were service providers not able to > >exchange routing information no service would ever connect to another. > > > >The requirements of a Carrier TN to URI translation mechanism requires that > >the data be completely authenticated by the SP for ALL endpoints under its > >service control so that the aggregate inter-carrier database of all TN to > >URI translations is considered authoritative and reliable. > > > >Since the data is designed to permit optimized inter-carrier routing and > >nothing else, there is no requirement that the data be globally accessible > >or visible. In fact for security and privacy reasons reasons the exact > >opposite is true. > > > >What seems to be clear that in the absence of authoritative, authenticated > >and reliable inter-carrier TN to URI database for voice communications > >services the default routing mechanism is the PSTN and for any number of > >reasons that is not a good idea in the long run. > > > >ENUM RFC 3761 defined one mechanism by which TN to URI translations could > >be accomplished for the General Case of Internet users using the DNS as the > >query-response mechanism. National Regulatory Authorities have generally > >defined the administrative policies and procedures surrounding 3761 as > >being OPT-IN for consumers, therefore the e164.arpa database may not be > >complete. And as a side bar, there are still significant problems in > >delegating various portions of the e164.arpa tree as of this date. > > > >The Carrier TN 2 URI service is clearly another case for a different set of > >users that has a different set of requirements which _may _require a > >different technical query-response solution. This problem is much more > >roughly analogous to the problem of route announcements in BGP than the DNS > >(probably bad analogy) . > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >Richard Shockey, Senior Manager, Strategic Technology Initiatives > >NeuStar Inc. > >46000 Center Oak Plaza - Sterling, VA 20166 > >sip:rshockey(at)iptel.org ENUM +87810-13313-31331 > >PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 > >815.333.1237 > > or > > ; > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > >_______________________________________________ > >enum mailing list > >enum at ietf.org > >https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 21 Jun 2004 01:37:26 -0400 From: Jeff Williams Date: Mon, 21 Jun 2004 01:37:26 -0400 To: Peter Williams Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: Message-ID: <40D68C73.B5196DD4@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter and all, Peter Williams wrote: > >From: Jeff Williams > >To: Stastny Richard > >CC: enum at ietf.org, Richard Shockey > >Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda > >Date: Sun, 20 Jun 2004 19:42:26 -0700 > > > >Stastny and all, > > > >Stastny Richard wrote: > > > > > So given Steven questions, my "User ENUM" definitions > > > and Richards "Carrier TN to URI translation mechanisms" aka "Carrier > >ENUM", > > > > > > I want to try to give an answer to question 1b first, before I address > >1a > > > > > > a: within User ENUM there exist privacy issues. > > > set-up properly these issues do not exist in "Carrier ENUM", > > > because either the information is not accessible or not usable > > > by end-users. > > > Note: all privacy issues with ENUM should thereore be discussed > > > in the first half of the meeting, not in the mini-BoF on "Carrier > >ENUM" > > > > Good point. > > This is not appropriate, in my view. The reasoning is very flawed. There is > a relationship between holder of the E.164 and the ENUM provider. While > end-users may be unable to gain access to the marketing information derived > from the providers analyis of the transactions for a given ENUM name, > listing beneath e164.arpa (or elsewhere), the provider may seek to sell this > information about the holder to value-added resellers, folk sellling > additional telematic services, etc etc. This is quite typical in the US, and > is what the US privacy policy apparatus is designed to codify, and disclose > (even if it provides little in the way of enfocement) - so subscribers are > at least notified of the possible arrangements that may impact their wider > use of telematics. > > > Remember to distinguish between privacy, and security folks. Providing > wonderful access conrol security by DNS or procedural means has no relevance > to the privacy issues which we mut address in our engineering work on a > public lookup service. Privacy is about information reuse, and disclousre of > the possible reuses by all involved parties, including providers. In many > cases, the most blatant privacy abuses do NORMALLY not involve the end-users > directly: they involve selling information about end-users by providers and > others with whom the end-user has no contractual relationships. Given your own comments and remarks here Peter, I would disagree that there is a separation between privacy and security, they are directly as well as indirectly. If a provider can and does sell such user ENUM data to any other party, the security of those users at that point is jeopardized. This can by in large, but not completely eliminated/reduced if the standards track is inclusive of the necessary provisions. These were already discussed and discounted as not necessary at that time. Bad idea, that. > > > Remember, it took IETF over 15 years of hard work to privacy-enhace our > email standards, with CA policy disclosures etc. We bridged complex legal > work about digital signatures and CAs, and simple crypto work. And it took > us over 10 years to secure IPSEC. If if takes as long to privacy enhance or > secure ENUM protocols, so be it. It shouldn't take anywhere near 10 years to address security and privacy issues with the ENUM standards track unless anti-privacy bigots wish to be continually disruptive... > > > Peter. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Mon, 21 Jun 2004 02:33:27 -0400 From: "Clive D.W. Feather" Date: Mon, 21 Jun 2004 02:33:27 -0400 To: "Fullbrook Kim (UK)" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <20040621062512.GA33605@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Fullbrook Kim (UK) said: > Drawing an analogy with basic PSTN landline service. I'm not sure how it is > in other countries but here in the UK you can choose to have your name and > phone number included in the regional phone book or you can choose not to > (and pay some money not to, but that's a different issue). Free opt-out is a legal requirement throughout the EU. -- 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 clive@demon.net Mon, 21 Jun 2004 02:38:40 -0400 From: "Clive D.W. Feather" Date: Mon, 21 Jun 2004 02:38:40 -0400 To: Jeff Williams Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <20040621062815.GB33605@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Jeff Williams said: > You again misunderstood what I said. That may be my fault however. > So I will try to be more precise. The user should be able to have either > opt-in or opt-out regardless of which tree. And that in the current > protocol is not provided for, and easily could be. That's nonsense. I can't opt out of the telco switching database, nor should I be able to. -- 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 Mon, 21 Jun 2004 03:18:57 -0400 From: "Stastny Richard" Date: Mon, 21 Jun 2004 03:18:57 -0400 To: "Peter Williams" Subject: RE: AW: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: <06CF906FE3998C4E944213062009F16244378B@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter Williams wrote: > > > a: within User ENUM there exist privacy issues. > > > set-up properly these issues do not exist in "Carrier ENUM", > > > because either the information is not accessible or not usable > > > by end-users. > > > Note: all privacy issues with ENUM should thereore be discussed > > > in the first half of the meeting, not in the mini-BoF on "Carrier > >ENUM" > > > > Good point. > > > This is not appropriate, in my view. The reasoning is very flawed. There > is > a relationship between holder of the E.164 and the ENUM provider. While > end-users may be unable to gain access to the marketing information > derived > from the providers analyis of the transactions for a given ENUM name, > listing beneath e164.arpa (or elsewhere), the provider may seek to sell > this > information about the holder to value-added resellers, folk sellling > additional telematic services, etc etc. This is quite typical in the US, > and > is what the US privacy policy apparatus is designed to codify, and > disclose > (even if it provides little in the way of enfocement) - so subscribers are > at least notified of the possible arrangements that may impact their wider > use of telematics. > [Richard>] With setting it up properly I meant that the privacy data is secured from end-user access by established means. Period. There are now already a bunch of privacy data out in databases, more or less protected. The more or less is none of our business. That companies may resell this data may happen, but in Europe this is not allowed without subscriber consent by the data protective laws. If this is different in US, go change the law, but I do not think IETF is the right place to do this. If somebody within a company is breaking the law, there is no means by a protocol or architecture to prevent this. So there is no reason to discuss or bemoan this in the ENUM WG or the mini-BOF on carrier ENUM, it is a complete waste of time. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 21 Jun 2004 12:07:43 -0400 From: Richard Shockey Date: Mon, 21 Jun 2004 12:07:43 -0400 To: "Peter Williams" Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: Message-ID: <6.1.0.6.2.20040621092632.03895940@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:43 AM 6/21/2004, Peter Williams wrote: Zone administration in the context of 3761 is the nation-state national regulatory authority period ..end of story.  That is the way it is in order to preserve and protect the integrity of the ITU E.164 numbering plan. It will not change, ergo further discussion of this matter is a waste of electrons. Lets be more careful, and perhaps more informative and precise. Can you cite the IS<->ITU-T agreement pertaining to this specific issue, please. [RFC3026] Blaine, R. "Liaison to IETF/ISOC on ENUM" RFC 3026, January 2001  [RFC 3245] Klensin, J. Editor "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions:  Informational Documents Contributed to ITU-T Study Group 2  (SG2)", RFC 3245, March 2002 Interim Procedures for the delegation of E.164 Shared Country Codes for Networks and Groups of Countries;   http://www.itu.int/ITU-T/inr/enum/procedures.html,       http://www.itu.int/ITU-T/inr/enum/procedures-02.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza  -   Sterling, VA  20166 sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 21 Jun 2004 19:45:31 -0400 From: Mike Hammer Date: Mon, 21 Jun 2004 19:45:31 -0400 To: Jeff Williams Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <4.3.2.7.2.20040621191343.00b7a8c0@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jeff, Just out of curiosity, how did the opt-in versus opt-out issue play out with other domain names in the DNS? Is it possible to have a domain name not in DNS that is useful? Also, are you asserting that having an entry in User ENUM and privacy are mutually exclusive? (That it is impossible by the content of the record in ENUM to provide privacy?) An E.164 number could be viewed as a public resource that is assigned to you to aid in establishing connections through the collective public telephone network. It would not make sense to allow users to take E.164 numbers out of circulation and thus cause everyone else's number to have to increase in length (any more than necessary) as a result. I'm trying to understand the model whereby you move the number to the IP domain, but then don't put it into ENUM to enable calls to be routed to it. Perhaps you could clarify what it means to opt-out or not opt-in? Not for or against anything just yet, just trying to understand exactly what data you consider private versus public. Mike At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: Stastny and all, Stastny Richard wrote: > Jeff Williams writes: > >And this to a very great degree is what is wrong with the standards > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > They did. The ENUM protocol as defined in IETF can be implemented > in both ways, athough NOT in the same tree, because the both options > are mutually exclusive. You again misunderstood what I said. That may be my fault however. So I will try to be more precise. The user should be able to have either opt-in or opt-out regardless of which tree. And that in the current protocol is not provided for, and easily could be. > > > Let me explain: Opt-in means that at the beginning nobody is in and the > end-user decides if he wants to be in to get this service. This is the case > with User ENUM, which is an add-on service. Yes I already knew this, so this exercise is not necessary... > The underlying service > is his phone service and this phone service is working regadless if > he is in ENUM or not (with the exception of ENUM-enable numbers, > which are operating only if you are in User ENUM, but nobody is > forced to use these numbers) Again yes I also already knew this as well. And here is one of the problem areas in the current standards track protocol. If you do not choose as a User ENUM to use these numbers you effectively do not have ENUM capability which is a trap that is by design, and bad design at that, to pressure any user to use these numbers and therefore expose themselves to privacy violations or intrusion of various sorts unnecessarily. > > > The end-user has the additional choice how much information he > discloses: the minimum requirement is the number itself and the > operator, if he puts in e.g. sip:+43xxx at provider.net. Yes and the minimum requirement is another area where the user is exposed to privacy intrusions as he/she need need not have to have the number disclosed or even listed or viewable in DNS records, but still available to law enforcement agencies upon notification of the user in advance. > Additional > information between caller and callee may be exchanges via > negotiation between servers (as in SIP) or Personal User Agents > as proposed in UCI. The end-user may also decide on his discretion > to put in more information as he likes, especially a company. This I also already knew. And the proposed UCI is a bit too loosely worded as to whom decides what the user can direct his/her "personal agent" to disclose and whether any restrictions are at the users discretion. Hence exposing the user to potential further damage should said personal agent decide without prior consent, such disclosures... > > > Opt-out would mean that everybody is in and the end-user decides not > to be in. If a provider decides to implement the basic communication service > based on ENUM, he MUST put all users using this service in ENUM Yes, and this I also already knew and again exposes unnecessarily the user to potential privacy intrusions of obvious and already discussed various sorts. > > > Using ENUM for a service is currently also opt-in, but for the provider as > a whole with all of his numbers. There is no opt-out for the individual > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > but in separate tree. It is opt-in currently because there is still the PSTN around > to reach providers not in Infrastructure ENUM by default. If the PSTN ceases > to exists at some point of time, another default method need to be defined if > E.164 numbering is still around. This may be ENUM or maybe not. Yes again exactly right, and I already knew as well as demonstrates that anti-privacy bigots do not wish of users to have opt-out for reasons that are of a political and philosophical nature which may or may not be shared by some of many users and also not in concert with EU's for instance, laws. > > > Up to this point of time, different trees may be used by different groups > of service providers (confederation), this is already happening. A service > provider may even participate in different trees at the same time. > > These trees may either be trees only accessible by participants of the > confederation (either in extranets or with access control), but not > on the public Internet, or if accessible by the public, the information > is either not accessible, encrypted or useless for the normal end-user. > > There is also a difference between the information contained in > the trees. > > In User ENUM the information points to end-points, > giving one ore more URIs where the end-user has his services. > Different NAPTRs may point to different service providers. > The domain name holder is the end-user. Right, and as the user does not own his/her domain name currently he/she is exposed to others making many privacy and security decisions for him/her depending on the service agreement the provider has or may change from time to time. > > > In Infrastructure ENUM the entry points in principle to > the destination network providing the service for this number. > The domain name holder is the service provider. Right if and when the Domain Name holder is also the service provider which would not be the case in most instances... > > > All this together precludes User ENUM and Infrastructure > ENUM to be in the same tree (even the delegation structure > may be differnent). > > Of course User ENUM and Infrastructure ENUM may co-exist, > any user listed in one or more Infrastructure trees may also > request an entry in User ENUM. The provider may also offer > to the calling customer a service in such a way that first User > ENUM queried and then Infrastructure ENUM. This is already > implemented in some SIP servers and works. (Note: why should > the provider do this? Because the user may do this by himself also. > It is kinda carrier selection ;-) > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > explaining all these issues. Yes I have seen early parts of this draft.. > > > BTW: there is one complication emerging at the moment: > Confederations also want Infrastructure ENUM to be used > for routing of transit calls, e.g. an provider is publishing number > ranges in a confederation tree he is serving on the PSTN with his > gateways. This is in principle feasable, but will cause serious problems > in the future, especially if two confederations decide to merge there > trees. If one numbers are entered by providers which are assigned > to them, no conflicts could arise if trees are merged. Agreed that there could be some problems in the instances where said confederations are merged for some reason or another such as a business merger or buyout. But again they can be overcome without intruding either previous confederations users discretion regarding any privacy exposures. > > > If numbers are entered by providers not assigned to them, this > will cause policy problems and conflicts. These conflicts cannot > be resolved in ENUM, because it is not designed for it. Other > protocols like TRIP or OSP should be used for this. > > Richard: > To Jeff: You know what my problem with all privacy advocates is? > > They are trespassing my privacy by trying to limit my freedom of decision, > including my human right to make idiotic decisions ;-) Hummm? Well I honestly don't see how such a situation is relevant or even possible. Freedom to choose is also a part of protecting anyone's privacy. Idiotic decisions by someone that does so for others, knowingly of that or those persons is a responsibility of great gravity sometimes. For oneself, and only effecting oneself, idiotic decisions are of course expectable however damaging to oneself only, they may be... Ask yourself, do you NEED access to my ENUM number? Does any network operator NEED unrestricted access to my ENUM number? Would access of any sort or at any level to any number other individuals, regardless of supposed status or position not have the increasing potential of the domain name holders ENUM number not expose him/her to potential if not eventual definite abuses of various sorts, some being of a life threatening nature? I believe the answer to this question to definitely be, YES. And THAT is not expectable and preventable if the current ENUM standards track/protocol incorporates at least most of the exposures now known and have been known for some time... Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ 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 Mon, 21 Jun 2004 19:53:46 -0400 From: Mike Hammer Date: Mon, 21 Jun 2004 19:53:46 -0400 To: Jeff Williams Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <4.3.2.7.2.20040621194702.0332ac00@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:25 AM 6/19/2004 -0700, Jeff Williams wrote: James and all, Right! It is becoming if the current standards track goes on unchecked, the White Pages and you as a user MUST be listed in it. Is there an RFC that specifies what are the mandatory elements in the record? While the white pages contains a person's name and number, I don't think a person's name is mandated in ENUM, is it? Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 21 Jun 2004 20:02:45 -0400 From: Jeff Williams Date: Mon, 21 Jun 2004 20:02:45 -0400 To: "Clive D.W. Feather" Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <40D78F32.5B347C45@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Clive and all, Clive D.W. Feather wrote: > Jeff Williams said: > > You again misunderstood what I said. That may be my fault however. > > So I will try to be more precise. The user should be able to have either > > opt-in or opt-out regardless of which tree. And that in the current > > protocol is not provided for, and easily could be. > > That's nonsense. I can't opt out of the telco switching database, nor > should I be able to. No what I said above was not nonsense. But your response is. I didn't suggest to opt-out of the telco switching database. I did suggest that that data should not be viewable or accessible in either tree. Big difference! >:) > > > -- > 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 | | Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 21 Jun 2004 20:13:50 -0400 From: Jeff Williams Date: Mon, 21 Jun 2004 20:13:50 -0400 To: Stastny Richard Subject: Re: AW: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F16244378B@oefeg-s02.oefeg.loc> Message-ID: <40D791BB.EDB0ADE6@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > Peter Williams wrote: > > > > a: within User ENUM there exist privacy issues. > > > > set-up properly these issues do not exist in "Carrier ENUM", > > > > because either the information is not accessible or not usable > > > > by end-users. > > > > Note: all privacy issues with ENUM should thereore be discussed > > > > in the first half of the meeting, not in the mini-BoF on "Carrier > > >ENUM" > > > > > > Good point. > > > > > > This is not appropriate, in my view. The reasoning is very flawed. There > > is > > a relationship between holder of the E.164 and the ENUM provider. While > > end-users may be unable to gain access to the marketing information > > derived > > from the providers analyis of the transactions for a given ENUM name, > > listing beneath e164.arpa (or elsewhere), the provider may seek to sell > > this > > information about the holder to value-added resellers, folk sellling > > additional telematic services, etc etc. This is quite typical in the US, > > and > > is what the US privacy policy apparatus is designed to codify, and > > disclose > > (even if it provides little in the way of enfocement) - so subscribers are > > at least notified of the possible arrangements that may impact their wider > > use of telematics. > > > [Richard>] With setting it up properly I meant that the privacy data > is secured from end-user access by established means. Period. > There are now already a bunch of privacy data out in databases, more > or less protected. The more or less is none of our business. Agreed to a point. The protocol/standards track can be designed to not allow for this to be the standard however, which is where I believe Richard, and certainly I and our members are at. > > > That companies may resell this data may happen, but in Europe > this is not allowed without subscriber consent by the data protective > laws. If this is different in US, go change the law, but I do > not think IETF is the right place to do this. Agreed here as well to a point. The IETF should only attempt to set good technical standards. However in doing so, it should consider privacy issues from that technical standards track in any and all proposed protocols. With ENUM amongst others the privacy element seems to be missing or ignored. > > > If somebody within a company is breaking the law, there is no > means by a protocol or architecture to prevent this. Also agreed here. But by designing ENUM to not provide for privacy intrusion can be accomplished before the fact. > So there is > no reason to discuss or bemoan this in the ENUM WG or the mini-BOF > on carrier ENUM, it is a complete waste of time. Disagreed here strongly! :( > > > Richard > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Tue, 22 Jun 2004 02:06:57 -0400 From: Jeff Williams Date: Tue, 22 Jun 2004 02:06:57 -0400 To: Mike Hammer Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <40D7A2EB.1AD5CE67@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike and all, I am sure I have stated this before on behalf of our members. However I will not post here how such methods can be deployed as to violating privacy through various nefarious technical means can be achieved as to do so would only serve to potentially provide those that would do so to have gotten a number of ideas by which using said methods could be added to their own and therefore used for nefarious purposes unnecessarily. I am guessing that you Mike know or know of some of the methods to which I am indirectly and on purpose referring to. The number assigned if publicly accessible or even viewable is in and of itself a privacy intrusion that should not be allowed. Same is true for operators of ENUM activated networks such a Telco's having same of similar access to said assigned numbers. In addition if a whois lookup would by default display a ENUM number assigned to that domain Name or Names in the case of a bulk whois look-up than those persons privacy has been compromised unnecessarily and could damage them in a number of ways such as stalking, identity theft of various sorts. Mike Hammer wrote: > Jeff, > > Just out of curiosity, how did the opt-in versus opt-out issue play out > with other domain names in the DNS? Is it possible to have a domain name > not in DNS that is useful? > > Also, are you asserting that having an entry in User ENUM and privacy are > mutually exclusive? (That it is impossible by the content of the record in > ENUM to provide privacy?) > > An E.164 number could be viewed as a public resource that is assigned to > you to aid in establishing connections through the collective public > telephone network. It would not make sense to allow users to take E.164 > numbers out of circulation and thus cause everyone else's number to have to > increase in length (any more than necessary) as a result. I'm trying to > understand the model whereby you move the number to the IP domain, but then > don't put it into ENUM to enable calls to be routed to it. Perhaps you > could clarify what it means to opt-out or not opt-in? > > Not for or against anything just yet, just trying to understand exactly > what data you consider private versus public. > > Mike > > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: > >Stastny and all, > > > >Stastny Richard wrote: > > > > > Jeff Williams writes: > > > >And this to a very great degree is what is wrong with the standards > > > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > > > > > They did. The ENUM protocol as defined in IETF can be implemented > > > in both ways, athough NOT in the same tree, because the both options > > > are mutually exclusive. > > > > You again misunderstood what I said. That may be my fault however. > >So I will try to be more precise. The user should be able to have either > >opt-in or opt-out regardless of which tree. And that in the current > >protocol is not provided for, and easily could be. > > > > > > > > > > > Let me explain: Opt-in means that at the beginning nobody is in and the > > > end-user decides if he wants to be in to get this service. This is the case > > > with User ENUM, which is an add-on service. > > > > Yes I already knew this, so this exercise is not necessary... > > > > > The underlying service > > > is his phone service and this phone service is working regadless if > > > he is in ENUM or not (with the exception of ENUM-enable numbers, > > > which are operating only if you are in User ENUM, but nobody is > > > forced to use these numbers) > > > > Again yes I also already knew this as well. And here is one of the > >problem areas in the current standards track protocol. If you do not > >choose as a User ENUM to use these numbers you effectively do > >not have ENUM capability which is a trap that is by design, and bad > >design at that, to pressure any user to use these numbers and therefore > >expose themselves to privacy violations or intrusion of various sorts > >unnecessarily. > > > > > > > > > > > The end-user has the additional choice how much information he > > > discloses: the minimum requirement is the number itself and the > > > operator, if he puts in e.g. sip:+43xxx at provider.net. > > > > Yes and the minimum requirement is another area where the user > >is exposed to privacy intrusions as he/she need need not have to > >have the number disclosed or even listed or viewable in DNS > >records, but still available to law enforcement agencies upon > >notification of the user in advance. > > > > > > > Additional > > > information between caller and callee may be exchanges via > > > negotiation between servers (as in SIP) or Personal User Agents > > > as proposed in UCI. The end-user may also decide on his discretion > > > to put in more information as he likes, especially a company. > > > >This I also already knew. And the proposed UCI is a bit too loosely > >worded as to whom decides what the user can direct his/her > >"personal agent" to disclose and whether any restrictions are > >at the users discretion. Hence exposing the user to potential > >further damage should said personal agent decide without prior > >consent, such disclosures... > > > > > > > > > > > Opt-out would mean that everybody is in and the end-user decides not > > > to be in. If a provider decides to implement the basic communication > > service > > > based on ENUM, he MUST put all users using this service in ENUM > > > > Yes, and this I also already knew and again exposes unnecessarily the > >user to potential privacy intrusions of obvious and already discussed > >various sorts. > > > > > > > > > > > Using ENUM for a service is currently also opt-in, but for the provider as > > > a whole with all of his numbers. There is no opt-out for the individual > > > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > > > but in separate tree. It is opt-in currently because there is still the > > PSTN around > > > to reach providers not in Infrastructure ENUM by default. If the PSTN > > ceases > > > to exists at some point of time, another default method need to be > > defined if > > > E.164 numbering is still around. This may be ENUM or maybe not. > > > > Yes again exactly right, and I already knew as well as demonstrates that > >anti-privacy bigots do not wish of users to have opt-out for reasons that > >are of a political and philosophical nature which may or may not be shared > >by some of many users and also not in concert with EU's for instance, > >laws. > > > > > > > > > > > Up to this point of time, different trees may be used by different groups > > > of service providers (confederation), this is already happening. A service > > > provider may even participate in different trees at the same time. > > > > > > These trees may either be trees only accessible by participants of the > > > confederation (either in extranets or with access control), but not > > > on the public Internet, or if accessible by the public, the information > > > is either not accessible, encrypted or useless for the normal end-user. > > > > > > There is also a difference between the information contained in > > > the trees. > > > > > > In User ENUM the information points to end-points, > > > giving one ore more URIs where the end-user has his services. > > > Different NAPTRs may point to different service providers. > > > The domain name holder is the end-user. > > > > Right, and as the user does not own his/her domain name currently > >he/she is exposed to others making many privacy and security decisions > >for him/her depending on the service agreement the provider has or > >may change from time to time. > > > > > > > > > > > In Infrastructure ENUM the entry points in principle to > > > the destination network providing the service for this number. > > > The domain name holder is the service provider. > > > > Right if and when the Domain Name holder is also the service > >provider which would not be the case in most instances... > > > > > > > > > > > All this together precludes User ENUM and Infrastructure > > > ENUM to be in the same tree (even the delegation structure > > > may be differnent). > > > > > > Of course User ENUM and Infrastructure ENUM may co-exist, > > > any user listed in one or more Infrastructure trees may also > > > request an entry in User ENUM. The provider may also offer > > > to the calling customer a service in such a way that first User > > > ENUM queried and then Infrastructure ENUM. This is already > > > implemented in some SIP servers and works. (Note: why should > > > the provider do this? Because the user may do this by himself also. > > > It is kinda carrier selection ;-) > > > > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > > > explaining all these issues. > > > > Yes I have seen early parts of this draft.. > > > > > > > > > > > BTW: there is one complication emerging at the moment: > > > Confederations also want Infrastructure ENUM to be used > > > for routing of transit calls, e.g. an provider is publishing number > > > ranges in a confederation tree he is serving on the PSTN with his > > > gateways. This is in principle feasable, but will cause serious problems > > > in the future, especially if two confederations decide to merge there > > > trees. If one numbers are entered by providers which are assigned > > > to them, no conflicts could arise if trees are merged. > > > > Agreed that there could be some problems in the instances where > >said confederations are merged for some reason or another such > >as a business merger or buyout. But again they can be overcome > >without intruding either previous confederations users discretion > >regarding any privacy exposures. > > > > > > > > > > > If numbers are entered by providers not assigned to them, this > > > will cause policy problems and conflicts. These conflicts cannot > > > be resolved in ENUM, because it is not designed for it. Other > > > protocols like TRIP or OSP should be used for this. > > > > > > Richard: > > > To Jeff: You know what my problem with all privacy advocates is? > > > > > > They are trespassing my privacy by trying to limit my freedom of decision, > > > including my human right to make idiotic decisions ;-) > > > > Hummm? Well I honestly don't see how such a situation is relevant > >or even possible. Freedom to choose is also a part of protecting > >anyone's privacy. Idiotic decisions by someone that does so for > >others, knowingly of that or those persons is a responsibility of > >great gravity sometimes. For oneself, and only effecting oneself, > >idiotic decisions are of course expectable however damaging > >to oneself only, they may be... > > > > Ask yourself, do you NEED access to my ENUM number? > >Does any network operator NEED unrestricted access to my > >ENUM number? Would access of any sort or at any level > >to any number other individuals, regardless of supposed status > >or position not have the increasing potential of the domain name > >holders ENUM number not expose him/her to potential if not > >eventual definite abuses of various sorts, some being of a > >life threatening nature? I believe the answer to this question > >to definitely be, YES. And THAT is not expectable and > >preventable if the current ENUM standards track/protocol > >incorporates at least most of the exposures now known and > >have been known for some time... > > > >Regards, > > > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > >"Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > >"If the probability be called P; the injury, L; and the burden, B; > >liability depends upon whether B is less than L multiplied by > >P: i.e., whether B is less than PL." > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > >=============================================================== > >Updated 1/26/04 > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > >IDNS. div. of Information Network Eng. INEG. INC. > >E-Mail jwkckid1 at ix.netcom.com > > Registered Email addr with the USPS > >Contact Number: 214-244-4827 > > > > > > > >_______________________________________________ > >enum mailing list > >enum at ietf.org > >https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Tue, 22 Jun 2004 08:54:53 -0400 From: James Seng Date: Tue, 22 Jun 2004 08:54:53 -0400 To: Mike Hammer Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40D7D14E.8020705@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R as far as i know, the RFC is silent on how you want to use it. so basically you have the right to use it in stupid ways, if you wish to. that to me is a good engineering design :- one that allow good things to happen but also does not prevent stupid things. the latter may turn out to be smart in some other ways in future..you never know. thus, policies on privacies are interested and definately important, but that discussion to bring it to another forum, e.g. Numbering Authority of each country. On the other hand, this is not to say we dont discuss it at all :- I am all for discussing "Considerations of Privacy in ENUM" altho I am more relucant to discuss "Privacy Statement for ENUM". Lets not pretend IETF can do global policy. ps: In case anyone wonders what I am doing in Singapore for privacy, I am advocating we publish only records that users wants to publish and absolutely no WHOIS or (horror!) CRISP. -James Seng Mike Hammer wrote: At 12:25 AM 6/19/2004 -0700, Jeff Williams wrote: James and all, Right! It is becoming if the current standards track goes on unchecked, the White Pages and you as a user MUST be listed in it. Is there an RFC that specifies what are the mandatory elements in the record? While the white pages contains a person's name and number, I don't think a person's name is mandated in ENUM, is it? Mike _______________________________________________ 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 Tue, 22 Jun 2004 08:55:43 -0400 From: "Stastny Richard" Date: Tue, 22 Jun 2004 08:55:43 -0400 To: "Mike Hammer" Subject: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F162443797@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike wrote: > Is it possible to have a domain name not in DNS that is useful? I like this one. It is the perfect answer to Jeffs: >The number assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed. Just wondering he is not calling this an abomination. I could reword this according to Mike to: >A domain name assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed. Lucky me that I have already stastny.com, but this should be taken away now by Jeff and his members? Who are you or the group you are speaking on behalf of to allow or not allow me to have stastny.com. I consider THIS a severe privacy intrusion near to religious fundamentalism. May I cite here another philosopher: Das Böse ist der Glaube zu wissen, was das Gute sei (Rudolf Burger). The evil is the faith to know what the good is. So I come back to Lessig's? statement that if the Internet would not be around since fifty years (it just happened), it would be impossible to design and to deploy it now. There are many reasons for the correctness of this statement, but one definitely would be the still ongoing privacy discussion: - is it allowed to connect a host directly via a public IP address to the Internet. - is it allowed to have a public visible domain. - is it allowed to query a webpage just to see if it is accessible - is it allowed to post a webpage everybody can access and is it allowed to read such a page. Shouldn't there be a contract set up by lawyers beforehand? - is it allowed to know an e-mail address of somebody and send an e-mail to - is it allowed to put a webcam in my bedroom - and so on and on Also a public white page phone book is an obscenity in itself It should not be allowed (BTW: in the old days there was no such thing in the USSR) IETF is a technical body, but in the last week on this list no technical issues whatsoever have been discussed, only political and philosophical. See Richard > -----Original Message----- > From: Mike Hammer [mailto:mhammer at cisco.com] > Sent: Tuesday, June 22, 2004 1:30 AM > To: Jeff Williams; Stastny Richard > Cc: enum at ietf.org > Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > Jeff, > > Just out of curiosity, how did the opt-in versus opt-out issue play out > with other domain names in the DNS? Is it possible to have a domain name > not in DNS that is useful? > > Also, are you asserting that having an entry in User ENUM and privacy are > mutually exclusive? (That it is impossible by the content of the record > in > ENUM to provide privacy?) > > An E.164 number could be viewed as a public resource that is assigned to > you to aid in establishing connections through the collective public > telephone network. It would not make sense to allow users to take E.164 > numbers out of circulation and thus cause everyone else's number to have > to > increase in length (any more than necessary) as a result. I'm trying to > understand the model whereby you move the number to the IP domain, but > then > don't put it into ENUM to enable calls to be routed to it. Perhaps you > could clarify what it means to opt-out or not opt-in? > > Not for or against anything just yet, just trying to understand exactly > what data you consider private versus public. > > Mike > > > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: > >Stastny and all, > > > >Stastny Richard wrote: > > > > > Jeff Williams writes: > > > >And this to a very great degree is what is wrong with the standards > > > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > > > > > They did. The ENUM protocol as defined in IETF can be implemented > > > in both ways, athough NOT in the same tree, because the both options > > > are mutually exclusive. > > > > You again misunderstood what I said. That may be my fault however. > >So I will try to be more precise. The user should be able to have either > >opt-in or opt-out regardless of which tree. And that in the current > >protocol is not provided for, and easily could be. > > > > > > > > > > > Let me explain: Opt-in means that at the beginning nobody is in and > the > > > end-user decides if he wants to be in to get this service. This is the > case > > > with User ENUM, which is an add-on service. > > > > Yes I already knew this, so this exercise is not necessary... > > > > > The underlying service > > > is his phone service and this phone service is working regadless if > > > he is in ENUM or not (with the exception of ENUM-enable numbers, > > > which are operating only if you are in User ENUM, but nobody is > > > forced to use these numbers) > > > > Again yes I also already knew this as well. And here is one of the > >problem areas in the current standards track protocol. If you do not > >choose as a User ENUM to use these numbers you effectively do > >not have ENUM capability which is a trap that is by design, and bad > >design at that, to pressure any user to use these numbers and therefore > >expose themselves to privacy violations or intrusion of various sorts > >unnecessarily. > > > > > > > > > > > The end-user has the additional choice how much information he > > > discloses: the minimum requirement is the number itself and the > > > operator, if he puts in e.g. sip:+43xxx at provider.net. > > > > Yes and the minimum requirement is another area where the user > >is exposed to privacy intrusions as he/she need need not have to > >have the number disclosed or even listed or viewable in DNS > >records, but still available to law enforcement agencies upon > >notification of the user in advance. > > > > > > > Additional > > > information between caller and callee may be exchanges via > > > negotiation between servers (as in SIP) or Personal User Agents > > > as proposed in UCI. The end-user may also decide on his discretion > > > to put in more information as he likes, especially a company. > > > >This I also already knew. And the proposed UCI is a bit too loosely > >worded as to whom decides what the user can direct his/her > >"personal agent" to disclose and whether any restrictions are > >at the users discretion. Hence exposing the user to potential > >further damage should said personal agent decide without prior > >consent, such disclosures... > > > > > > > > > > > Opt-out would mean that everybody is in and the end-user decides not > > > to be in. If a provider decides to implement the basic communication > > service > > > based on ENUM, he MUST put all users using this service in ENUM > > > > Yes, and this I also already knew and again exposes unnecessarily the > >user to potential privacy intrusions of obvious and already discussed > >various sorts. > > > > > > > > > > > Using ENUM for a service is currently also opt-in, but for the > provider as > > > a whole with all of his numbers. There is no opt-out for the > individual > > > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > > > but in separate tree. It is opt-in currently because there is still > the > > PSTN around > > > to reach providers not in Infrastructure ENUM by default. If the PSTN > > ceases > > > to exists at some point of time, another default method need to be > > defined if > > > E.164 numbering is still around. This may be ENUM or maybe not. > > > > Yes again exactly right, and I already knew as well as demonstrates > that > >anti-privacy bigots do not wish of users to have opt-out for reasons that > >are of a political and philosophical nature which may or may not be > shared > >by some of many users and also not in concert with EU's for instance, > >laws. > > > > > > > > > > > Up to this point of time, different trees may be used by different > groups > > > of service providers (confederation), this is already happening. A > service > > > provider may even participate in different trees at the same time. > > > > > > These trees may either be trees only accessible by participants of > the > > > confederation (either in extranets or with access control), but not > > > on the public Internet, or if accessible by the public, the > information > > > is either not accessible, encrypted or useless for the normal end-user. > > > > > > There is also a difference between the information contained in > > > the trees. > > > > > > In User ENUM the information points to end-points, > > > giving one ore more URIs where the end-user has his services. > > > Different NAPTRs may point to different service providers. > > > The domain name holder is the end-user. > > > > Right, and as the user does not own his/her domain name currently > >he/she is exposed to others making many privacy and security decisions > >for him/her depending on the service agreement the provider has or > >may change from time to time. > > > > > > > > > > > In Infrastructure ENUM the entry points in principle to > > > the destination network providing the service for this number. > > > The domain name holder is the service provider. > > > > Right if and when the Domain Name holder is also the service > >provider which would not be the case in most instances... > > > > > > > > > > > All this together precludes User ENUM and Infrastructure > > > ENUM to be in the same tree (even the delegation structure > > > may be differnent). > > > > > > Of course User ENUM and Infrastructure ENUM may co-exist, > > > any user listed in one or more Infrastructure trees may also > > > request an entry in User ENUM. The provider may also offer > > > to the calling customer a service in such a way that first User > > > ENUM queried and then Infrastructure ENUM. This is already > > > implemented in some SIP servers and works. (Note: why should > > > the provider do this? Because the user may do this by himself also. > > > It is kinda carrier selection ;-) > > > > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > > > explaining all these issues. > > > > Yes I have seen early parts of this draft.. > > > > > > > > > > > BTW: there is one complication emerging at the moment: > > > Confederations also want Infrastructure ENUM to be used > > > for routing of transit calls, e.g. an provider is publishing number > > > ranges in a confederation tree he is serving on the PSTN with his > > > gateways. This is in principle feasable, but will cause serious > problems > > > in the future, especially if two confederations decide to merge there > > > trees. If one numbers are entered by providers which are assigned > > > to them, no conflicts could arise if trees are merged. > > > > Agreed that there could be some problems in the instances where > >said confederations are merged for some reason or another such > >as a business merger or buyout. But again they can be overcome > >without intruding either previous confederations users discretion > >regarding any privacy exposures. > > > > > > > > > > > If numbers are entered by providers not assigned to them, this > > > will cause policy problems and conflicts. These conflicts cannot > > > be resolved in ENUM, because it is not designed for it. Other > > > protocols like TRIP or OSP should be used for this. > > > > > > Richard: > > > To Jeff: You know what my problem with all privacy advocates is? > > > > > > They are trespassing my privacy by trying to limit my freedom of > decision, > > > including my human right to make idiotic decisions ;-) > > > > Hummm? Well I honestly don't see how such a situation is relevant > >or even possible. Freedom to choose is also a part of protecting > >anyone's privacy. Idiotic decisions by someone that does so for > >others, knowingly of that or those persons is a responsibility of > >great gravity sometimes. For oneself, and only effecting oneself, > >idiotic decisions are of course expectable however damaging > >to oneself only, they may be... > > > > Ask yourself, do you NEED access to my ENUM number? > >Does any network operator NEED unrestricted access to my > >ENUM number? Would access of any sort or at any level > >to any number other individuals, regardless of supposed status > >or position not have the increasing potential of the domain name > >holders ENUM number not expose him/her to potential if not > >eventual definite abuses of various sorts, some being of a > >life threatening nature? I believe the answer to this question > >to definitely be, YES. And THAT is not expectable and > >preventable if the current ENUM standards track/protocol > >incorporates at least most of the exposures now known and > >have been known for some time... > > > >Regards, > > > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > >"Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > >"If the probability be called P; the injury, L; and the burden, B; > >liability depends upon whether B is less than L multiplied by > >P: i.e., whether B is less than PL." > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > >=============================================================== > >Updated 1/26/04 > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > >IDNS. div. of Information Network Eng. INEG. INC. > >E-Mail jwkckid1 at ix.netcom.com > > Registered Email addr with the USPS > >Contact Number: 214-244-4827 > > > > > > > >_______________________________________________ > >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 Tue, 22 Jun 2004 08:55:45 -0400 From: "Stastny Richard" Date: Tue, 22 Jun 2004 08:55:45 -0400 To: Subject: FW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F162443798@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R So privacy is already implemented within Cisco ;-) It says that I have no right to send messages to this recipient. Is the systemadministrator with Cisco also a lawyer? This would also be a solution for privacy in ENUM: You publish numbers but you cannot reach them Problem solved Richard -----Original Message----- From: Systemadministrator Sent: Tuesday, June 22, 2004 10:06 AM To: mhammer at cisco.com Subject: Unzustellbar: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Ihre Nachricht hat einige oder alle Empfanger nicht erreicht. Betreff: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Gesendet am: 22.06.2004 10:05 Folgende Empfanger konnten nicht erreicht werden: 'Mike Hammer' am 22.06.2004 10:06 Sie sind nicht berechtigt, Nachrichten an diesen Empfanger zu senden. Wenden Sie sich an den Systemadministrator. ... Relaying denied> _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Tue, 22 Jun 2004 18:29:56 -0400 From: Andrew Newton Date: Tue, 22 Jun 2004 18:29:56 -0400 To: "Stastny Richard" Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F162443797@oefeg-s02.oefeg.loc> Message-ID: <93B7505A-C45B-11D8-8D33-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jun 22, 2004, at 4:04 AM, Stastny Richard wrote: - is it allowed to know an e-mail address of somebody and send an e-mail to Not true anymore. There are many jurisdictions that restrict how email can be sent these days. Just because IETF protocols allow it, that doesn't mean it is always legal. Just as I can technically use the PSTN to call people at midnight to hock my wares, that doesn't mean it is right, ethical, or legal for me to do it. IETF is a technical body, but in the last week on this list no technical issues whatsoever have been discussed, only political and philosophical. The IETF should concern itself with the technical development of interoperable protocols. Those protocols should have mechanisms to address privacy concerns where reasonably possible. And the deployment and use of these mechanisms should be at the discretion of network operators based on the policy of their jurisdiction. Is it reasonable to modify DNS with privacy controls? Probably not. As the saying goes, "that cow is already out of the barn." Is it reasonable to look at the implications of privacy on the other parts of the network that ENUM may touch? Probably yes. There are many an IETF effort doing just that and within reason of their technical scope. EPP comes to mind. GEOPRIV has an excellent example of privacy within reason: when placing calls to emergency call centers, privacy of geo-location data is a secondary concern and must not prohibit the call from going through. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 22 Jun 2004 18:31:30 -0400 From: Mike Hammer Date: Tue, 22 Jun 2004 18:31:30 -0400 To: Jeff Williams Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <4.3.2.7.2.20040622151405.00b1ac00@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jeff, It is well known in security circles that "security through obscurity" is no security at all. Best not to design technical solutions around mechanisms that have not been well inspected by respected experts. The number in and of itself is not private and can not be made so, or the ability of the public telephone network can not work. (You can not by legal fiat force all the world's telephone operators to remove partial or full telephone numbers from their databases. It is not possible to doing routing correctly without them. I point out the parallels between ENUM and the LNP databases to show the folly and error of such positions. There are also nefarious purposes for taking E.164 number assignments and then not making use of them in the PSTN. It is not in the public interest to allow that to occur, and being in the IP-domain does not make a valid basis for an exception. You are on much safer ground when you argue that the linkage of other information, which could be deemed privacy-related (names, employer, postal addresses, geographic location, etc.) within databases is subject to the privacy laws of various countries. I would argue that for any E.164 number in the form of a domain name that is found within the DNS, if the resulting records point simply to information of a service or a service provider address that does not provide more information specific to an individual subscriber, then no privacy violation has occurred. Any messages sent to that address, be they http, email, im, sip, h323, or whatever can then be handled on their own terms. Routing happens. I understand that vagueness provides employment for many lawyers, but this is a case where ambiguity undermines a key infrastructure and the need for precision is paramount. Mike At 08:09 PM 6/21/2004 -0700, Jeff Williams wrote: Mike and all, I am sure I have stated this before on behalf of our members. However I will not post here how such methods can be deployed as to violating privacy through various nefarious technical means can be achieved as to do so would only serve to potentially provide those that would do so to have gotten a number of ideas by which using said methods could be added to their own and therefore used for nefarious purposes unnecessarily. I am guessing that you Mike know or know of some of the methods to which I am indirectly and on purpose referring to. The number assigned if publicly accessible or even viewable is in and of itself a privacy intrusion that should not be allowed. Same is true for operators of ENUM activated networks such a Telco's having same of similar access to said assigned numbers. In addition if a whois lookup would by default display a ENUM number assigned to that domain Name or Names in the case of a bulk whois look-up than those persons privacy has been compromised unnecessarily and could damage them in a number of ways such as stalking, identity theft of various sorts. Mike Hammer wrote: > Jeff, > > Just out of curiosity, how did the opt-in versus opt-out issue play out > with other domain names in the DNS? Is it possible to have a domain name > not in DNS that is useful? > > Also, are you asserting that having an entry in User ENUM and privacy are > mutually exclusive? (That it is impossible by the content of the record in > ENUM to provide privacy?) > > An E.164 number could be viewed as a public resource that is assigned to > you to aid in establishing connections through the collective public > telephone network. It would not make sense to allow users to take E.164 > numbers out of circulation and thus cause everyone else's number to have to > increase in length (any more than necessary) as a result. I'm trying to > understand the model whereby you move the number to the IP domain, but then > don't put it into ENUM to enable calls to be routed to it. Perhaps you > could clarify what it means to opt-out or not opt-in? > > Not for or against anything just yet, just trying to understand exactly > what data you consider private versus public. > > Mike > > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: > >Stastny and all, > > > >Stastny Richard wrote: > > > > > Jeff Williams writes: > > > >And this to a very great degree is what is wrong with the standards > > > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > > > > > They did. The ENUM protocol as defined in IETF can be implemented > > > in both ways, athough NOT in the same tree, because the both options > > > are mutually exclusive. > > > > You again misunderstood what I said. That may be my fault however. > >So I will try to be more precise. The user should be able to have either > >opt-in or opt-out regardless of which tree. And that in the current > >protocol is not provided for, and easily could be. > > > > > > > > > > > Let me explain: Opt-in means that at the beginning nobody is in and the > > > end-user decides if he wants to be in to get this service. This is the case > > > with User ENUM, which is an add-on service. > > > > Yes I already knew this, so this exercise is not necessary... > > > > > The underlying service > > > is his phone service and this phone service is working regadless if > > > he is in ENUM or not (with the exception of ENUM-enable numbers, > > > which are operating only if you are in User ENUM, but nobody is > > > forced to use these numbers) > > > > Again yes I also already knew this as well. And here is one of the > >problem areas in the current standards track protocol. If you do not > >choose as a User ENUM to use these numbers you effectively do > >not have ENUM capability which is a trap that is by design, and bad > >design at that, to pressure any user to use these numbers and therefore > >expose themselves to privacy violations or intrusion of various sorts > >unnecessarily. > > > > > > > > > > > The end-user has the additional choice how much information he > > > discloses: the minimum requirement is the number itself and the > > > operator, if he puts in e.g. sip:+43xxx at provider.net. > > > > Yes and the minimum requirement is another area where the user > >is exposed to privacy intrusions as he/she need need not have to > >have the number disclosed or even listed or viewable in DNS > >records, but still available to law enforcement agencies upon > >notification of the user in advance. > > > > > > > Additional > > > information between caller and callee may be exchanges via > > > negotiation between servers (as in SIP) or Personal User Agents > > > as proposed in UCI. The end-user may also decide on his discretion > > > to put in more information as he likes, especially a company. > > > >This I also already knew. And the proposed UCI is a bit too loosely > >worded as to whom decides what the user can direct his/her > >"personal agent" to disclose and whether any restrictions are > >at the users discretion. Hence exposing the user to potential > >further damage should said personal agent decide without prior > >consent, such disclosures... > > > > > > > > > > > Opt-out would mean that everybody is in and the end-user decides not > > > to be in. If a provider decides to implement the basic communication > > service > > > based on ENUM, he MUST put all users using this service in ENUM > > > > Yes, and this I also already knew and again exposes unnecessarily the > >user to potential privacy intrusions of obvious and already discussed > >various sorts. > > > > > > > > > > > Using ENUM for a service is currently also opt-in, but for the provider as > > > a whole with all of his numbers. There is no opt-out for the individual > > > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > > > but in separate tree. It is opt-in currently because there is still the > > PSTN around > > > to reach providers not in Infrastructure ENUM by default. If the PSTN > > ceases > > > to exists at some point of time, another default method need to be > > defined if > > > E.164 numbering is still around. This may be ENUM or maybe not. > > > > Yes again exactly right, and I already knew as well as demonstrates that > >anti-privacy bigots do not wish of users to have opt-out for reasons that > >are of a political and philosophical nature which may or may not be shared > >by some of many users and also not in concert with EU's for instance, > >laws. > > > > > > > > > > > Up to this point of time, different trees may be used by different groups > > > of service providers (confederation), this is already happening. A service > > > provider may even participate in different trees at the same time. > > > > > > These trees may either be trees only accessible by participants of the > > > confederation (either in extranets or with access control), but not > > > on the public Internet, or if accessible by the public, the information > > > is either not accessible, encrypted or useless for the normal end-user. > > > > > > There is also a difference between the information contained in > > > the trees. > > > > > > In User ENUM the information points to end-points, > > > giving one ore more URIs where the end-user has his services. > > > Different NAPTRs may point to different service providers. > > > The domain name holder is the end-user. > > > > Right, and as the user does not own his/her domain name currently > >he/she is exposed to others making many privacy and security decisions > >for him/her depending on the service agreement the provider has or > >may change from time to time. > > > > > > > > > > > In Infrastructure ENUM the entry points in principle to > > > the destination network providing the service for this number. > > > The domain name holder is the service provider. > > > > Right if and when the Domain Name holder is also the service > >provider which would not be the case in most instances... > > > > > > > > > > > All this together precludes User ENUM and Infrastructure > > > ENUM to be in the same tree (even the delegation structure > > > may be differnent). > > > > > > Of course User ENUM and Infrastructure ENUM may co-exist, > > > any user listed in one or more Infrastructure trees may also > > > request an entry in User ENUM. The provider may also offer > > > to the calling customer a service in such a way that first User > > > ENUM queried and then Infrastructure ENUM. This is already > > > implemented in some SIP servers and works. (Note: why should > > > the provider do this? Because the user may do this by himself also. > > > It is kinda carrier selection ;-) > > > > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > > > explaining all these issues. > > > > Yes I have seen early parts of this draft.. > > > > > > > > > > > BTW: there is one complication emerging at the moment: > > > Confederations also want Infrastructure ENUM to be used > > > for routing of transit calls, e.g. an provider is publishing number > > > ranges in a confederation tree he is serving on the PSTN with his > > > gateways. This is in principle feasable, but will cause serious problems > > > in the future, especially if two confederations decide to merge there > > > trees. If one numbers are entered by providers which are assigned > > > to them, no conflicts could arise if trees are merged. > > > > Agreed that there could be some problems in the instances where > >said confederations are merged for some reason or another such > >as a business merger or buyout. But again they can be overcome > >without intruding either previous confederations users discretion > >regarding any privacy exposures. > > > > > > > > > > > If numbers are entered by providers not assigned to them, this > > > will cause policy problems and conflicts. These conflicts cannot > > > be resolved in ENUM, because it is not designed for it. Other > > > protocols like TRIP or OSP should be used for this. > > > > > > Richard: > > > To Jeff: You know what my problem with all privacy advocates is? > > > > > > They are trespassing my privacy by trying to limit my freedom of decision, > > > including my human right to make idiotic decisions ;-) > > > > Hummm? Well I honestly don't see how such a situation is relevant > >or even possible. Freedom to choose is also a part of protecting > >anyone's privacy. Idiotic decisions by someone that does so for > >others, knowingly of that or those persons is a responsibility of > >great gravity sometimes. For oneself, and only effecting oneself, > >idiotic decisions are of course expectable however damaging > >to oneself only, they may be... > > > > Ask yourself, do you NEED access to my ENUM number? > >Does any network operator NEED unrestricted access to my > >ENUM number? Would access of any sort or at any level > >to any number other individuals, regardless of supposed status > >or position not have the increasing potential of the domain name > >holders ENUM number not expose him/her to potential if not > >eventual definite abuses of various sorts, some being of a > >life threatening nature? I believe the answer to this question > >to definitely be, YES. And THAT is not expectable and > >preventable if the current ENUM standards track/protocol > >incorporates at least most of the exposures now known and > >have been known for some time... > > > >Regards, > > > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > >"Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > >"If the probability be called P; the injury, L; and the burden, B; > >liability depends upon whether B is less than L multiplied by > >P: i.e., whether B is less than PL." > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > >=============================================================== > >Updated 1/26/04 > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > >IDNS. div. of Information Network Eng. INEG. INC. > >E-Mail jwkckid1 at ix.netcom.com > > Registered Email addr with the USPS > >Contact Number: 214-244-4827 > > > > > > > >_______________________________________________ > >enum mailing list > >enum at ietf.org > >https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 22 Jun 2004 18:32:48 -0400 From: Mike Hammer Date: Tue, 22 Jun 2004 18:32:48 -0400 To: "Stastny Richard" Subject: Re: FW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F162443798@oefeg-s02.oefeg.loc > Message-ID: <4.3.2.7.2.20040622172220.02ed2c00@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Not sure what you sent, but there is spam-checking software that may have filtered your message out for some reason (false positive). Unfortunately a lot does still get through. Mike At 10:15 AM 6/22/2004 +0200, Stastny Richard wrote: So privacy is already implemented within Cisco ;-) It says that I have no right to send messages to this recipient. Is the systemadministrator with Cisco also a lawyer? This would also be a solution for privacy in ENUM: You publish numbers but you cannot reach them Problem solved Richard -----Original Message----- From: Systemadministrator Sent: Tuesday, June 22, 2004 10:06 AM To: mhammer at cisco.com Subject: Unzustellbar: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Ihre Nachricht hat einige oder alle Empfanger nicht erreicht. Betreff: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Gesendet am: 22.06.2004 10:05 Folgende Empfanger konnten nicht erreicht werden: 'Mike Hammer' am 22.06.2004 10:06 Sie sind nicht berechtigt, Nachrichten an diesen Empfanger zu senden. Wenden Sie sich an den Systemadministrator. ... Relaying denied> _______________________________________________ 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 jwkckid1@ix.netcom.com Thu, 24 Jun 2004 12:41:41 -0400 From: Jeff Williams Date: Thu, 24 Jun 2004 12:41:41 -0400 To: Stastny Richard Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F162443797@oefeg-s02.oefeg.loc> Message-ID: <40D915C8.12AF03B8@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny and all, Stastny Richard wrote: > Mike wrote: > > Is it possible to have a domain name not in DNS that is useful? > > I like this one. It is the perfect answer to Jeffs: > >The number assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed. > > Just wondering he is not calling this an abomination. Not an abomination but close! >;) > > > I could reword this according to Mike to: > >A domain name assigned if publicly accessible or even viewable is in and of >itself a privacy intrusion that should not be allowed. Frist of all Mike didn't say/post this, I did... > > > Lucky me that I have already stastny.com, but this should > be taken away now by Jeff and his members? Of course not. But you or any domain name holder should be directing what aspects of his/her/it's registration data is publicly accessible. > > Who are you or the group you are speaking on behalf of to > allow or not allow me to have stastny.com. I consider THIS > a severe privacy intrusion near to religious fundamentalism. I never said you couldn't! But it seems you for some odd reason which I cannot pretend to reasonably understand, feel as though you should not have stastny.com. Go figure on that one is all I can say. However if you don't have stastny.com TM'ed you may in the future find a TM legal challenge to deal with. That can get costly. > > > May I cite here another philosopher: > Das Böse ist der Glaube zu wissen, was das Gute sei (Rudolf Burger). > The evil is the faith to know what the good is. Utter nonsense here I am afraid. > > > So I come back to Lessig's? statement that if the Internet would not > be around since fifty years (it just happened), it would be impossible > to design and to deploy it now. Nothing is impossible. Absolutes are illogical. It is very likely IMHO, that Lessig was being obtuse on purpose here... > > > There are many reasons for the correctness of this statement, but one > definitely would be the still ongoing privacy discussion: > - is it allowed to connect a host directly via a public IP address > to the Internet. > - is it allowed to have a public visible domain. > - is it allowed to query a webpage just to see if it is accessible > - is it allowed to post a webpage everybody can access and is it > allowed to read such a page. Shouldn't there be a contract set up by > lawyers beforehand? Yes. > > - is it allowed to know an e-mail address of somebody and send an e-mail to > - is it allowed to put a webcam in my bedroom > - and so on and on It also allowed for the domain name holder to protect his/her/it's publicly displayed registration data or not as he/she/it desires. > > > Also a public white page phone book is an obscenity in itself > It should not be allowed (BTW: in the old days there was no such thing > in the USSR) Even in the US for as long as I can recall, which is several decades now, a persons phone number could remain "Unlisted" in the white pages. This is still true today. Why is it than that ENUM user numbers assigned or otherwise MUST be so listed? Is it because some group of individuals wishes to track or be able to track annoys ENUM number for whatever desires they should so choose, regardless of whom those persons/groups may or may not represent such as Hamas, Al-queda, Islamic gehad, ect., ect... > > > IETF is a technical body, but in the last week on this list no technical > issues whatsoever have been discussed, only political and philisophical Technical issues in today's world more and more often have philosophical as unfortunately political and direct personal implications. That's reality, like it or not. > > > See > > Richard > > > -----Original Message----- > > From: Mike Hammer [mailto:mhammer at cisco.com] > > Sent: Tuesday, June 22, 2004 1:30 AM > > To: Jeff Williams; Stastny Richard > > Cc: enum at ietf.org > > Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > > > Jeff, > > > > Just out of curiosity, how did the opt-in versus opt-out issue play out > > with other domain names in the DNS? Is it possible to have a domain name > > not in DNS that is useful? > > > > Also, are you asserting that having an entry in User ENUM and privacy are > > mutually exclusive? (That it is impossible by the content of the record > > in > > ENUM to provide privacy?) > > > > An E.164 number could be viewed as a public resource that is assigned to > > you to aid in establishing connections through the collective public > > telephone network. It would not make sense to allow users to take E.164 > > numbers out of circulation and thus cause everyone else's number to have > > to > > increase in length (any more than necessary) as a result. I'm trying to > > understand the model whereby you move the number to the IP domain, but > > then > > don't put it into ENUM to enable calls to be routed to it. Perhaps you > > could clarify what it means to opt-out or not opt-in? > > > > Not for or against anything just yet, just trying to understand exactly > > what data you consider private versus public. > > > > Mike > > > > > > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: > > >Stastny and all, > > > > > >Stastny Richard wrote: > > > > > > > Jeff Williams writes: > > > > >And this to a very great degree is what is wrong with the standards > > > > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > > > > > > > They did. The ENUM protocol as defined in IETF can be implemented > > > > in both ways, athough NOT in the same tree, because the both options > > > > are mutually exclusive. > > > > > > You again misunderstood what I said. That may be my fault however. > > >So I will try to be more precise. The user should be able to have either > > >opt-in or opt-out regardless of which tree. And that in the current > > >protocol is not provided for, and easily could be. > > > > > > > > > > > > > > > Let me explain: Opt-in means that at the beginning nobody is in and > > the > > > > end-user decides if he wants to be in to get this service. This is the > > case > > > > with User ENUM, which is an add-on service. > > > > > > Yes I already knew this, so this exercise is not necessary... > > > > > > > The underlying service > > > > is his phone service and this phone service is working regadless if > > > > he is in ENUM or not (with the exception of ENUM-enable numbers, > > > > which are operating only if you are in User ENUM, but nobody is > > > > forced to use these numbers) > > > > > > Again yes I also already knew this as well. And here is one of the > > >problem areas in the current standards track protocol. If you do not > > >choose as a User ENUM to use these numbers you effectively do > > >not have ENUM capability which is a trap that is by design, and bad > > >design at that, to pressure any user to use these numbers and therefore > > >expose themselves to privacy violations or intrusion of various sorts > > >unnecessarily. > > > > > > > > > > > > > > > The end-user has the additional choice how much information he > > > > discloses: the minimum requirement is the number itself and the > > > > operator, if he puts in e.g. sip:+43xxx at provider.net. > > > > > > Yes and the minimum requirement is another area where the user > > >is exposed to privacy intrusions as he/she need need not have to > > >have the number disclosed or even listed or viewable in DNS > > >records, but still available to law enforcement agencies upon > > >notification of the user in advance. > > > > > > > > > > Additional > > > > information between caller and callee may be exchanges via > > > > negotiation between servers (as in SIP) or Personal User Agents > > > > as proposed in UCI. The end-user may also decide on his discretion > > > > to put in more information as he likes, especially a company. > > > > > >This I also already knew. And the proposed UCI is a bit too loosely > > >worded as to whom decides what the user can direct his/her > > >"personal agent" to disclose and whether any restrictions are > > >at the users discretion. Hence exposing the user to potential > > >further damage should said personal agent decide without prior > > >consent, such disclosures... > > > > > > > > > > > > > > > Opt-out would mean that everybody is in and the end-user decides not > > > > to be in. If a provider decides to implement the basic communication > > > service > > > > based on ENUM, he MUST put all users using this service in ENUM > > > > > > Yes, and this I also already knew and again exposes unnecessarily the > > >user to potential privacy intrusions of obvious and already discussed > > >various sorts. > > > > > > > > > > > > > > > Using ENUM for a service is currently also opt-in, but for the > > provider as > > > > a whole with all of his numbers. There is no opt-out for the > > individual > > > > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > > > > but in separate tree. It is opt-in currently because there is still > > the > > > PSTN around > > > > to reach providers not in Infrastructure ENUM by default. If the PSTN > > > ceases > > > > to exists at some point of time, another default method need to be > > > defined if > > > > E.164 numbering is still around. This may be ENUM or maybe not. > > > > > > Yes again exactly right, and I already knew as well as demonstrates > > that > > >anti-privacy bigots do not wish of users to have opt-out for reasons that > > >are of a political and philosophical nature which may or may not be > > shared > > >by some of many users and also not in concert with EU's for instance, > > >laws. > > > > > > > > > > > > > > > Up to this point of time, different trees may be used by different > > groups > > > > of service providers (confederation), this is already happening. A > > service > > > > provider may even participate in different trees at the same time. > > > > > > > > These trees may either be trees only accessible by participants of > > the > > > > confederation (either in extranets or with access control), but not > > > > on the public Internet, or if accessible by the public, the > > information > > > > is either not accessible, encrypted or useless for the normal end-user. > > > > > > > > There is also a difference between the information contained in > > > > the trees. > > > > > > > > In User ENUM the information points to end-points, > > > > giving one ore more URIs where the end-user has his services. > > > > Different NAPTRs may point to different service providers. > > > > The domain name holder is the end-user. > > > > > > Right, and as the user does not own his/her domain name currently > > >he/she is exposed to others making many privacy and security decisions > > >for him/her depending on the service agreement the provider has or > > >may change from time to time. > > > > > > > > > > > > > > > In Infrastructure ENUM the entry points in principle to > > > > the destination network providing the service for this number. > > > > The domain name holder is the service provider. > > > > > > Right if and when the Domain Name holder is also the service > > >provider which would not be the case in most instances... > > > > > > > > > > > > > > > All this together precludes User ENUM and Infrastructure > > > > ENUM to be in the same tree (even the delegation structure > > > > may be differnent). > > > > > > > > Of course User ENUM and Infrastructure ENUM may co-exist, > > > > any user listed in one or more Infrastructure trees may also > > > > request an entry in User ENUM. The provider may also offer > > > > to the calling customer a service in such a way that first User > > > > ENUM queried and then Infrastructure ENUM. This is already > > > > implemented in some SIP servers and works. (Note: why should > > > > the provider do this? Because the user may do this by himself also. > > > > It is kinda carrier selection ;-) > > > > > > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > > > > explaining all these issues. > > > > > > Yes I have seen early parts of this draft.. > > > > > > > > > > > > > > > BTW: there is one complication emerging at the moment: > > > > Confederations also want Infrastructure ENUM to be used > > > > for routing of transit calls, e.g. an provider is publishing number > > > > ranges in a confederation tree he is serving on the PSTN with his > > > > gateways. This is in principle feasable, but will cause serious > > problems > > > > in the future, especially if two confederations decide to merge there > > > > trees. If one numbers are entered by providers which are assigned > > > > to them, no conflicts could arise if trees are merged. > > > > > > Agreed that there could be some problems in the instances where > > >said confederations are merged for some reason or another such > > >as a business merger or buyout. But again they can be overcome > > >without intruding either previous confederations users discretion > > >regarding any privacy exposures. > > > > > > > > > > > > > > > If numbers are entered by providers not assigned to them, this > > > > will cause policy problems and conflicts. These conflicts cannot > > > > be resolved in ENUM, because it is not designed for it. Other > > > > protocols like TRIP or OSP should be used for this. > > > > > > > > Richard: > > > > To Jeff: You know what my problem with all privacy advocates is? > > > > > > > > They are trespassing my privacy by trying to limit my freedom of > > decision, > > > > including my human right to make idiotic decisions ;-) > > > > > > Hummm? Well I honestly don't see how such a situation is relevant > > >or even possible. Freedom to choose is also a part of protecting > > >anyone's privacy. Idiotic decisions by someone that does so for > > >others, knowingly of that or those persons is a responsibility of > > >great gravity sometimes. For oneself, and only effecting oneself, > > >idiotic decisions are of course expectable however damaging > > >to oneself only, they may be... > > > > > > Ask yourself, do you NEED access to my ENUM number? > > >Does any network operator NEED unrestricted access to my > > >ENUM number? Would access of any sort or at any level > > >to any number other individuals, regardless of supposed status > > >or position not have the increasing potential of the domain name > > >holders ENUM number not expose him/her to potential if not > > >eventual definite abuses of various sorts, some being of a > > >life threatening nature? I believe the answer to this question > > >to definitely be, YES. And THAT is not expectable and > > >preventable if the current ENUM standards track/protocol > > >incorporates at least most of the exposures now known and > > >have been known for some time... > > > > > >Regards, > > > > > >-- > > >Jeffrey A. Williams > > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > >"Be precise in the use of words and expect precision from others" - > > > Pierre Abelard > > > > > >"If the probability be called P; the injury, L; and the burden, B; > > >liability depends upon whether B is less than L multiplied by > > >P: i.e., whether B is less than PL." > > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > >=============================================================== > > >Updated 1/26/04 > > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > >IDNS. div. of Information Network Eng. INEG. INC. > > >E-Mail jwkckid1 at ix.netcom.com > > > Registered Email addr with the USPS > > >Contact Number: 214-244-4827 > > > > > > > > > > > >_______________________________________________ > > >enum mailing list > > >enum at ietf.org > > >https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Thu, 24 Jun 2004 12:41:58 -0400 From: Jeff Williams Date: Thu, 24 Jun 2004 12:41:58 -0400 To: Mike Hammer Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F16244377F@oefeg-s02.oefeg.loc> Message-ID: <40D92F13.125D8CB3@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike and all, Mike Hammer wrote: > Jeff, > > It is well known in security circles that "security through obscurity" is > no security at all. Well I disagree with this statement entirely. If it were not for using obscurity some many years ago now, I would not be alive today. Using good "Obscurity" techniques has always been a good form of security, both man made, and in nature. > Best not to design technical solutions around > mechanisms that have not been well inspected by respected experts. Understood here of course. As one of those respected experts in some circles, I can of course appritiate this comment/remark. > > > The number in and of itself is not private and can not be made so, or the > ability of the public telephone network can not work. Why not? Just because someone says it cannot be made private to a degree. But that I mean, it can be "Unlisted" for "Public" consumption or in whois lookup's ect... > (You can not by > legal fiat force all the world's telephone operators to remove partial or > full telephone numbers from their databases. I am not suggesting that telephone operators do so. I AM asking and even demanding as the spokesman for our members, that those numbers not be publicly listed or avalible for viewing even by any operator. For instance, you cannot view or even get my home phone number right now even if you called information for Frisco Texas, as it is not listed. Try to do so and see if you can. Than post it here, and I will tell you if it is my home phone number or not. Good luck! I also have 3 different cell phone numbers which presently are also not listed, nor I would bet can you obtain 2 of them via any directory. The one which is my main contact phone number is listed in my sig file below, and is sometimes forwarded to my office phone, home phone, and rarely but sometimes forwareded to my China based cell phone number. I would bet you would not be able to find the remaining two cell phone numbers listed, but NOT publicly provided access. Care to place a wager? >:) > It is not possible to doing > routing correctly without them. I point out the parallels between ENUM and > the LNP databases to show the folly and error of such positions. Nonsense. What I believe you are saying is NOT what I am suggesting ( see above comments/remarks and again previous remarks/comments in this regard ). So I think we have a disconnect, if you will pardon the pun. >:) What I am, and have been saying/suggesting in several ways, is that "User ENUM" numbers need not be publicly viewable in Whois or any other lookup facility data by anyone. And yet can still be used for other database functions such as archiving, ect... > > > There are also nefarious purposes for taking E.164 number assignments and > then not making use of them in the PSTN. It is not in the public interest > to allow that to occur, and being in the IP-domain does not make a valid > basis for an exception. > > You are on much safer ground when you argue that the linkage of other > information, which could be deemed privacy-related (names, employer, postal > addresses, geographic location, etc.) within databases is subject to the > privacy laws of various countries. "User ENUM" numbers can be used, as I have said repeatedly to track location of the owner or user of that number. Hence further, postal address can also be extrapolated when starting with a "User ENUM" number, allowing for stalking, and other privacy as well as security related concerns if said "User ENUM" number is not sufficiently "Obscured" ( your term ) from public access. > > > I would argue that for any E.164 number in the form of a domain name that > is found within the DNS, if the resulting records point simply to > information of a service or a service provider address that does not > provide more information specific to an individual subscriber, then no > privacy violation has occurred. I would respectfully disagree with this argument/assertion. Again based on what I have already outlined several times now. ( also see in brief, above ). > Any messages sent to that address, be they > http, email, im, sip, h323, or whatever can then be handled on their own > terms. Routing happens. Routing can still happen uninterrupted even if the "User ENUM" number is "Not publicly listed" but still available for routing purposes. > > > I understand that vagueness provides employment for many lawyers, but this > is a case where ambiguity undermines a key infrastructure and the need for > precision is paramount. Agreed. I have tried to be precise, yet brief and to the relevant points regarding privacy, accuracy, and functionality. I believe I have done so. And done so again here, without being overly technically distinct. > > > Mike > > At 08:09 PM 6/21/2004 -0700, Jeff Williams wrote: > >Mike and all, > > > > I am sure I have stated this before on behalf of our members. However > >I will not post here how such methods can be deployed as to violating > >privacy through various nefarious technical means can be achieved as > >to do so would only serve to potentially provide those that would do so > >to have gotten a number of ideas by which using said methods could be > >added to their own and therefore used for nefarious purposes unnecessarily. > >I am guessing that you Mike know or know of some of the methods to > >which I am indirectly and on purpose referring to. > > > > The number assigned if publicly accessible or even viewable is in and > >of itself a privacy intrusion that should not be allowed. Same is true > >for operators of ENUM activated networks such a Telco's having > >same of similar access to said assigned numbers. In addition if > >a whois lookup would by default display a ENUM number assigned > >to that domain Name or Names in the case of a bulk whois look-up > >than those persons privacy has been compromised unnecessarily and > >could damage them in a number of ways such as stalking, identity > >theft of various sorts. > > > >Mike Hammer wrote: > > > > > Jeff, > > > > > > Just out of curiosity, how did the opt-in versus opt-out issue play out > > > with other domain names in the DNS? Is it possible to have a domain name > > > not in DNS that is useful? > > > > > > Also, are you asserting that having an entry in User ENUM and privacy are > > > mutually exclusive? (That it is impossible by the content of the record in > > > ENUM to provide privacy?) > > > > > > An E.164 number could be viewed as a public resource that is assigned to > > > you to aid in establishing connections through the collective public > > > telephone network. It would not make sense to allow users to take E.164 > > > numbers out of circulation and thus cause everyone else's number to have to > > > increase in length (any more than necessary) as a result. I'm trying to > > > understand the model whereby you move the number to the IP domain, but then > > > don't put it into ENUM to enable calls to be routed to it. Perhaps you > > > could clarify what it means to opt-out or not opt-in? > > > > > > Not for or against anything just yet, just trying to understand exactly > > > what data you consider private versus public. > > > > > > Mike > > > > > > At 09:34 PM 6/19/2004 -0700, Jeff Williams wrote: > > > >Stastny and all, > > > > > > > >Stastny Richard wrote: > > > > > > > > > Jeff Williams writes: > > > > > >And this to a very great degree is what is wrong with the standards > > > > > >track with ENUM. Both opt-in and Opt-out should be incorporated. > > > > > > > > > > They did. The ENUM protocol as defined in IETF can be implemented > > > > > in both ways, athough NOT in the same tree, because the both options > > > > > are mutually exclusive. > > > > > > > > You again misunderstood what I said. That may be my fault however. > > > >So I will try to be more precise. The user should be able to have either > > > >opt-in or opt-out regardless of which tree. And that in the current > > > >protocol is not provided for, and easily could be. > > > > > > > > > > > > > > > > > > > Let me explain: Opt-in means that at the beginning nobody is in and the > > > > > end-user decides if he wants to be in to get this service. This is > > the case > > > > > with User ENUM, which is an add-on service. > > > > > > > > Yes I already knew this, so this exercise is not necessary... > > > > > > > > > The underlying service > > > > > is his phone service and this phone service is working regadless if > > > > > he is in ENUM or not (with the exception of ENUM-enable numbers, > > > > > which are operating only if you are in User ENUM, but nobody is > > > > > forced to use these numbers) > > > > > > > > Again yes I also already knew this as well. And here is one of the > > > >problem areas in the current standards track protocol. If you do not > > > >choose as a User ENUM to use these numbers you effectively do > > > >not have ENUM capability which is a trap that is by design, and bad > > > >design at that, to pressure any user to use these numbers and therefore > > > >expose themselves to privacy violations or intrusion of various sorts > > > >unnecessarily. > > > > > > > > > > > > > > > > > > > The end-user has the additional choice how much information he > > > > > discloses: the minimum requirement is the number itself and the > > > > > operator, if he puts in e.g. sip:+43xxx at provider.net. > > > > > > > > Yes and the minimum requirement is another area where the user > > > >is exposed to privacy intrusions as he/she need need not have to > > > >have the number disclosed or even listed or viewable in DNS > > > >records, but still available to law enforcement agencies upon > > > >notification of the user in advance. > > > > > > > > > > > > > Additional > > > > > information between caller and callee may be exchanges via > > > > > negotiation between servers (as in SIP) or Personal User Agents > > > > > as proposed in UCI. The end-user may also decide on his discretion > > > > > to put in more information as he likes, especially a company. > > > > > > > >This I also already knew. And the proposed UCI is a bit too loosely > > > >worded as to whom decides what the user can direct his/her > > > >"personal agent" to disclose and whether any restrictions are > > > >at the users discretion. Hence exposing the user to potential > > > >further damage should said personal agent decide without prior > > > >consent, such disclosures... > > > > > > > > > > > > > > > > > > > Opt-out would mean that everybody is in and the end-user decides not > > > > > to be in. If a provider decides to implement the basic communication > > > > service > > > > > based on ENUM, he MUST put all users using this service in ENUM > > > > > > > > Yes, and this I also already knew and again exposes unnecessarily the > > > >user to potential privacy intrusions of obvious and already discussed > > > >various sorts. > > > > > > > > > > > > > > > > > > > Using ENUM for a service is currently also opt-in, but for the > > provider as > > > > > a whole with all of his numbers. There is no opt-out for the individual > > > > > end-user. This is called Infrastructure ENUM. It uses ENUM technology, > > > > > but in separate tree. It is opt-in currently because there is still the > > > > PSTN around > > > > > to reach providers not in Infrastructure ENUM by default. If the PSTN > > > > ceases > > > > > to exists at some point of time, another default method need to be > > > > defined if > > > > > E.164 numbering is still around. This may be ENUM or maybe not. > > > > > > > > Yes again exactly right, and I already knew as well as demonstrates > > that > > > >anti-privacy bigots do not wish of users to have opt-out for reasons that > > > >are of a political and philosophical nature which may or may not be shared > > > >by some of many users and also not in concert with EU's for instance, > > > >laws. > > > > > > > > > > > > > > > > > > > Up to this point of time, different trees may be used by different > > groups > > > > > of service providers (confederation), this is already happening. A > > service > > > > > provider may even participate in different trees at the same time. > > > > > > > > > > These trees may either be trees only accessible by participants of the > > > > > confederation (either in extranets or with access control), but not > > > > > on the public Internet, or if accessible by the public, the information > > > > > is either not accessible, encrypted or useless for the normal end-user. > > > > > > > > > > There is also a difference between the information contained in > > > > > the trees. > > > > > > > > > > In User ENUM the information points to end-points, > > > > > giving one ore more URIs where the end-user has his services. > > > > > Different NAPTRs may point to different service providers. > > > > > The domain name holder is the end-user. > > > > > > > > Right, and as the user does not own his/her domain name currently > > > >he/she is exposed to others making many privacy and security decisions > > > >for him/her depending on the service agreement the provider has or > > > >may change from time to time. > > > > > > > > > > > > > > > > > > > In Infrastructure ENUM the entry points in principle to > > > > > the destination network providing the service for this number. > > > > > The domain name holder is the service provider. > > > > > > > > Right if and when the Domain Name holder is also the service > > > >provider which would not be the case in most instances... > > > > > > > > > > > > > > > > > > > All this together precludes User ENUM and Infrastructure > > > > > ENUM to be in the same tree (even the delegation structure > > > > > may be differnent). > > > > > > > > > > Of course User ENUM and Infrastructure ENUM may co-exist, > > > > > any user listed in one or more Infrastructure trees may also > > > > > request an entry in User ENUM. The provider may also offer > > > > > to the calling customer a service in such a way that first User > > > > > ENUM queried and then Infrastructure ENUM. This is already > > > > > implemented in some SIP servers and works. (Note: why should > > > > > the provider do this? Because the user may do this by himself also. > > > > > It is kinda carrier selection ;-) > > > > > > > > > > ETSI is currently drafting a TS 102 055 on Infrastructure ENUM > > > > > explaining all these issues. > > > > > > > > Yes I have seen early parts of this draft.. > > > > > > > > > > > > > > > > > > > BTW: there is one complication emerging at the moment: > > > > > Confederations also want Infrastructure ENUM to be used > > > > > for routing of transit calls, e.g. an provider is publishing number > > > > > ranges in a confederation tree he is serving on the PSTN with his > > > > > gateways. This is in principle feasable, but will cause serious > > problems > > > > > in the future, especially if two confederations decide to merge there > > > > > trees. If one numbers are entered by providers which are assigned > > > > > to them, no conflicts could arise if trees are merged. > > > > > > > > Agreed that there could be some problems in the instances where > > > >said confederations are merged for some reason or another such > > > >as a business merger or buyout. But again they can be overcome > > > >without intruding either previous confederations users discretion > > > >regarding any privacy exposures. > > > > > > > > > > > > > > > > > > > If numbers are entered by providers not assigned to them, this > > > > > will cause policy problems and conflicts. These conflicts cannot > > > > > be resolved in ENUM, because it is not designed for it. Other > > > > > protocols like TRIP or OSP should be used for this. > > > > > > > > > > Richard: > > > > > To Jeff: You know what my problem with all privacy advocates is? > > > > > > > > > > They are trespassing my privacy by trying to limit my freedom of > > decision, > > > > > including my human right to make idiotic decisions ;-) > > > > > > > > Hummm? Well I honestly don't see how such a situation is relevant > > > >or even possible. Freedom to choose is also a part of protecting > > > >anyone's privacy. Idiotic decisions by someone that does so for > > > >others, knowingly of that or those persons is a responsibility of > > > >great gravity sometimes. For oneself, and only effecting oneself, > > > >idiotic decisions are of course expectable however damaging > > > >to oneself only, they may be... > > > > > > > > Ask yourself, do you NEED access to my ENUM number? > > > >Does any network operator NEED unrestricted access to my > > > >ENUM number? Would access of any sort or at any level > > > >to any number other individuals, regardless of supposed status > > > >or position not have the increasing potential of the domain name > > > >holders ENUM number not expose him/her to potential if not > > > >eventual definite abuses of various sorts, some being of a > > > >life threatening nature? I believe the answer to this question > > > >to definitely be, YES. And THAT is not expectable and > > > >preventable if the current ENUM standards track/protocol > > > >incorporates at least most of the exposures now known and > > > >have been known for some time... > > > > > > > >Regards, > > > > > > > >-- > > > >Jeffrey A. Williams > > > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > > >"Be precise in the use of words and expect precision from others" - > > > > Pierre Abelard > > > > > > > >"If the probability be called P; the injury, L; and the burden, B; > > > >liability depends upon whether B is less than L multiplied by > > > >P: i.e., whether B is less than PL." > > > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > > >=============================================================== > > > >Updated 1/26/04 > > > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > > >IDNS. div. of Information Network Eng. INEG. INC. > > > >E-Mail jwkckid1 at ix.netcom.com > > > > Registered Email addr with the USPS > > > >Contact Number: 214-244-4827 > > > > > > > > > > > > > > > >_______________________________________________ > > > >enum mailing list > > > >enum at ietf.org > > > >https://www1.ietf.org/mailman/listinfo/enum > > > >Regards, > > > >-- > >Jeffrey A. Williams > >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > >"Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > >"If the probability be called P; the injury, L; and the burden, B; > >liability depends upon whether B is less than L multiplied by > >P: i.e., whether B is less than PL." > >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > >=============================================================== > >Updated 1/26/04 > >CSO/DIR. Internet Network Eng. SR. Eng. Network data security > >IDNS. div. of Information Network Eng. INEG. INC. > >E-Mail jwkckid1 at ix.netcom.com > > Registered Email addr with the USPS > >Contact Number: 214-244-4827 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 24 Jun 2004 12:42:34 -0400 From: "Stastny Richard" Date: Thu, 24 Jun 2004 12:42:34 -0400 To: Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437A2@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R > Jeff wrote: > Routing can still happen uninterrupted even if the "User ENUM" number > is "Not publicly listed" but still available for routing purposes. > [Richard>] This is nonsense. "User ENUM" is always public. If a number is not listed in "user ENUM" it not available and cannot by used for "routing" purposes. Period It may be listed in Infrastructure ENUM which is NOT publicly available, and will be used for routing purposes by definition. Since it is not publicly available, there is no privacy issue. At least no one to deal with here. This was my last statement in this thread on this issue. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 24 Jun 2004 12:42:47 -0400 From: "Stastny Richard" Date: Thu, 24 Jun 2004 12:42:47 -0400 To: "Richard Shockey" Subject: RE: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: <06CF906FE3998C4E944213062009F1624437A3@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R I still do not know what should be on the agenda of the Carrier ENUM mini-BoF. Sofar two issues have been raised: 1. Privacy, but this is a non-issue for Carrier ENUM (it may be discussed in the User ENUM part) 2. Usage of Carrier ENUM for transit routing I said related to this issue "ENUM as it is now is not providing these functions, one should use TRIP or OSP for this. The mini-BoF may discuss this issue and may come to a conclusion. (reject the issue or extend ENUM)" I have seen NO comment on this on the list. BTW, I have seen besides the privacy issue NO comment related to Carrier ENUM on this list sofar so there seem to be either no interest or nobody already implementing Carrier ENUM is coming forward. Either way, we may skip the topic. Richard > Richard Stastny ĂFEG Ăsterreichische Fernmeldetechnische Entwicklungs- und FĂrderungsgesellschaft mbH BĂroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: Web: Die in dieser Mitteilung und AnhĂngen enthaltenen Informationen sind ausschlieĂlich fĂr den Adressaten bestimmt und kĂnnen geheime, vertrauliche oder vor Weitergabe geschĂtzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten EmpfĂnger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder VervielfĂltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtĂmlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu lĂschen, ohne Kopien einzubehalten. Danke. -----Original Message----- From: Stastny Richard Sent: Sunday, June 20, 2004 10:29 PM To: Richard Shockey Cc: enum at ietf.org Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda So given Steven questions, my "User ENUM" definitions and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM",  I want to try to give an answer toÂquestion 1b first, before I address 1a  a: within User ENUM there exist privacy issues.  set-up properly these issues do not exist in "Carrier ENUM",  because either the information is not accessible or not usable  by end-users.  Note: all privacy issues with ENUM should thereore be discussed  in the first half of the meeting, not in the mini-BoF on "Carrier ENUM"  b. "User ENUM" is end-to-end and therefore opt-in Â-ÂÂService providers wanting to deploy a routing of calls  between their networks avoiding the PSTN as interconnect  need a tool on the Internet to achieve this goal. (This  tool is also necessary if no PSTN exists anymore ;-) ÂÂ-ÂThey may choose to use the technology as defined  in RFC3761 at al.  -ÂTo achieve this they have to includeÂALL E.164 numbers assigend  to them andÂthey in turn assigned to the end-users they  are providing service for (anybody an idea of a better wording?)  so opt-in is not possible. - confederations of service providers may choose any domain in  the DNS as root for their tree, they may even chooseÂa "private DNS"   - IfÂa service provider Âpopulates the tree only with E.164 numbers  assigned to him, a later merging of trees is trivial, because no overlaps  exist.  - currently also nor additional requirements on the ENUM protocol  are known. If there are, please come forward now.  Warning: the above definition is only valid if "carrier ENUM" is only used for routing to destination service providers hosting the numbers they hold in the tree.  So 1a: What are the issues/problems that need to be addressed? Recently some requirements have been discussed to use ENUM and especially "carrier ENUM" for additional purposes,e.g. routing to transit providers if they also provide gateways to the PSTN.  Although this is in principle possible with ENUM, this is not recommended because it may cause conflicts in domain ownerships and make it impossible to merge trees later.  Since in most cases routing to the PSTN is involved, this immediately raises the question of settlement and alternative routes. ENUM as it is now is not providing these functions, one should use TRIP or OSP for this.  The mini-BoF may discuss this issue and may come to a conclusion. (reject the issue or extend ENUM) Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Thu, 24 Jun 2004 12:44:27 -0400 From: James Seng Date: Thu, 24 Jun 2004 12:44:27 -0400 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F1624437A3@oefeg-s02.oefeg.loc> Message-ID: <40D98921.5090203@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R Here is what I think: First, I think we need to do some problem statement trashing. What is Carrier ENUM and what's the problem we trying to solve? Then we can have someone present a solution (or more) as a strawman to start the discussion. Anyone wants to give a first shot at these two? -James Seng Stastny Richard wrote: I still do not know what should be on the agenda of the Carrier ENUM mini-BoF. Sofar two issues have been raised: 1. Privacy, but this is a non-issue for Carrier ENUM (it may be discussed in the User ENUM part) 2. Usage of Carrier ENUM for transit routing I said related to this issue "ENUM as it is now is not providing these functions, one should use TRIP or OSP for this. The mini-BoF may discuss this issue and may come to a conclusion. (reject the issue or extend ENUM)" I have seen NO comment on this on the list. BTW, I have seen besides the privacy issue NO comment related to Carrier ENUM on this list sofar so there seem to be either no interest or nobody already implementing Carrier ENUM is coming forward. Either way, we may skip the topic. Richard Richard Stastny ĂFEG Ăsterreichische Fernmeldetechnische Entwicklungs- und FĂrderungsgesellschaft mbH BĂroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: Web: Die in dieser Mitteilung und AnhĂngen enthaltenen Informationen sind ausschlieĂlich fĂr den Adressaten bestimmt und kĂnnen geheime, vertrauliche oder vor Weitergabe geschĂtzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten EmpfĂnger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder VervielfĂltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtĂmlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu lĂschen, ohne Kopien einzubehalten. Danke. -----Original Message----- From: Stastny Richard Sent: Sunday, June 20, 2004 10:29 PM To: Richard Shockey Cc: enum at ietf.org Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda So given Steven questions, my "User ENUM" definitions and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM", I want to try to give an answer to question 1b first, before I address 1a a: within User ENUM there exist privacy issues. set-up properly these issues do not exist in "Carrier ENUM", because either the information is not accessible or not usable by end-users. Note: all privacy issues with ENUM should thereore be discussed in the first half of the meeting, not in the mini-BoF on "Carrier ENUM" b. "User ENUM" is end-to-end and therefore opt-in - Service providers wanting to deploy a routing of calls between their networks avoiding the PSTN as interconnect need a tool on the Internet to achieve this goal. (This tool is also necessary if no PSTN exists anymore ;-) - They may choose to use the technology as defined in RFC3761 at al. - To achieve this they have to include ALL E.164 numbers assigend to them and they in turn assigned to the end-users they are providing service for (anybody an idea of a better wording?) so opt-in is not possible. - confederations of service providers may choose any domain in the DNS as root for their tree, they may even choose a "private DNS" - If a service provider populates the tree only with E.164 numbers assigned to him, a later merging of trees is trivial, because no overlaps exist. - currently also nor additional requirements on the ENUM protocol are known. If there are, please come forward now. Warning: the above definition is only valid if "carrier ENUM" is only used for routing to destination service providers hosting the numbers they hold in the tree. So 1a: What are the issues/problems that need to be addressed? Recently some requirements have been discussed to use ENUM and especially "carrier ENUM" for additional purposes,e.g. routing to transit providers if they also provide gateways to the PSTN. Although this is in principle possible with ENUM, this is not recommended because it may cause conflicts in domain ownerships and make it impossible to merge trees later. Since in most cases routing to the PSTN is involved, this immediately raises the question of settlement and alternative routes. ENUM as it is now is not providing these functions, one should use TRIP or OSP for this. The mini-BoF may discuss this issue and may come to a conclusion. (reject the issue or extend ENUM) Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 24 Jun 2004 12:44:51 -0400 From: "Stastny Richard" Date: Thu, 24 Jun 2004 12:44:51 -0400 To: "James Seng" Subject: RE: [Enum] Carrier ENUM mini-BoF Agenda Message-ID: <06CF906FE3998C4E944213062009F1624437A5@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R James, I already offered to provide half of the first point: I could present what carrier ENUM is (at least the ETSI point of view) and why it needs to be different from User ENUM The problem we are trying to solve is IMHO opinion an answer to the question if ENUM WG needs to do anything, or in other words: a. are there any additional requirements to RFC 3781 as it is now b. are there additional enumservices need especially for carrier ENUM. Note: if I talk about existing ENUM services it mean the ENUMservices defined in ETSI TS 102 172 v2 But these are needed also for User ENUM and should finally be registered by IANA (or not). My answer to these questions sofar is: no, there is nothing additional needed if carrier ENUM is only used to identify termination end points If carrier ENUM is also user for transit, then Something is needed, but I do not know what. Richard > -----Original Message----- > From: James Seng [mailto:jseng at pobox.org.sg] > Sent: Wednesday, June 23, 2004 3:44 PM > To: Stastny Richard > Cc: Richard Shockey; enum at ietf.org > Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda > > Here is what I think: > > First, I think we need to do some problem statement trashing. What is > Carrier ENUM and what's the problem we trying to solve? > > Then we can have someone present a solution (or more) as a strawman to > start the discussion. > > Anyone wants to give a first shot at these two? > > -James Seng > > Stastny Richard wrote: > > > I still do not know what should be on the agenda > > of the Carrier ENUM mini-BoF. > > > > Sofar two issues have been raised: > > > > 1. Privacy, but this is a non-issue for Carrier ENUM > > (it may be discussed in the User ENUM part) > > > > 2. Usage of Carrier ENUM for transit routing > > > > I said related to this issue > > "ENUM as it is now is not providing these functions, one > > should use TRIP or OSP for this. > > > > The mini-BoF may discuss this issue and may come > > to a conclusion. (reject the issue or extend ENUM)" > > > > I have seen NO comment on this on the list. > > > > BTW, I have seen besides the privacy issue > > NO comment related to Carrier ENUM on this list sofar > > so there seem to be either no interest or nobody > > already implementing Carrier ENUM is coming forward. > > > > Either way, we may skip the topic. > > > > > > Richard > > > > > > > >>Richard Stastny > > > > ĂFEG > > Ăsterreichische Fernmeldetechnische Entwicklungs- und > FĂrderungsgesellschaft mbH > > BĂroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien > > Postadresse: Postfach 147, A-1103 Wien > > Telefon: +43 664 420 4100 > > Telefax: +43 1 79780 13 > > E-Mail: > > Web: > > > > Die in dieser Mitteilung und AnhĂngen enthaltenen Informationen sind > ausschlieĂlich fĂr den Adressaten bestimmt und kĂnnen geheime, > vertrauliche oder vor Weitergabe geschĂtzte Informationen enthalten. Falls > es sich beim Leser dieses Absatzes nicht um den beabsichtigten EmpfĂnger > oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass > jegliche Weitergabe, Verteilung oder VervielfĂltigung dieser Mitteilung > verboten ist. Sollte dieses Schreiben irrtĂmlich zugestellt worden sein, > wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu > lĂschen, ohne Kopien einzubehalten. Danke. > > > > > > -----Original Message----- > > From: Stastny Richard > > Sent: Sunday, June 20, 2004 10:29 PM > > To: Richard Shockey > > Cc: enum at ietf.org > > Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda > > > > So given Steven questions, my "User ENUM" definitions > > and Richards "Carrier TN to URI translation mechanisms" aka "Carrier > ENUM", > > > > I want to try to give an answer to question 1b first, before I address > 1a > > > > a: within User ENUM there exist privacy issues. > > set-up properly these issues do not exist in "Carrier ENUM", > > because either the information is not accessible or not usable > > by end-users. > > Note: all privacy issues with ENUM should thereore be discussed > > in the first half of the meeting, not in the mini-BoF on "Carrier > ENUM" > > > > b. "User ENUM" is end-to-end and therefore opt-in > > - Service providers wanting to deploy a routing of calls > > between their networks avoiding the PSTN as interconnect > > need a tool on the Internet to achieve this goal. (This > > tool is also necessary if no PSTN exists anymore ;-) > > > > - They may choose to use the technology as defined > > in RFC3761 at al. > > > > - To achieve this they have to include ALL E.164 numbers assigend > > to them and they in turn assigned to the end-users they > > are providing service for (anybody an idea of a better wording?) > > so opt-in is not possible. > > > > - confederations of service providers may choose any domain in > > the DNS as root for their tree, they may even choose a "private DNS" > > > > - If a service provider populates the tree only with E.164 numbers > > assigned to him, a later merging of trees is trivial, because no > overlaps > > exist. > > - currently also nor additional requirements on the ENUM protocol > > are known. If there are, please come forward now. > > > > Warning: the above definition is only valid if "carrier ENUM" is > > only used for routing to destination service providers hosting the > > numbers they hold in the tree. > > > > So > > 1a: What are the issues/problems that need to be addressed? > > Recently some requirements have been discussed to use > > ENUM and especially "carrier ENUM" for additional > > purposes,e.g. routing to transit providers if they also > > provide gateways to the PSTN. > > > > Although this is in principle possible with ENUM, this > > is not recommended because it may cause conflicts in > > domain ownerships and make it impossible to merge > > trees later. > > > > Since in most cases routing to the PSTN is involved, > > this immediately raises the question of settlement and > > alternative routes. > > > > ENUM as it is now is not providing these functions, one > > should use TRIP or OSP for this. > > > > The mini-BoF may discuss this issue and may come > > to a conclusion. (reject the issue or extend ENUM) > > > > Richard > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Thu, 24 Jun 2004 12:45:00 -0400 From: James Seng Date: Thu, 24 Jun 2004 12:45:00 -0400 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F1624437A5@oefeg-s02.oefeg.loc> Message-ID: <40D99B21.3050208@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R I already offered to provide half of the first point: I could present what carrier ENUM is (at least the ETSI point of view) and why it needs to be different from User ENUM :-) Might be useful to shoot it again as the first item on the agenda. The problem we are trying to solve is IMHO opinion an answer to the question if ENUM WG needs to do anything, or in other words: a. are there any additional requirements to RFC 3781 as it is now b. are there additional enumservices need especially for carrier ENUM. My answer to these questions sofar is: no, there is nothing additional needed if carrier ENUM is only used to identify termination end points I haven't reach a conclusion yet... But I see the consideration of interoperability between multiple trees (forests you called it, i remember :-) as something Carrier ENUM needs to handle. And we see some discussion (offline) on silvertree and goldentree and how to sync between them and I thought it would be useful to bring that discussion to the group. The conclusion may that we dont need to do anything to RFC 3781 or we might. Or that we might consider this as an operation issue and move this to the OPS Area. Or maybe we can just do this in this WG or maybe we dont need any WG at all. Either way, having people to lead the discussion and see where this leads. :-) -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Thu, 24 Jun 2004 12:49:14 -0400 From: Internet-Drafts@ietf.org Date: Thu, 24 Jun 2004 12:49:14 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt Message-ID: <200406232052.QAA16762@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-02.txt Pages : 19 Date : 2004-6-23 This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and 'sips:' as per the IANA registration process defined in the ENUM specification RFC3761 [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-msg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-msg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Thu, 24 Jun 2004 12:51:33 -0400 From: "Fullbrook Kim (UK)" Date: Thu, 24 Jun 2004 12:51:33 -0400 To: "'enum at ietf.org> Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Status: R It's not clear to me exactly what you're suggesting here. - If the DNS you're referring to is private then no concerns. - If the DNS is publicly accessible then are you saying that in the DNS the E.164 number only has a domain name corresponding to it without a username   e.g. 12345678909 -> sip:bigtelco.com   ?  This would be an incomplete URI and would need some other mechanism to provide call routing to a specific user, perhaps a full ENUM DNS which is only accessible by Operators.  This "two tier" system would get rid of most of the privacy concerns but with the downside of some duplication of material.  Could be a solution worthy of further study. - If the DNS is publicly accessible with the URI in usual format e.g. 12345678909 -> sip:jdoe at bigtelco.com  then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out". Kim. -----Original Message----- From: Mike Hammer [mailto:mhammer at cisco.com] Sent: 22 June 2004 20:38 To: Jeff Williams Cc: enum at ietf.org; Stastny Richard Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) I would argue that for any E.164 number in the form of a domain name that is found within the DNS, if the resulting records point simply to information of a service or a service provider address that does not provide more information specific to an individual subscriber, then no privacy violation has occurred.  Any messages sent to that address, be they http, email, im, sip, h323, or whatever can then be handled on their own terms.  Routing happens. ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 Richard.Stastny@oefeg.at Thu, 24 Jun 2004 18:25:31 -0400 From: "Stastny Richard" Date: Thu, 24 Jun 2004 18:25:31 -0400 To: Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437A7@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R No, what Mike meant here is mcu simpler: assume you have number +437801234567 so you have an ENUM domain 7.6.5.4.3.2.1.0.8.7.3.4.e164.arpa in this domain you put a NAPTR with e.g. enumservice E2U+sip and a URI sip:437801234567 at bigtelco.com within your SIP server the user jdoe gets an alias 437801234567 (or the other way round) so only infromation somebody gets querying ENUM for the number +437801234567 is in addition is the provider. But user jdoe may still be reached via sip:jdoe at bigtelco.com for somebody knowing this. Richard -----UrsprĂngliche Nachricht----- Von: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] Gesendet: Do 24.06.2004 10:45 An: 'enum at ietf.org' Cc: Betreff: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) It's not clear to me exactly what you're suggesting here. - If the DNS you're referring to is private then no concerns. - If the DNS is publicly accessible then are you saying that in the DNS the E.164 number only has a domain name corresponding to it without a username e.g. 12345678909 -> sip:bigtelco.com ? This would be an incomplete URI and would need some other mechanism to provide call routing to a specific user, perhaps a full ENUM DNS which is only accessible by Operators. This "two tier" system would get rid of most of the privacy concerns but with the downside of some duplication of material. Could be a solution worthy of further study. - If the DNS is publicly accessible with the URI in usual format e.g. 12345678909 -> sip:jdoe at bigtelco.com then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out". Kim. -----Original Message----- From: Mike Hammer [mailto:mhammer at cisco.com] Sent: 22 June 2004 20:38 To: Jeff Williams Cc: enum at ietf.org; Stastny Richard Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) I would argue that for any E.164 number in the form of a domain name that is found within the DNS, if the resulting records point simply to information of a service or a service provider address that does not provide more information specific to an individual subscriber, then no privacy violation has occurred. Any messages sent to that address, be they http, email, im, sip, h323, or whatever can then be handled on their own terms. Routing happens. _____ ======================================================== This electronic message contains information from the mmO2 plc Group 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 jaap@sidn.nl Thu, 24 Jun 2004 19:39:24 -0400 From: Jaap Akkerhuis Date: Thu, 24 Jun 2004 19:39:24 -0400 To: "Stastny Richard" Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F1624437A3@oefeg-s02.oefeg.loc> Message-ID: <200406242237.i5OMbKEv025007@bartok.sidn.nl> MIME-Version: 1.0 Content-Type: text/plain Status: R Can you please send your email in non encoded form? There is no reason to encode plain ascii (since that is what you seem to be sending). jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Thu, 24 Jun 2004 19:40:05 -0400 From: James Seng Date: Thu, 24 Jun 2004 19:40:05 -0400 To: "Fullbrook Kim (UK)" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40DB5054.1060105@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R And how is it different from someone wardial a set of numbers and obtained a list of valid phone number today? ps: list of numbers != phone book. A yellowpage associate a number with a person. -James Seng Fullbrook Kim (UK) wrote: - If the DNS is publicly accessible with the URI in usual format e.g. 12345678909 -> sip:jdoe at bigtelco.com then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out". Kim. -----Original Message----- From: Mike Hammer [mailto:mhammer at cisco.com] Sent: 22 June 2004 20:38 To: Jeff Williams Cc: enum at ietf.org; Stastny Richard Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) I would argue that for any E.164 number in the form of a domain name that is found within the DNS, if the resulting records point simply to information of a service or a service provider address that does not provide more information specific to an individual subscriber, then no privacy violation has occurred. Any messages sent to that address, be they http, email, im, sip, h323, or whatever can then be handled on their own terms. Routing happens. ------------------------------------------------------------------------ ======================================================== This electronic message contains information from the mmO2 plc Group 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 jwkckid1@ix.netcom.com Thu, 24 Jun 2004 22:16:47 -0400 From: Jeff Williams Date: Thu, 24 Jun 2004 22:16:47 -0400 To: "Fullbrook Kim (UK)" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40DBA1CA.DE9FC5BA@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Again good point, and exactly right in your conclusion. The two tier approach is IMHO being used to be unclear purposefully as a method to soothe concerns of privacy while at the same time effecting a policy that would be so confusing to the unsuspecting public at getting access to private information as well as perhaps selling said information to potential marketing firms in order to bolster the providers bottom line. Fullbrook Kim (UK) wrote: > It's not clear to me exactly what you're suggesting here. > > - If the DNS you're referring to is private then no concerns. > - If the DNS is publicly accessible then are you saying that in the > DNS the > E.164 number only has a domain name corresponding to it without a > username > e.g. 12345678909 -> sip:bigtelco.com ? This would be an incomplete > URI > and would need some other mechanism to provide call routing to a > specific > user, perhaps a full ENUM DNS which is only accessible by Operators. > This > "two tier" system would get rid of most of the privacy concerns but > with the > downside of some duplication of material. Could be a solution worthy > of > further study. > - If the DNS is publicly accessible with the URI in usual format e.g. > 12345678909 -> sip:jdoe at bigtelco.com then we are back to the same > situation > already described: anyone can "war dial" the DNS and build up a list > of SIP > URIs of subscribers which is effectively a publicly accessible phone > book > without "opt out". > > Kim. > > -----Original Message----- > From: Mike Hammer [mailto:mhammer at cisco.com] > Sent: 22 June 2004 20:38 > To: Jeff Williams > Cc: enum at ietf.org; Stastny Richard > Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator > ENUM) > > > > I would argue that for any E.164 number in the form of a domain name > that > is found within the DNS, if the resulting records point simply to > information of a service or a service provider address that does not > provide more information specific to an individual subscriber, then no > > privacy violation has occurred. Any messages sent to that address, be > they > http, email, im, sip, h323, or whatever can then be handled on their > own > terms. Routing happens. > > > > - > --------------------------------------------------------------------- > > > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 25 Jun 2004 02:15:22 -0400 From: Jeff Williams Date: Fri, 25 Jun 2004 02:15:22 -0400 To: enum at ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt In-Reply-To: <200406232052.QAA16762@ietf.org> Message-ID: <40DBD94B.A412E329@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R All, Well as we have been discussing it seems that the concerns regarding privacy were not adequately addressed in this draft as the so called rough consensus doctrine of the IETF seems to desire to adhere to. Draft referenced below: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt Sections with weak security and privacy provisions are as follows: Security Considerations: An e-mail address is a canonical address by which a user is known. Placing this address in ENUPM is comparable to placing a SIP or H.323 address in the DNS. DNS does not make any policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM NAPTR resource record must therefore be considered to be open to the public, which is a cause for some privacy considerations. Therefore ENUM Subscribers should be made aware of this risk. Since it is within the responsibility of the ENUM Subscriber which data is entered in ENUM, it is within the ENUM Subscribers control if he enters e-mail addresses: 1. allowing inference of private data e.g. his first and last name 2. at all It should also be considered that it is the purpose of public communication identifiers to be publicly known. To reduce spam and other unwanted communication other means should be made available. And..... 6. Security Considerations DNS, as used by ENUM, is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a Telephone Directory, it does open the data subject to having "their" information collected automatically without any indication that this has been done or by whom. Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they are sent increases when they post to the mailing list; publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS" for example. Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus providing a "sacrificial" phone number in any publication is not possible. Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give their explicit informed consent to data being published in ENUM. In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent. However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that their consent for its publication is explicitly confirmed at regular intervals. When placing a fax call via the PSTN or a sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that the end user be asked to confirm sending the message, and that the destination number be presented to them. It is the originating Brandner, et al. Expires December 20, 2004 [Page 14] Internet-Draft IANA Registration for Message ENUMservices June 2004 user's choice on whether or not to send a message to this destination number, but they SHOULD be shown the destination number so that they can make this decision. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [19] to these, is provided in RFC3761 [6]. =========== End of referenced sections =============== So shall we again discuss and consider alternative or more appropriate language and or provisions to this draft that closer matches the "Rough Consensus" of interested parties and/or stakeholders/users? Internet-Drafts at ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping Working Group of the IETF. > > Title : IANA Registration for ENUMservices email, fax, mms, ems and sms > Author(s) : R. Brandner, et al. > Filename : draft-ietf-enum-msg-02.txt > Pages : 19 > Date : 2004-6-23 > > This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms', > 'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and > 'sips:' as per the IANA registration process defined in the ENUM > specification RFC3761 [6]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-enum-msg-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-msg-02.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. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 25 Jun 2004 02:18:28 -0400 From: Jeff Williams Date: Fri, 25 Jun 2004 02:18:28 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437A2@oefeg-s02.oefeg.loc> Message-ID: <40DBDBFC.53C50005@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, Stastny Richard wrote: > > Jeff wrote: > > Routing can still happen uninterrupted even if the "User ENUM" number > > is "Not publicly listed" but still available for routing purposes. > > > [Richard>] This is nonsense. > "User ENUM" is always public. If a number is not listed in "user ENUM" > it not available and cannot by used for "routing" purposes. Period I wasn't referring for "routing" purposes. I was referring to public viewable access via DNS lookups ect... Sorry if I wasn't as clear as I may have needed to be... > > > It may be listed in Infrastructure ENUM which is NOT publicly available, > and will be used for routing purposes by definition. Since it > is not publicly available, there is no privacy issue. At least no > one to deal with here. Ok, for the purposes of routing, yes there is no privacy issue of significant concern. Your point is taken here.. However routing tables could be used or accessed and than used for nefarious purposes lest viewable address they are protected in some form. I can think of several ways which such protection could be achieved. It may be this is a starting point for that discussion? > > This was my last statement in this thread on this issue. > > Richard > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 25 Jun 2004 02:33:00 -0400 From: Jeff Williams Date: Fri, 25 Jun 2004 02:33:00 -0400 To: Stastny Richard Subject: Re: [Enum] Carrier ENUM mini-BoF Agenda In-Reply-To: <06CF906FE3998C4E944213062009F1624437A3@oefeg-s02.oefeg.loc> Message-ID: <40DBDD29.227EDBC1@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, Why would the subject of privacy and security in user ENUM be skipped? As I stated earlier on another thread, even in carrier ENUM for routes, some small amount of exposure to privacy intrusion exists.. Hence it would seem appropriate that this also needs some addressing unless the anti-privacy bigots wish to dismiss such out of hand? Stastny Richard wrote: > I still do not know what should be on the agenda > of the Carrier ENUM mini-BoF. > > Sofar two issues have been raised: > > 1. Privacy, but this is a non-issue for Carrier ENUM > (it may be discussed in the User ENUM part) > > 2. Usage of Carrier ENUM for transit routing > > I said related to this issue > "ENUM as it is now is not providing these functions, one > should use TRIP or OSP for this. > > The mini-BoF may discuss this issue and may come > to a conclusion. (reject the issue or extend ENUM)" > > I have seen NO comment on this on the list. > > BTW, I have seen besides the privacy issue > NO comment related to Carrier ENUM on this list sofar > so there seem to be either no interest or nobody > already implementing Carrier ENUM is coming forward. > > Either way, we may skip the topic. > > Richard > > > Richard Stastny > Ă?FEG > Ă?sterreichische Fernmeldetechnische Entwicklungs- und Förderungsgesellschaft mbH > BĂĽroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien > Postadresse: Postfach 147, A-1103 Wien > Telefon: +43 664 420 4100 > Telefax: +43 1 79780 13 > E-Mail: > Web: > > Die in dieser Mitteilung und Anhängen enthaltenen Informationen sind ausschlieĂ?lich fĂĽr den Adressaten bestimmt und können geheime, vertrauliche oder vor Weitergabe geschĂĽtzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfänger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfältigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtĂĽmlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu löschen, ohne Kopien einzubehalten. Danke. > > -----Original Message----- > From: Stastny Richard > Sent: Sunday, June 20, 2004 10:29 PM > To: Richard Shockey > Cc: enum at ietf.org > Subject: AW: [Enum] Carrier ENUM mini-BoF Agenda > > So given Steven questions, my "User ENUM" definitions > and Richards "Carrier TN to URI translation mechanisms" aka "Carrier ENUM", >  > I want to try to give an answer to question 1b first, before I address 1a >  > a: within User ENUM there exist privacy issues. >    set-up properly these issues do not exist in "Carrier ENUM", >    because either the information is not accessible or not usable >    by end-users. >    Note: all privacy issues with ENUM should thereore be discussed >    in the first half of the meeting, not in the mini-BoF on "Carrier ENUM" >  > b. "User ENUM" is end-to-end and therefore opt-in >  -  Service providers wanting to deploy a routing of calls >    between their networks avoiding the PSTN as interconnect >    need a tool on the Internet to achieve this goal. (This >    tool is also necessary if no PSTN exists anymore ;-) > >   - They may choose to use the technology as defined >    in RFC3761 at al. > >  - To achieve this they have to include ALL E.164 numbers assigend >     to them and they in turn assigned to the end-users they >     are providing service for (anybody an idea of a better wording?) >     so opt-in is not possible. > > -  confederations of service providers may choose any domain in >    the DNS as root for their tree, they may even choose a "private DNS" >  >  - If a service provider  populates the tree only with E.164 numbers >     assigned to him, a later merging of trees is trivial, because no overlaps >     exist. >  - currently also nor additional requirements on the ENUM protocol >    are known. If there are, please come forward now. >  > Warning: the above definition is only valid if "carrier ENUM" is > only used for routing to destination service providers hosting the > numbers they hold in the tree. >  > So > 1a: What are the issues/problems that need to be addressed? > Recently some requirements have been discussed to use > ENUM and especially "carrier ENUM" for additional > purposes,e.g. routing to transit providers if they also > provide gateways to the PSTN. >  > Although this is in principle possible with ENUM, this > is not recommended because it may cause conflicts in > domain ownerships and make it impossible to merge > trees later. >  > Since in most cases routing to the PSTN is involved, > this immediately raises the question of settlement and > alternative routes. > > ENUM as it is now is not providing these functions, one > should use TRIP or OSP for this. >  > The mini-BoF may discuss this issue and may come > to a conclusion. (reject the issue or extend ENUM) > > Richard > > ------------------------------------------------------------------------ > > Part 1.2 Type: Plain Text (text/plain) > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Fri, 25 Jun 2004 05:11:57 -0400 From: "Fullbrook Kim (UK)" Date: Fri, 25 Jun 2004 05:11:57 -0400 To: "'enum at ietf.org> Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Status: R Summarising what's being said here, making a call to is just mapped to sip:@telco.com  i.e. a call to 1234567890 becomes a call to sip:1234567890 at bigtelco.com    If we stand back from the immediate ENUM issues here, would we all agree that the underlying intent in the SIP world is to move to a world of "user friendly" addresses (SIP URI)  rather than E.164 numbers ?  E.164 numbers are retained for compatibility reasons but this is a secondary form of addressing. Given this, that the primary means of addressing SIP services is e.g. johndoe at bigtelco.com    this implies there has to be another mapping database behind the scenes to map the 1234567890  on to johndoe    This second mapping database would surely be an ENUM database accessible only by operators, thereby reinforcing the case for separating out "user ENUM" - which does the first mapping - from "Operator ENUM"  - which does the second ?   While I'm quite comfortable with this model because it does deal appropriately with the privacy difficulties while also ensuring call routing is maintained, I am concerned that the deployment is now different to my interpretation of what the RFCs originally intended which is a single global domain structure.  We have a missing step which is to specify how the "Operator ENUM" structure is set up and separated from the "user ENUM".  A number of valid suggestions have already been made on this list but surely the first step is to gain agreement on this principle for the way forward, or propose an alternative which deals with the privacy concerns ? Kim. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: 24 June 2004 21:26 To: enum at ietf.org Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) No, what Mike meant here is mcu simpler:   assume you have number +437801234567 so you have an ENUM domain 7.6.5.4.3.2.1.0.8.7.3.4.e164.arpa in this domain you put a NAPTR with e.g. enumservice E2U+sip and a URI sip:437801234567 at bigtelco.com   within your SIP server the user jdoe gets an alias 437801234567 (or the other way round)   so only infromation somebody gets querying ENUM for the number +437801234567 is in addition is the provider.   < FONT SIZE=2>But user jdoe may still be reached via sip:jdoe at bigtelco.com for somebody knowing this.   Richard           -----Ursprüngliche Nachricht-----         Von: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM]         Gesendet: Do 24.06.2004 10:45         An: 'enum at ietf.org'         Cc:         Betreff: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)                         It's not clear to me exactly what you're suggesting here.         - If the DNS you're referring to is private then no concerns.         - If the DNS is publicly accessible then are you saying that in the DNS the E.164 number only has a domain name corresponding to it without a username   e.g. 12345678909 -> sip:bigtelco.com   ?  This would be an incomplete URI and would need some other mechanism to provide call routing to a specific user, perhaps a full ENUM DNS which is only accessible by Operators.  This "two tier" system would get rid of most of the privacy concerns but with the downside of some duplication of material.  Could be a solution worthy of further study.         - If the DNS is publicly accessible with the URI in usual format e.g. 12345678909 -> sip:jdoe at bigtelco.com  then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out".         Kim.         -----Original Message-----         From: Mike Hammer [mailto:mhammer at cisco.com]         Sent: 22 June 2004 20:38         To: Jeff Williams         Cc: enum at ietf.org; Stastny Richard         Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)                 I would argue that for any E.164 number in the form of a domain name that         is found within the DNS, if the resulting records point simply to         information of a service or a service provider address that does not         provide more information specific to an individual subscriber, then no         privacy violation has occurred.  Any messages sent to that address, be they         http, email, im, sip, h323, or whatever can then be handled on their own         terms.  Routing happens.   _____          ========================================================         This electronic message contains information from the mmO2 plc Group         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.         ========================================================         ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 Kim.Fullbrook@O2.COM Fri, 25 Jun 2004 05:11:59 -0400 From: "Fullbrook Kim (UK)" Date: Fri, 25 Jun 2004 05:11:59 -0400 To: "'enum at ietf.org> Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Status: R The underlying intent in the SIP world is for everyone to have a "user friendly" address rather than an E.164 number.  I might choose to have a SIP URI as kim at bigtelco.com  - a name which says something about me - and will probably have a similarity to my email address and Presence address.  I don't want to have to choose  x43thyu at bigtelco.com  to maintain obscurity.  Perhaps we may have to argue over whether someone whose SIP URI is oldbrowneyes at bigtelco.com is being obscure or giving out information about themself.  My assertion is that this is personal information and should be kept private if the owner wishes. If someone wardials a list of E.164 numbers today they will get ring tone (or busy tone) from valid numbers and probably "number unobtainable" from invalid numbers.  But all they have is a list of numbers.  There is nothing to distinguish one number from another. My number doesn't say anything about me except possibly the area I live in or the carrier that I use.  The intent of the ENUM DNS (from RFC 2916) is that it can be "used for identifying available services connected to one E.164 number" giving examples of re-directs, email address and web page. Someone can wardial the DNS using E.164 numbers to get back a list of SIP URIs and potentially other information such as email addresses. My definition of a phone book obtained by this means is a list of valid SIP URIs which contain some user-specific information.  So to sum up and answer the question: - a list of e.164 numbers is just a list of numbers which says nothing about the owner of the number, only that there is probably a working phone on the end of it - A list of SIP URIs, if we follow the intent behind the use of SIP, is that it makes available naming information about that person which they may not want to give out, whether it is in the form of "kim" or "oldbrowneyes". Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 24 June 2004 23:06 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) And how is it different from someone wardial a set of numbers and obtained a list of valid phone number today? ps: list of numbers != phone book. A yellowpage associate a number with a person. -James Seng Fullbrook Kim (UK) wrote: > - If the DNS is publicly accessible with the URI in usual format e.g. > 12345678909 -> sip:jdoe at bigtelco.com  then we are back to the same > situation already described: anyone can "war dial" the DNS and build up > a list of SIP URIs of subscribers which is effectively a publicly > accessible phone book without "opt out". > > Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 24 June 2004 23:06 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) And how is it different from someone wardial a set of numbers and obtained a list of valid phone number today? ps: list of numbers != phone book. A yellowpage associate a number with a person. -James Seng Fullbrook Kim (UK) wrote: > - If the DNS is publicly accessible with the URI in usual format e.g. > 12345678909 -> sip:jdoe at bigtelco.com  then we are back to the same > situation already described: anyone can "war dial" the DNS and build up > a list of SIP URIs of subscribers which is effectively a publicly > accessible phone book without "opt out". > > Kim. > > -----Original Message----- > From: Mike Hammer [mailto:mhammer at cisco.com] > Sent: 22 June 2004 20:38 > To: Jeff Williams > Cc: enum at ietf.org; Stastny Richard > Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > > > I would argue that for any E.164 number in the form of a domain name that > is found within the DNS, if the resulting records point simply to > information of a service or a service provider address that does not > provide more information specific to an individual subscriber, then no > privacy violation has occurred.  Any messages sent to that address, be they > http, email, im, sip, h323, or whatever can then be handled on their own > terms.  Routing happens. > > ------------------------------------------------------------------------ > > ======================================================== > This electronic message contains information from the mmO2 plc Group > 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 ========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby 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 jseng@pobox.org.sg Fri, 25 Jun 2004 06:22:23 -0400 From: James Seng Date: Fri, 25 Jun 2004 06:22:23 -0400 To: "Fullbrook Kim (UK)" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40DBFB76.6080600@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R Fullbrook Kim (UK) wrote: The underlying intent in the SIP world is for everyone to have a "user friendly" address rather than an E.164 number. And a E.164 number is also a user-friendly identifier as much as SIP is. > I might choose to have a SIP URI as kim at bigtelco.com - a name which says something about me - and will probably have a similarity to my email address and Presence address. If you choose it to be similar, thats your choice. But you can also choose it to be different. I don't want to have to choose x43thyu at bigtelco.com to maintain obscurity. Then find a ITSP which dont do this. The choice is still yours. > Perhaps we may have to argue over whether someone whose SIP URI is oldbrowneyes at bigtelco.com is being obscure or giving out information about themself. My assertion is that this is personal information and should be kept private if the owner wishes. As you can see above, you have a choice. > If someone wardials a list of E.164 numbers today they will get ring tone (or busy tone) from valid numbers and probably "number unobtainable" from invalid numbers. But all they have is a list of numbers. There is nothing to distinguish one number from another. My number doesn't say anything about me except possibly the area I live in or the carrier that I use. Yes. The intent of the ENUM DNS (from RFC 2916) is that it can be "used for identifying available services connected to one E.164 number" giving examples of re-directs, email address and web page. > Someone can wardial the DNS using E.164 numbers to get back a list of SIP URIs and potentially other information such as email addresses. My definition of a phone book obtained by this means is a list of valid SIP URIs which contain some user-specific information. Not _neccessary_. While it is _possible_ for someone to obtain a lot of information by doing ENUM queries, you can either choose to put in this information yourself or you don't. And if you don't then, either because your ISPs do it without asking for your permission or it is mandated by the regulator, then you have a ITSP /regulation which dont understand privacy, and that's an issue *you* bring to them, not to ENUM WG. So to sum up and answer the question: - a list of e.164 numbers is just a list of numbers which says nothing about the owner of the number, only that there is probably a working phone on the end of it - A list of SIP URIs, if we follow the intent behind the use of SIP, is that it makes available naming information about that person which they may not want to give out, whether it is in the form of "kim" or "oldbrowneyes". Nope. You have a choice. There is nothing to say your SIP address = Email address. For a lot of reasons, my IETF EMail address != Person Email address != Personal Phone number != SIP Address. In summary, your _supposingly_ problem, is a problem of many _ifs_. If user sip address = email, and if you put that into DNS or if someone else put it into it without your permission, and if someone wardials, etc. Along each of these 'ifs', there are many alternative realities which does not violate privacy. -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Fri, 25 Jun 2004 11:10:53 -0400 From: "Livingood, Jason" Date: Fri, 25 Jun 2004 11:10:53 -0400 To: "'Fullbrook Kim (UK)'" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Kim Fullbrook wrote 2 examples that would not work: > e.g. 12345678909 -> sip:bigtelco.com ? This would be an incomplete URI... > e.g. 12345678909 -> sip:jdoe at bigtelco.com then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out". What about sip:12345678909 at bigtelco.com as the URI? Does that display privacy information in anyone's view if 12345678909 represents a number on the PSTN which is reachable by anyone else with a telephone? Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Fri, 25 Jun 2004 11:53:37 -0400 From: "Livingood, Jason" Date: Fri, 25 Jun 2004 11:53:37 -0400 To: "'Fullbrook Kim (UK)'" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Kim wrote: > The intent of the ENUM DNS (from RFC 2916) is that it can be "used for identifying > available services connected to one E.164 number" giving examples of re-directs, email > > address and web page. > Someone can wardial the DNS using E.164 numbers to get back a list of SIP URIs and > potentially other information such as email addresses. My definition of a phone book > obtained by this means is a list of valid SIP URIs which contain some user-specific > information. I agree that this is possible, which begs the question of *why* a rational person would choose to register a number in ENUM and request with their SP that service addresses (email addr, IM ID, mobile #, etc.) be associated with their E.164 number? The only use case I can reasonably imagine is one for businesses, whereby 1-800-COMPANY is associated in ENUM with a variety addresses for that company (www.company.com, support at company.com, etc.). These are entities which want to share as much contact information as possible, compared to consumers which generally wish to share as little as possible. This business use is perhaps not a sufficient justification for investment in ENUM infrastructure in various countries (unless establishing a working business model is a thing of the past - but I think the bubble days are gone). What we seem to have, however, is a massive new market for VoIP services that would find ENUM to be a very helpful solution to enable softswitches (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions. The ultimate goal for these providers is to route calls over IP networks, without touching the PSTN (and therefore incurring various charges according to the PSTN regulatory regime). There is no technical reason why 'public' ENUM cannot be applied to this problem (I am purposely using 'public' and ignoring the artificial and loosely defined concepts of 'user' and 'carrier' ENUM - everyone has their own understanding of each it seems). Going back to Steve Lind's question of (paraphrasing) what problem the IETF is trying to solve, I still don't see an answer. IMHO, ENUM can be used by Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, CLECs, IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is for describing voice). It will be impossible to solve some constantly-shifting debate about 'privacy' in ENUM since no one seems to be able to agree on what privacy is (which is quite natural). However, privacy can be more readily defined and agreed upon at the national level, which is how the public ENUM delegations occur. Each country is likely to have different ways of viewing personal information and privacy, and have different laws, rules, and regulations to this effect. Within countries, different providers may be treated differently and have different standards to meet for notifying or seeking the consent of customers of the entry of their TN into ENUM (such as a highly regulated traditional telco vs. an unregulated ISP). So it appears to me, at least, that privacy issues are best addressed locally, in each country. And if that is the case, what is the point of much of the discussion on this list in the past several weeks? What is the technical problem at hand? Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 25 Jun 2004 12:57:58 -0400 From: Jim Reid Date: Fri, 25 Jun 2004 12:57:58 -0400 To: "Livingood, Jason" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <25562.1088179990@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Jason" == Livingood, Jason writes: Jason> What about sip:12345678909 at bigtelco.com as the URI? Does Jason> that display privacy information in anyone's view if Jason> 12345678909 represents a number on the PSTN which is Jason> reachable by anyone else with a telephone? Maybe, maybe not. But it does fall foul of most EU data protection legislation. Under that, any data which identifies a living person is classed as "personal data" and there are rules about how it can be used, processed and accessed. However most of these evaporate under the opt-in principle when the data subject consents to having their personal data stored in a computer system and knows how it will be used. Disclaimer: I am not a lawyer and don't play one on TV. But in a previous life I have had to deal with the UK's Data Protection Act. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 25 Jun 2004 12:58:00 -0400 From: Richard Shockey Date: Fri, 25 Jun 2004 12:58:00 -0400 To: "Livingood, Jason" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <6.1.0.6.2.20040625121109.039ada58@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 10:13 AM 6/25/2004, Livingood, Jason wrote: Kim Fullbrook wrote 2 examples that would not work: > e.g. 12345678909 -> sip:bigtelco.com ? This would be an incomplete URI... > e.g. 12345678909 -> sip:jdoe at bigtelco.com then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out". What about sip:12345678909 at bigtelco.com as the URI? Does that display privacy information in anyone's view if 12345678909 represents a number on the PSTN which is reachable by anyone else with a telephone? This BTW is exactly the example I put in my Privacy and Security Draft The optimal SIP AOR is for use in ENUM systems is: sip:e164number at serviceprovider.foo remember privacy and security is not a issue for ENUM ..ENUM is only a TN to URI translation database. Privacy and security controls are a SIP issue and should be managed and controlled there. Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 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 mhammer@cisco.com Fri, 25 Jun 2004 13:50:15 -0400 From: Mike Hammer Date: Fri, 25 Jun 2004 13:50:15 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <4.3.2.7.2.20040625133137.089cc928@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, Could you explain where the personal information is in the sip address you cite? It tells you absolutely nothing about who that number is assigned to, or even if it is assigned to someone at all. If this runs afoul of EU legislation, then that legislation has some serious problems. Mike At 05:13 PM 6/25/2004 +0100, Jim Reid wrote: >>>>> "Jason" == Livingood, Jason writes: Jason> What about sip:12345678909 at bigtelco.com as the URI? Does Jason> that display privacy information in anyone's view if Jason> 12345678909 represents a number on the PSTN which is Jason> reachable by anyone else with a telephone? Maybe, maybe not. But it does fall foul of most EU data protection legislation. Under that, any data which identifies a living person is classed as "personal data" and there are rules about how it can be used, processed and accessed. However most of these evaporate under the opt-in principle when the data subject consents to having their personal data stored in a computer system and knows how it will be used. Disclaimer: I am not a lawyer and don't play one on TV. But in a previous life I have had to deal with the UK's Data Protection Act. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 25 Jun 2004 14:25:53 -0400 From: Jim Reid Date: Fri, 25 Jun 2004 14:25:53 -0400 To: Mike Hammer Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <4.3.2.7.2.20040625133137.089cc928@cia.cisco.com> Message-ID: <25812.1088187379@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Mike" == Mike Hammer writes: Mike> Jim, Could you explain where the personal information is in Mike> the sip address you cite? I didn't cite any sip address. Mike> It tells you absolutely nothing about who that number is Mike> assigned to, or even if it is assigned to someone at all. That's true. But if the address does identify a living person, it will be subject to EU Data Protection legislation within EU jurisdiction. Mike> If this runs afoul of EU legislation, then that legislation Mike> has some serious problems. Welcome to the real world. :-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 25 Jun 2004 14:59:21 -0400 From: Mike Hammer Date: Fri, 25 Jun 2004 14:59:21 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <4.3.2.7.2.20040625144939.00b7fde8@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 07:16 PM 6/25/2004 +0100, Jim Reid wrote: >>>>> "Mike" == Mike Hammer writes: Mike> Jim, Could you explain where the personal information is in Mike> the sip address you cite? I didn't cite any sip address. Pardon, that Jason cited: sip:12345678909 at bigtelco.com Mike> It tells you absolutely nothing about who that number is Mike> assigned to, or even if it is assigned to someone at all. That's true. But if the address does identify a living person, it will be subject to EU Data Protection legislation within EU jurisdiction. Mike> If this runs afoul of EU legislation, then that legislation Mike> has some serious problems. Welcome to the real world. :-) Well, the solution is to fix bad laws, not non-problems. Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 25 Jun 2004 15:28:13 -0400 From: "Stastny Richard" Date: Fri, 25 Jun 2004 15:28:13 -0400 To: "Jim Reid" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437AC@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Sorry, but I consider this a busllshit or Jim is trying to pull your leg. I know that people in the UK are paranoic about privacy, e.g. 30% are unlisted in the phonebook, in Austria this 5-10%. But UK is not really Europe. Nevertheless, if this would be true, also a domain name in ENUM would be not possible in the first place, because this would also trespass your privacy. So if you put some information in this domain which is not disclosing more information as you already disclosed, this cannot violate any law. Richard -----UrsprĂngliche Nachricht----- Von: Jim Reid [mailto:jim at rfc1035.com] Gesendet: Fr 25.06.2004 20:16 An: Mike Hammer Cc: enum at ietf.org Betreff: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) >>>>> "Mike" == Mike Hammer writes: Mike> Jim, Could you explain where the personal information is in Mike> the sip address you cite? I didn't cite any sip address. Mike> It tells you absolutely nothing about who that number is Mike> assigned to, or even if it is assigned to someone at all. That's true. But if the address does identify a living person, it will be subject to EU Data Protection legislation within EU jurisdiction. Mike> If this runs afoul of EU legislation, then that legislation Mike> has some serious problems. Welcome to the real world. :-) _______________________________________________ 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 james.f.baskin@verizon.com Fri, 25 Jun 2004 15:42:58 -0400 From: james.f.baskin@verizon.com Date: Fri, 25 Jun 2004 15:42:58 -0400 To: "Jim Reid" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Jim R, Assuming that a string of digits equal to a telephone number assigned to an person "identifies a living person" and is subject to EU Data Protection legislation, what exactly does the legislation allow or disallow regarding publishing that string of digits in a publicly accessible database?   Does the data protection legislation require opt-in by that person?   What happens if that string of digits also happens to identify some other living person because it happens to match that person's public library card number or some other identifier? Is British Telecom required to get everyone in its on-line telephone directory to explicitly opt-in before listing them?  BT's on-line directory lists name, telephone number, and street address.   If you are saying that before publishing any data element that identifies a living person one should review the data protection rules to be sure the publication complies with the rules, that is a reasonable suggestion.  However, if you are suggesting that publication of "sip:123456789 at serviceprovider.com" is prohibited by the data protection legislation without prior approval (opt-in), that is something else entirely. Are you making the latter suggestion? Jim B >>>>> "Mike" == Mike Hammer writes: Mike> Jim, Could you explain where the personal information is in Mike> the sip address you cite? I didn't cite any sip address. Mike> It tells you absolutely nothing about who that number is Mike> assigned to, or even if it is assigned to someone at all. That's true. But if the address does identify a living person, it will be subject to EU Data Protection legislation within EU jurisdiction. Mike> If this runs afoul of EU legislation, then that legislation Mike> has some serious problems. Welcome to the real world. :-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 25 Jun 2004 15:48:35 -0400 From: Jim Reid Date: Fri, 25 Jun 2004 15:48:35 -0400 To: "Stastny Richard" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437AC@oefeg-s02.oefeg.loc> Message-ID: <25945.1088192414@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: Richard> Sorry, but I consider this a busllshit or Jim is trying Richard> to pull your leg. I know that people in the UK are Richard> paranoic about privacy, e.g. 30% are unlisted in the Richard> phonebook, in Austria this 5-10%. But UK is not really Richard> Europe. You may consider this bullshit, but you're wrong. You are confusing privacy with data protection. These are completely different things. The former is concerned with the disclosure of data. The latter deals with what happens to that (non-private) data when it is disclosed. My credit history is confidential. But under the Data Protection legislation, I'm entitled to find out what data my bank is storing about me and get that corrected if it's wrong. There are rules about how the bank can process that information and what use it gets put to. That's in addition to the non-disclosure protections. Richard> So if you put some information in this domain which is Richard> not disclosing more information as you already disclosed, Richard> this cannot violate any law. AFAIK, nobody was talking about violating any law. I just pointed out that ENUM will cause "personal data" to be published in the DNS. In the context that EU Data Protection law defines that term: ie something that identifies a living person. If that personal data gets stored on computers in the EU, the use of that data is subject to the provisions of EU Data Protection legislation. That, Richard, is not bullshit. It's a fact. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 25 Jun 2004 16:43:24 -0400 From: Richard Shockey Date: Fri, 25 Jun 2004 16:43:24 -0400 To: enum at ietf.org Subject: [Enum] So far it looks like Wed afternoon. Message-ID: <6.1.0.6.2.20040625162407.03a39ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R WEDNESDAY, August 4, 2004 0800-1700 IETF Registration - Harbor Island Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer 0900-1130 Morning Sessions APP marid MTA Authorization Records in DNS WG INT dhc Dynamic Host Configuration WG OPS mboned MBONE Deployment WG * RTG pce Path Computation Element BOF SEC pkix Public Key Infrastructure WG TSV rddp Remote Direct Data Placement WG TSV sip Session Initiation Protocol WG 1130-1300 Break 1300-1500 Afternoon Sessions I IRTF asrg Anti Spam Working Group OPS capwap Control and Provisioning of Wireless Access Points WG OPS dnsop Domain Name System Operations WG * RTG rpsec Routing Protocol Security Requirements WG SEC krbwg Kerberos WG TSV enum Telephone and Number Mapping WG TSV mmusic Multiparty Multimedia Session Control WG * >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 25 Jun 2004 16:54:23 -0400 From: Jim Reid Date: Fri, 25 Jun 2004 16:54:23 -0400 To: james.f.baskin at verizon.com Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <26012.1088195867@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "james" == james f baskin writes: Hmm. It seems our American and Austrian readers need a primer on the principles of EU Data Protection. Here goes.... james> Assuming that a string of digits equal to a telephone james> number assigned to an person "identifies a living person" james> and is subject to EU Data Protection legislation, what james> exactly does the legislation allow or disallow regarding james> publishing that string of digits in a publicly accessible james> database? It doesn't really say anything about that. It does however say a number of other things. The entity that stores and manipulates the data (the data controller) is supposed to register the fact that they are storing personal data and the purposes that it gets used for. ie "I'm a telco and I store the names and addresses of my customers so they can be sent bills." A data subject -- ie end user -- is entitled to ask the data controller for a record of any data that's stored about them and what it gets used for. If that data is incorrect, the data subject can get it fixed. They can also get compensation when personal data is improperly used. The data controller is not allowed to use the personal data for unregistered purposes. And they can't have that data processed or stored somewhere that doesn't follow EU data protection legislation. Things get easier with individuals who are storing personal data for private or hobby purposes. The Information Commissioner's office doesn't care that I have a couple of mailing lists on my server and my laptop has the names and addresses of friends and colleagues on it. They would care if I was providing a UK directory enquiries service and hadn't registered that usage with them. So provided the telco or ISP tells the Information Commissioner's office that they'll be publishing the data, that should be enough. But some safeguards will have to be in place. Which could mean opt-in will be mandatory because the personal data gets published on the internet where it could be processed by entities who don't comply with EU data protection legislation and are beyond EU jurisdiction. At this point, professional advice is needed. james> Does the data protection legislation require opt-in by that james> person? No. Though this is usually implicit whenever someone signs up for anything that creates an electronic record. Lots of things like forms for opening bank accounts and so on will have small print about the data subject's rights and safeguards under the Data Protection laws. james> What happens if that string of digits also happens to james> identify some other living person because it happens to james> match that person's public library card number or some james> other identifier? Nothing. It's not the string of digits that matter. It's the fact they're stored on a computer and the uses it then gets put to that matters. If I've got a beef with the local library's use of any personal data they have about me, I'll take that up with their data protection officer. That's another provision of the legislation. james> Is British Telecom required to get everyone in its on-line james> telephone directory to explicitly opt-in before listing james> them? No. But BT is required to register that they maintain that data on a computer and to allow data subjects to access their personal data and get it corrected if necessary. Which you'd expect a phone company would want to do for a telephone directory anyway. This time I'll resist the temptation to take a cheap shot at BT. james> If you are saying that before publishing any data element james> that identifies a living person one should review the data james> protection rules to be sure the publication complies with james> the rules, that is a reasonable suggestion. I am. Even so, putting personal data into the DNS could be a data protection nightmare. james> However, if you are suggesting that publication of james> "sip:123456789 at serviceprovider.com" is prohibited by the james> data protection legislation without prior approval james> (opt-in), that is something else entirely. Are you making james> the latter suggestion? No. Though it might be if I'm populating the DNS with personal data about zillions of people and haven't told the Information Commissioner that I'm doing that. Or whacking that data on to servers outside the EU. Or maybe allowing that data to be mined by third parties (spammers perhaps) so it can be used for purposes that haven't been registered or are outside EU jurisdiction. Visit www.informationcommissioner.gov.uk if you want more info about EU Data Protection and how it's applied in the UK. The same principles apply throughout the EU, though the details may be different in EU member states. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 25 Jun 2004 16:58:10 -0400 From: "Peter Williams" Date: Fri, 25 Jun 2004 16:58:10 -0400 To: jim at rfc1035.com Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R AFAIK, nobody was talking about violating any law. I just pointed out that ENUM will cause "personal data" to be published in the DNS. In the context that EU Data Protection law defines that term: ie something that identifies a living person. If that personal data gets stored on computers in the EU, the use of that data is subject to the provisions of EU Data Protection legislation. That, Richard, is not bullshit. It's a fact. Under the US-EU protocol, US companies who violate EU data protection laws get some immunity from tort suits if they have the US-styled privacy policies - which address the issues the EU is concerned about for its users and its consumers. US Consumers here will also be subject to those rules, note, as they may cache the DNS ENUM data in address books, and in their home routers, etc. The rash of privacy policies you see in the US is 100% induced by the threat of data protection suits, in European courts of American companies - for improper disclosure of personal data about EU persons in a manner not conforming to their stated policies (which must conform to a safe-haven clause in the US/EU protocol, furthermore.) This whole issue in ENUM is complicated by the fact that IAB members are clearly setting the standards and operational practices for ENUM, rather than an self-managing, self-directing IETF WG. Authority derived from DARPA research contracts (controlling .arpa via IAB member fiat) and authority from the DoC for ICANN need clarification to see where US stands on the US/EU protocol for DNS routing data that is personal in nature. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 25 Jun 2004 17:51:52 -0400 From: "Stastny Richard" Date: Fri, 25 Jun 2004 17:51:52 -0400 To: Subject: [Enum] Privacy of communication parameters Message-ID: <06CF906FE3998C4E944213062009F1624437AD@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear list, IMHO is the protection of public communication parameters by hiding them away and not publishing them the wrong way to go to protect someones privacy Communication parameters are designed to allow communication. Of course there may be reasons that somebody is forced by circumstances (e.g. getting malicious calls) to unlist his/her phone nmber, but this should not be the normal situation. To protect privacy in communication two things should be enhanced: -secure proof of identifcation and -filtering by personal user agents If someone wants to communicate with me he knows my identity beforehand. To be on equal terms I want to know his identity also before establishing the communication. This does not mean that somebody is not able to establish communication, but it is my choice if I or my PUA accepts such a communication. On the other hand, if I establish a communication I also would like to know if the recipient is realy the one I intended to call, e.g. my bank. Enabling bilateral proof of identity would solve most of the current spamming, pishing, etc. problems. UCI would be one possibility to enable this, and not only for voice, but for any kind of communication. I understand that many people are not satisfied with the currnet situation on the Internet, but the problem cannot be solved by not allowing a technical solution forward because if misused it could do some harm. To solve the current problens a general solution is required and not a partial and very specific one Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 25 Jun 2004 18:44:40 -0400 From: "Stastny Richard" Date: Fri, 25 Jun 2004 18:44:40 -0400 To: "Jim Reid" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437AE@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R The EU Data Protection Law is a typical example of the law you cannot fulfil. So either everybody is breaking it or busines is coming to a complete stop. That's why such types of laws are complete nonsense and dangerous. But this type of rules have tradition in Europe. One other example is strikes of government workers or government near enterprises by working to the rules. The Austrian railway is doing a strike nearly every year by "working to the rules" and then the system comes to a complete stop. q.e.d. Richard -----UrsprĂngliche Nachricht----- Von: Jim Reid [mailto:jim at rfc1035.com] Gesendet: Fr 25.06.2004 22:37 An: james.f.baskin at verizon.com Cc: enum at ietf.org Betreff: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) >>>>> "james" == james f baskin writes: Hmm. It seems our American and Austrian readers need a primer on the principles of EU Data Protection. Here goes.... james> Assuming that a string of digits equal to a telephone james> number assigned to an person "identifies a living person" james> and is subject to EU Data Protection legislation, what james> exactly does the legislation allow or disallow regarding james> publishing that string of digits in a publicly accessible james> database? It doesn't really say anything about that. It does however say a number of other things. The entity that stores and manipulates the data (the data controller) is supposed to register the fact that they are storing personal data and the purposes that it gets used for. ie "I'm a telco and I store the names and addresses of my customers so they can be sent bills." A data subject -- ie end user -- is entitled to ask the data controller for a record of any data that's stored about them and what it gets used for. If that data is incorrect, the data subject can get it fixed. They can also get compensation when personal data is improperly used. The data controller is not allowed to use the personal data for unregistered purposes. And they can't have that data processed or stored somewhere that doesn't follow EU data protection legislation. Things get easier with individuals who are storing personal data for private or hobby purposes. The Information Commissioner's office doesn't care that I have a couple of mailing lists on my server and my laptop has the names and addresses of friends and colleagues on it. They would care if I was providing a UK directory enquiries service and hadn't registered that usage with them. So provided the telco or ISP tells the Information Commissioner's office that they'll be publishing the data, that should be enough. But some safeguards will have to be in place. Which could mean opt-in will be mandatory because the personal data gets published on the internet where it could be processed by entities who don't comply with EU data protection legislation and are beyond EU jurisdiction. At this point, professional advice is needed. james> Does the data protection legislation require opt-in by that james> person? No. Though this is usually implicit whenever someone signs up for anything that creates an electronic record. Lots of things like forms for opening bank accounts and so on will have small print about the data subject's rights and safeguards under the Data Protection laws. james> What happens if that string of digits also happens to james> identify some other living person because it happens to james> match that person's public library card number or some james> other identifier? Nothing. It's not the string of digits that matter. It's the fact they're stored on a computer and the uses it then gets put to that matters. If I've got a beef with the local library's use of any personal data they have about me, I'll take that up with their data protection officer. That's another provision of the legislation. james> Is British Telecom required to get everyone in its on-line james> telephone directory to explicitly opt-in before listing james> them? No. But BT is required to register that they maintain that data on a computer and to allow data subjects to access their personal data and get it corrected if necessary. Which you'd expect a phone company would want to do for a telephone directory anyway. This time I'll resist the temptation to take a cheap shot at BT. james> If you are saying that before publishing any data element james> that identifies a living person one should review the data james> protection rules to be sure the publication complies with james> the rules, that is a reasonable suggestion. I am. Even so, putting personal data into the DNS could be a data protection nightmare. james> However, if you are suggesting that publication of james> "sip:123456789 at serviceprovider.com" is prohibited by the james> data protection legislation without prior approval james> (opt-in), that is something else entirely. Are you making james> the latter suggestion? No. Though it might be if I'm populating the DNS with personal data about zillions of people and haven't told the Information Commissioner that I'm doing that. Or whacking that data on to servers outside the EU. Or maybe allowing that data to be mined by third parties (spammers perhaps) so it can be used for purposes that haven't been registered or are outside EU jurisdiction. Visit www.informationcommissioner.gov.uk if you want more info about EU Data Protection and how it's applied in the UK. The same principles apply throughout the EU, though the details may be different in EU member states. _______________________________________________ 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 jwkckid1@ix.netcom.com Fri, 25 Jun 2004 22:28:02 -0400 From: Jeff Williams Date: Fri, 25 Jun 2004 22:28:02 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <25812.1088187379@gromit.rfc1035.com> Message-ID: <40DCF7C2.D4216266@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, Mike and all, Jim Reid wrote: > >>>>> "Mike" == Mike Hammer writes: > > Mike> Jim, Could you explain where the personal information is in > Mike> the sip address you cite? > > I didn't cite any sip address. > > Mike> It tells you absolutely nothing about who that number is > Mike> assigned to, or even if it is assigned to someone at all. > > That's true. But if the address does identify a living person, it will > be subject to EU Data Protection legislation within EU jurisdiction. > > Mike> If this runs afoul of EU legislation, then that legislation > Mike> has some serious problems. > > Welcome to the real world. :-) That's right Jim and Mike. And the real world is whom will be the customers of ENUM assignments. The real world is made up of mostly but not completely individuals whom are stakeholders/users or soon to become potential individual stakeholders/users... They make the rules through their elected representatives by in large or they may make the rules directly through various means... > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 25 Jun 2004 22:41:25 -0400 From: Jeff Williams Date: Fri, 25 Jun 2004 22:41:25 -0400 To: Mike Hammer Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40DCFA52.218C860E@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike and all, Mike Hammer wrote: > At 07:16 PM 6/25/2004 +0100, Jim Reid wrote: > > >>>>> "Mike" == Mike Hammer writes: > > > > Mike> Jim, Could you explain where the personal information is in > > Mike> the sip address you cite? > > > >I didn't cite any sip address. > > Pardon, that Jason cited: > > sip:12345678909 at bigtelco.com > > > Mike> It tells you absolutely nothing about who that number is > > Mike> assigned to, or even if it is assigned to someone at all. > > > >That's true. But if the address does identify a living person, it will > >be subject to EU Data Protection legislation within EU jurisdiction. > > > > Mike> If this runs afoul of EU legislation, then that legislation > > Mike> has some serious problems. > > > >Welcome to the real world. :-) > > Well, the solution is to fix bad laws, not non-problems. Well the populace of the EU doesn't see it's privacy laws as bad law. The responsibility of technical organizations in part is to comply with the will of the people, not the will of a few small SIG's... > > > Mike > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From pk@TechFak.Uni-Bielefeld.DE Sat, 26 Jun 2004 05:57:50 -0400 From: Peter Koch Date: Sat, 26 Jun 2004 05:57:50 -0400 To: enum at ietf.org Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437AE@oefeg-s02.oefeg.loc> Message-ID: <200406260952.i5Q9q5A15260@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: text/plain Status: R "Stastny Richard" wrote: > VGhlIEVVIERhdGEgUHJvdGVjdGlvbiBMYXcgaXMgYSB0eXBpY2FsIGV4YW1wbGUNCm9mIHRoZSBs > YXcgeW91IGNhbm5vdCBmdWxmaWwuIFNvIGVpdGhlciBldmVyeWJvZHkgaXMgYnJlYWtpbmcNCml0 I'd rather say UGxlYXNlIGRvIG5vdCB1c2UgdGhlIGJhc2U2NCBlbmNvZGluZyBmb3IgdGV4dCBk YXRhLgo= -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Sat, 26 Jun 2004 07:19:54 -0400 From: "Conroy, Lawrence (SMTP)" Date: Sat, 26 Jun 2004 07:19:54 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437AC@oefeg-s02.oefeg.loc> Message-ID: <09B0A2D4-C761-11D8-A17E-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Richard, folks, actually, it's 40%. It makes no difference, in my experience - you still get cold called. Remember, the DPA was brought in originally as the UK was faced with an EU directive and had to enact a law or all other EU states would be forced to treat it like other duff countries that have no acceptable data privacy controls. Recall the fun with the US deciding in the end that the EU was serious and allowing the safe haven privacy control self-certifications for companies? This strikes me as a p*ss*ng competition between Countries/Blocs, and as it's still just "You, Me, and the NSA"**, rather pointless. ** [and friends - don't forget the mutual assistance laws] As I understand it, the DPA does not cover personal web sites or data that I ask to be published; it covers the use of that data by the people storing it. In the case of a web hosting service, that's the whole point (i.e. it's what I'm paying them to do). Now, if you believe that the web hosting service has to find what personal data I've just pushed to my web site, then notify the Government to say what that data is and how they're using it, then we're in LaLa Land. When the DPA first came in and the DP Registrar was totally overwhelmed with paperwork flying in their direction; notification of personally published data would be an absurdity that WILL be ignored as it would make that look like a very quiet day in the office. If one expects DNS Providers to do this is, then that random neural firing is, in my opinion, equally bizarre. In short: If I want to publish my contacts, then "Get Your Tanks Off My Lawn". If I want to control who gets to see what contacts, then I'll use a PUA system, with a "global" entry in ENUM pointing to that. The IETF and (eventually) IANA and the ITU/IAB have done their job. I have a mechanism to do at least the global publication. Now, on the PUA stuff you can bury it in Legal issues until hell freezes over. For the rest, it's my risk, and my choice. I don't live in California. all the best, Lawrence On 25 Jun 2004, at 20:15, Stastny Richard wrote: I know that people in the UK are paranoic about privacy, e.g. 30% are unlisted in the phonebook, in Austria this 5-10%. But UK is not really Europe. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Sat, 26 Jun 2004 13:31:14 -0400 From: "Peter Williams" Date: Sat, 26 Jun 2004 13:31:14 -0400 To: jseng at pobox.org.sg Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R We have a history in IETF of addressing privacy in the area of name bindings. For nearly 20 years, we have addressed disclosures in the area of CA - TTPs (much like ENUM TTPs) that address name bindings. Whereas CAs bind names in a certificate, ENUM providers will bind names in a DNS entry. And if you don't then, either because your ISPs do it without asking for your permission or it is mandated by the regulator, then you have a ITSP /regulation which dont understand privacy, and that's an issue *you* bring to them, not to ENUM WG. ENUM WG can decide to follow the practice of other WGs in addressing policy disclosures, and means for accessing policy discloures about name bindings, or it can decide to offload the issues to future subscribers and/or users. Inevitably the AD will be heavily involved in this, and the factors and communications that sway her will be up for IETF disclosure, and (as IETF operates mainly in the US) discovery. What she cannot argue is that IETF has no understanding or involvement in the topic area: it has considerable knowhow, and has previously standardized topics in the area of operational policy disclosure for name binding mechanisms before now. Mostly significantly, it has undertaken to publish compliance criteria for such operators to use ,when measuing their conformance to the IETF policy disclosure standards - for name binding mechanisms. Peter. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Sat, 26 Jun 2004 14:08:02 -0400 From: "Peter Williams" Date: Sat, 26 Jun 2004 14:08:02 -0400 To: lwc at roke.co.uk Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R As I understand it, the DPA does not cover personal web sites or data that I ask to be published; it covers the use of that data by the people storing it. In the case of a web hosting service, that's the whole point (i.e. it's what I'm paying them to do). Many of these protection schemes that address privacy issues (both in the US, and the EU) regulate providers, who can be reasonably assumed to have subscribers with certain expectations about privacy. Privacy is a hard social issue, with no clear definition. However, there are accepted inflections in public law, statutes and administrative law. We have public data whose sole purpose is sharing, personal data that needs protection against unwarranted exploitation by third parties, private information that one secures appropriately with a technical mechanism, and other important categories. Richard has a certain belief about the privacy expectations of all ENUM Provider subscribers, and argues (rather coarsely) his position. His argument is articulate, but rather unpursuasive, as the basis for his claims are his personal expectations as a subscriber. He happens to be a person with low expectations about certain elements of his personal data, viewing that data has necessarily public in order to achieve his individual communication goals. Now, if you believe that the web hosting service has to find what personal data I've just pushed to my web site, then notify the Government to say what that data is and how they're using it, then we're in LaLa Land. As a potential service provider, lwc, if your website is based on FrontPage, say, and it offers a registration and messaging module for others who can post memos to your site, YOU might be advised to pay a visit to the registrar. I would expect you to do this for any website YOU host at a third party service bureau, a web site you host yourself, or for a DNS server that you operate or cause to be operated - and which distributes personal data about others to others. Your need to comply with data protection regulation, if any, is, "of course," a private and privileged disclosure matter to be shared by you and your legal advisor. When the DPA first came in and the DP Registrar was totally overwhelmed with paperwork flying in their direction; notification of personally published data would be an absurdity that WILL be ignored as it would make that look like a very quiet day in the office. The US Federal government consider many suggestions made to address the problem of people setting and publishing their expectations of privacy. It chose decentralized disclosure making, rather than EU-style registration of disclosures by central bodies; with obvioius impact on the ease by which the scheme could be engendered and indirectly managed into place over time, on a massive scale. In the US commercial arena, the practices for expectation setting settled on placing obligations on the party with most control and the most to gain from exploitation - the telematic service provider. That is, certain (ambiguous) privacy expectations were presumed for all consumers, and a provider may disclose a policy in order to negotiate those expectations down to something acceptable to that person, engaging with the user as they subscribe, or as they use the service (if the providers policy provides notice of its ability to change) or if the user is not a susbcriber. If one expects DNS Providers to do this is, then that random neural firing is, in my opinion, equally bizarre. An ENUM provider is not a classical DNS service provider: ENUM necessarily binds two name forms from two (or more than two) distinct naming authorities. the ENUM provider will be asserting control of that binding of different personal data items, much as a CA binds several personal names in its certificates. In each case, the ENUM provider goes beyond DNS, and goes onto exercise direct control over the delivery of privacy-enhanced (ENUM) or security-enhanced services in the case of ENUM service enhaced with offline certificate chain URIs. While an EU TTP operating ENUM service may attempt to claim it is an unknowing outsourcing contractor supporting a relationship between a subscriber and a SIP-enabled telco, the US TTPs currently fighting for control of ENUM business through ICANN and IAB-related law suits are unlikely to proceed on this course: they need to assert control for their assurance to have much economic value: CISCO can provide critical infastructure-grade servers and operational knowhow to a telco just as well as it can supply it to ******, say, when acting as a TTP operating DNS servers mastering a critical infrastructure zone within .arpa. In short: If I want to publish my contacts, then "Get Your Tanks Off My Lawn". If I want to control who gets to see what contacts, then I'll use a PUA system, with a "global" entry in ENUM pointing to that. Contracts suggest that the data is not personal in nature. While contracts often contain personal data, the use of the contract form already suggests the parties are quite sophisticated, and can negotiate privacy issues (if any) in the terms of the contract - probably with the advice of appropriate legal professionals. The terms may involve the removal of equipment from lawns, if the parties so desire, and can select any security- or privacy-filtering technology that the parties may agree to. In the UK, in particular, third party rights may be implied here, as third parties now have certain rights even though they are not parties to contracts addressing telematic services or information upon which they are induced to rely by the contracting parties. The IETF and (eventually) IANA and the ITU/IAB have done their job. But ICANN have not, and neither (in the US) has the DoC - in revising the procurement contract it places (and must surely revise) with ICANN to address ENUM - given ENUM must use .arpa delegated zones, by IAB mandate. The DOC actions must be publicly reviewed, and the influence of IAB over DoC must be similarly disclosed, if there is any. IAB is acting for and as IETF. Quite properly it discloses its ITU communications (somewhat late, note, for public input), and will surely and necessarily disclose its US government communications on the topic of ENUM regulation. We must recall that IAB has considerable influence over the technical standards controlling operators of those regions of the DNS it designates as critical infrastructure, and has had a history of assigning a critical infrastructure contract (to RIPE) showing coordination with the Internet Society on a topic related to ENUM, and disclosed in an Informational RFC specifically discussing ENUM planning. I have a mechanism to do at least the global publication. We have several mechanisms for performing the act of publishing personal data for distribiution by the DNS, and for use in delivering an IETF-standardized or a proprietary E2U-based telematic data lookup service. And there are IAB mandates essentially on how operators MUST then distribute and control the data that has been so published in the ENUM portion of the DNS. There is, also, evidence of attempts to scope an IETF WG session on the topic of amending the IAB mandate on the options for such distribution, taking input from a closed European Standardization organization; and there is evidence of specific and maintained resistance to the call for the sub-session addressing the possible change in mandate to consider privacy issues, as propery articulated by members of the IETF ENUM WG mailing list Now, on the PUA stuff you can bury it in Legal issues until hell freezes over. For the rest, it's my risk, and my choice. I don't live in California. Unforuantely, CA law may address your activities, in much the same way that national laws derived from the EU directive in question threaten Americans with liability for their actions. all the best, Lawrence On 25 Jun 2004, at 20:15, Stastny Richard wrote: I know that people in the UK are paranoic about privacy, e.g. 30% are unlisted in the phonebook, in Austria this 5-10%. But UK is not really Europe. _______________________________________________ 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 Sat, 26 Jun 2004 16:46:13 -0400 From: "Livingood, Jason" Date: Sat, 26 Jun 2004 16:46:13 -0400 To: enum at ietf.org Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > AFAIK, nobody was talking about violating any law. I just > pointed out that ENUM will cause "personal data" to be > published in the DNS. In the context that EU Data Protection > law defines that term: ie something that identifies a living > person. So I think the operative question then (in a perhaps futile attempt to keep things simple) is whether or not a telephone number (either in standalone E.164 structure 12346567890, or in a SIP URI sip:12346567890 at foo.com) is indeed considered "personal data" or not. I don't happen to believe it is but then I'm not a lawyer either. If someone can show a legal precedent for this or make a good arguement to this effect, please do so. Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Sun, 27 Jun 2004 00:31:25 -0400 From: "IETF-IESG-Support via RT" Date: Sun, 27 Jun 2004 00:31:25 -0400 To: enum at ietf.org Subject: [Enum] [Inquiry #5130] AutoReply: Need phentermine or other drugs - Purchase here online In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Need phentermine or other drugs - Purchase here online", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #5130] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #5130] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, iesg-secretary at ietf.org ------------------------------------------------------------------------- This transaction appears to have no content _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sun, 27 Jun 2004 02:17:11 -0400 From: Jeff Williams Date: Sun, 27 Jun 2004 02:17:11 -0400 To: Peter Williams Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <40DE7E22.C0B7DD17@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter and all, Peter Williams wrote: > We have a history in IETF of addressing privacy in the area of name > bindings. For nearly 20 years, we have addressed disclosures in the area of > CA - TTPs (much like ENUM TTPs) that address name bindings. Whereas CAs bind > names in a certificate, ENUM providers will bind names in a DNS entry. Your right here of course as you state it. And it is that ENUM providers can still bind names with assigned ENUM's to users without those names and numbers being necessarily viewable to anyone. However as the current standards track is now, that is not an option for users to decide, which is where the crux of the privacy problem/issue is from a technical perspective. As the IAB has a history of being anti-privacy bigots, this concern is therefore not only appropriate but also heightened accordingly. > > > > > >And if you don't then, either because your ISPs do it without asking for > >your permission or it is mandated by the regulator, then you have a ITSP > >/regulation which dont understand privacy, and that's an issue *you* bring > >to them, not to ENUM WG. > > > > ENUM WG can decide to follow the practice of other WGs in addressing policy > disclosures, and means for accessing policy discloures about name bindings, > or it can decide to offload the issues to future subscribers and/or users. > Inevitably the AD will be heavily involved in this, and the factors and > communications that sway her will be up for IETF disclosure, and (as IETF > operates mainly in the US) discovery. > > What she cannot argue is that IETF has no understanding or involvement in > the topic area: it has considerable knowhow, and has previously standardized > topics in the area of operational policy disclosure for name binding > mechanisms before now. Mostly significantly, it has undertaken to publish > compliance criteria for such operators to use ,when measuing their > conformance to the IETF policy disclosure standards - for name binding > mechanisms. > > Peter. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 29 Jun 2004 04:27:03 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 04:27:03 -0400 To: "Livingood, Jason" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437BC@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R > There is no technical reason why 'public' > ENUM cannot be applied to this problem (I am purposely using 'public' and > ignoring the artificial and loosely defined concepts of 'user' and > 'carrier' > ENUM - everyone has their own understanding of each it seems). Hi Jason, Sorry for the somewhat delayed answer, I was busy. I think you made a very good point, but there may be a distinction between 'publi'! and 'private'. Let's try an analysis of the ENUM 'market' and the 'customers'. Historically ENUM started with the following idea: 1. A subscriber has already an E.164 number on the PSTN (this was the only way to get an ENUM entry), and he may now decide on his own to request an entry in ENUM (opt-in), given his country has also decided to opt-in. He may now place URI's in his ENUM entry, pointing in principle to whatever a URI may point to, e.g. a sip or mailto URI. Where he gets the URI from in the first place was his own business. This was not a good business model, because it was to complicated, confusing to have two terminations, one on the PSTN and one on the Internet, and finally after three years nobody is able to get a delegation in any country anyway. So only some freaks used it. There was only one potential business: linking IP PBX together: In this case you could reach the same extension from the PSTN and from the Internet, so from a end-user point the same device rings. The user may also just dial a number and the IP PBX checks ENUM First and if nothing is found, it dumps the call to the PSTN. If the company knows that some other companies they are dealing with are also in ENUM, they may save substantial money. Note: this may now also be an option again for residential subscribers considering the new ATA's with FXO-ports (e.g. the SPA-3000, Azatel, etc) 2. Where did the above mentioned freaks get the SIP URI's from? >From "providers" like FWD, sipphone, iptel, or DYI. Now these providers all had numeric userID. Why? Because it is easier to dial them on IP Phones and especially ATAs. These providers now started to link each other together using "cross trunking" access codes, but also some of them wanted to implement ENUM. This is useful, but where to get numbers from. What they needed where numbers NOT yet existing on the PSTN, so no opt-in is required. Some countries considered to open special number ranges for this purpose, but again these numbers are not available really, and if, they will be non-geographic numbers The above mentioned providers in most cases had no (direct) interworking with the PSTN. 3. Some providers started to interwork with the PSTN and here it showed clearly that customer primarily wanted local geographic numbers. Period. These numbers differ from the above mentioned opt-in scheme in 1. that they really terminate on IP, either single numbers ported out or whole number ranges. If these providers want to link each other via ENUM, ALL numbers must be in ENUM, so we have now a clash with the original opt-in model. This problem may still be solved insofar that a user may opt-in with a PSTN line on his own, but with a VoIP service automatically by his provider (e.g. he agrees that his number will be in ENUM (privacy provided) if he is using this service). There are even ways to accommodate both in one tree. Note: one basic attribute of all these options is that the user has in addition to his E.164 number a public URI assigned. He may be reached via this URI regardless of ENUM. So if a calling user knows the URI, he may reach the called party in any case. Or in other words, ENUM is opt-in for the CALLING User also. Sofar the story of public "User" ENUM in e164.arpa. The major problem of e164.arpa is that it is simply not available, so one may get the idea to set up the same principle just in another tree (temporarily?) (silver tree), so every operator may join with his number ranges. 4. Now we have other customers for "ENUM" in addition. Any provider using VoIP internally in his network (e.g YahooBB!, Comcast, etc.) is currently interconnecting via the PSTN. Logically both the providers and the users may benefit if these operators would interconnect via IP. The big difference between these providers and the above mentioned three options is that the subscribers of these operators DO NOT GET AN URI (at least not a public reachable one). There are many reason for this, e.g. the providers do not want to make the internals of there networks public, privacy again (because ALL numbers of an operator needs to be in), but the major reason is: if you make a URI public, you also need to agree on zero-termination. There will also be a clash with already opted-in users. This tree may finally be the authoritative NP tree pointing for each E.164 number to the provider hosting it and MUST be able to do this even if the PSTN ceases to exist. 5. I just want to add one option for completeness: some providers want also to announce not only the numbers they host, but also the number they may make available on the PSTN via their gateways. ENUM is not designed for this, one should use TRIP or OSP for this purpose. I currently do not see a possibility to get all requirements for all 4 options workable in one tree. I also do not see any advantage for option 4 candidates to go for e164.arpa, because they need a solution NOW and they may do this in any tree (public or private) (see also ETSI draft TS 102 055) So I see two possibilities for User and Infrastructure ENUM are: 1. Find a way to implement everything in one tree (which I consider not possible, but I am open for proposals) 2. Make two trees, one for above option 1.-3. and another one for option 4. There is no problem having two trees in parallel, a provider (or even the user himself) may query public User ENUM first and public or private Infrastructure ENUM afterwards. Talking about two trees, of course there will be more trees at the beginning, but if every operator gets delegated only the numbers he is hosting, any two trees may be merged without any problem (if no transit routes are in). This leaves the question of e164.arpa itself. For Infrastructure ENUM there is no need to go into e164.arpa and wait until hell freezes over until all countries have decided eventually to opt-in. Sorry to say, but the same is valid for "User" ENUM. The proposal here is to set up a silver tree immediately by all interested parties, which may or may not be folded back to e164.arpa if it gets useful. Countries already having e164.arpa implemented may be copied over to the silver tree in the meantime. Best regards Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > Sent: Friday, June 25, 2004 5:16 PM > To: 'Fullbrook Kim (UK)'; 'enum at ietf.org' > Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > Kim wrote: > > > The intent of the ENUM DNS (from RFC 2916) is that it can be "used for > identifying > > available services connected to one E.164 number" giving examples of > re-directs, email > > > address and web page. > > Someone can wardial the DNS using E.164 numbers to get back a list of > SIP > URIs and > > potentially other information such as email addresses. My definition of > a > phone book > > obtained by this means is a list of valid SIP URIs which contain some > user-specific > > information. > > I agree that this is possible, which begs the question of *why* a rational > person would choose to register a number in ENUM and request with their SP > that service addresses (email addr, IM ID, mobile #, etc.) be associated > with their E.164 number? > > The only use case I can reasonably imagine is one for businesses, whereby > 1-800-COMPANY is associated in ENUM with a variety addresses for that > company (www.company.com, support at company.com, etc.). These are entities > which want to share as much contact information as possible, compared to > consumers which generally wish to share as little as possible. This > business use is perhaps not a sufficient justification for investment in > ENUM infrastructure in various countries (unless establishing a working > business model is a thing of the past - but I think the bubble days are > gone). > > What we seem to have, however, is a massive new market for VoIP services > that would find ENUM to be a very helpful solution to enable softswitches > (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions. > The > ultimate goal for these providers is to route calls over IP networks, > without touching the PSTN (and therefore incurring various charges > according > to the PSTN regulatory regime). There is no technical reason why 'public' > ENUM cannot be applied to this problem (I am purposely using 'public' and > ignoring the artificial and loosely defined concepts of 'user' and > 'carrier' > ENUM - everyone has their own understanding of each it seems). > > Going back to Steve Lind's question of (paraphrasing) what problem the > IETF > is trying to solve, I still don't see an answer. IMHO, ENUM can be used > by > Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, CLECs, > IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is for > describing voice). It will be impossible to solve some constantly- > shifting > debate about 'privacy' in ENUM since no one seems to be able to agree on > what privacy is (which is quite natural). > > However, privacy can be more readily defined and agreed upon at the > national > level, which is how the public ENUM delegations occur. Each country is > likely to have different ways of viewing personal information and privacy, > and have different laws, rules, and regulations to this effect. Within > countries, different providers may be treated differently and have > different > standards to meet for notifying or seeking the consent of customers of > the > entry of their TN into ENUM (such as a highly regulated traditional telco > vs. an unregulated ISP). So it appears to me, at least, that privacy > issues > are best addressed locally, in each country. And if that is the case, > what > is the point of much of the discussion on this list in the past several > weeks? What is the technical problem at hand? > > Jason Livingood > > > > > > > > > _______________________________________________ > 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 Tue, 29 Jun 2004 08:50:49 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 08:50:49 -0400 To: "Stastny Richard" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BC@oefeg-s02.oefeg.loc> Message-ID: <1778.1088512653@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: Richard> Sofar the story of public "User" ENUM in e164.arpa. The Richard> major problem of e164.arpa is that it is simply not Richard> available, so one may get the idea to set up the same Richard> principle just in another tree (temporarily?) (silver Richard> tree), so every operator may join with his number ranges. Sorry Richard, this is too simplistic. Your so-called silver tree could only work if all the operators reached a consensus on the domain name of that tree and who got to operate and populate it. There's probably about as much chance of that happening as I have of winning Miss World. A unique and consistent naming scheme needs to be deployed in order to avoid all sorts of confusion and bad practices that will deter users and cripple the uptake of ENUM-based services. And as soon as anyone starts talking about entering E.164 numbers into the DNS, the usual government and regulatory issues raise their head. For instance I cannot imagine the Chinese government agreeing to +86 going under a registry operated in Austria. Or vice versa. Maybe your silver tree could fly if all the VoIP providers and their fellow travellers co-operated on setting this up. But so far all I see are competing, mutually exclusive naming schemes which seem to be about protecting market share or locking service providers and end users into a vendor-specific solution. Getting co-operation seems unlikely, even if there was agreement on who did what and how costs were recovered. On top of that I can't see how VoIP provider A would be comfortable exposing their customer's "phone numbers" in some private, shared tree to VoIP provider B. Richard> I currently do not see a possibility to get all Richard> requirements for all 4 options workable in one tree. Indeed. User and Infrastucture ENUM (to use those weasel terms) are different things and cannot possibly exist in the same tree. They can of course use the same domain name, but with different sets of name servers providing different data to different constituencies: one for the public internet and one for private telco-like usage. Since the same sorts of applications are likely to live in both places -- ie VoIP to SIP servers -- it would be sensible to use the same domain name. That would avoid the messy complexity of applications having to figure out where they are today to decide what domain name they should lookup. Richard> There is no problem having two trees in parallel, a Richard> provider (or even the user himself) may query public User Richard> ENUM first and public or private Infrastructure ENUM Richard> afterwards. I don't understand this. An end user should never, ever see a private ENUM tree. Even if querying both trees was possible, how is the user or application supposed to know which one holds the data it's supposed to use? If my phone number is in both places each with 1 NAPTR record pointing at different SIP servers, which one does the application connect to? Now suppose one of those SIP servers lives deep in some telco's net and is unreachable from another operator's net. Or the internet. Or vice versa. Richard> Talking about two trees, of course there will be more Richard> trees at the beginning, but if every operator gets Richard> delegated only the numbers he is hosting, any two trees Richard> may be merged without any problem (if no transit routes Richard> are in). This can never work. Number portability means block delegations to operators will become increasingly fragmented over time. Delegations will probably have to be made for individual numbers (or perhaps an organisation's DDI block). If not, providers could use their control over the end user's DNS content for all sorts of anti-competitive practices. Like making it difficult to change the customer's delegation to another provider. FYI merging DNS trees is far from the simple exercise you seem to think it is. Read on... Richard> This leaves the question of e164.arpa itself. For Richard> Infrastructure ENUM there is no need to go into e164.arpa Richard> and wait until hell freezes over until all countries have Richard> decided eventually to opt-in. Wrong. Operators can (and probably should) use a private version of e164.arpa today. This doesn't need any involvement in the Tier-0 and Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB agreed domain name for ENUM. It's neutral and not controlled by any commercial interest or nation. So it's the obvious choice for the unique and consistent naming scheme that Infrastructure ENUM needs. There is no viable alternative. [BTW don't confuse the domain name e164.arpa with its public expression on the internet today.] This would also make it easier for operators to interwork and perhaps link their private trees: ie nobody has to figure out the DNS gunk needed to merge say enum.pulver.com with e164.at or enum.bt.intra. Richard> Sorry to say, but the same is valid for "User" ENUM. The Richard> proposal here is to set up a silver tree immediately by Richard> all interested parties, which may or may not be folded Richard> back to e164.arpa if it gets useful. Countries already Richard> having e164.arpa implemented may be copied over to the Richard> silver tree in the meantime. Richard, you should not be making statements like this. Merging trees and migrating domain names is a very, very painful process. [I know because I've done it. Have you?] Even for the most trivial of cases in controlled environments, this exercise is difficult, time-consuming and all too easy to get wrong. In an ENUM world with as little as a few hundred individually managed zones, migrating or merging them will be effectively impossible. Now scale this to say a few million delegations... For bonus points, deal with zones that have NAPTR records pointing at URIs inside the tree that's being merged. Please remember that once a domain name is registered and gets used, it lives forever in things like application software, configuration files, address books, search engine databases, web links, documents & stationery, web browser bookmarks, etc, etc. Once someone starts populating phone numbers or whatever under RichardsSilverTree.at, they're going to be pretty much stuck with that until long after hell freezes over. I sometimes still get email sent to an address I stopped using 10+ years and 5 jobs ago. This is one reason why there needs to be considerably more thought about the choice of domain name for Infrastructure ENUM. You seem to be saying that any old name can be used and moved elsewhere at some point in future with a wave of a magic wand. It's not going to be that simple. It can't be. Trust me on this. I've done fairly big domain name migrations/mergers and know just how hard this is to do. It's even harder when trying to maintain continuity of service. And harder still when you've no idea what applications are out there and what they look up or how they'll break if their favourite domain names get changed. I think we agree there must be a single, consistent name space for Infrastructure ENUM. The question then becomes one of implementation: what domain name is used and how it gets realised. This is orthogonal to what happens with the public e164.arpa name space. Please don't confuse these two things even if the same domain name happens to apply to both. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Tue, 29 Jun 2004 09:50:39 -0400 From: "Christian de Larrinaga" Date: Tue, 29 Jun 2004 09:50:39 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <1778.1088512653@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Jim you wrote. . > Operators can (and probably should) use a private version of e164.arpa today. This doesn't need any involvement in the Tier-0 and Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB agreed domain name for ENUM. It's neutral and not controlled by any commercial interest or nation. So it's the obvious choice for the unique and consistent naming scheme that Infrastructure ENUM needs. There is no viable alternative. [BTW don't confuse the domain name e164.arpa with its public expression on the internet today.] This would also make it easier for operators to interwork and perhaps link their private trees: ie nobody has to figure out the DNS gunk needed to merge say enum.pulver.com with e164.at or enum.bt.intra. cdel:--< what specifically do you propose? It sounds like you are proposing non routable private e164.arpa zones behind firewalls? and ... I think we agree there must be a single, consistent name space for Infrastructure ENUM. The question then becomes one of implementation: what domain name is used and how it gets realised. This is orthogonal to what happens with the public e164.arpa name space. Please don't confuse these two things even if the same domain name happens to apply to both. cdel:---< By infrasructure ENUM do you mean ENUM that is not e164.arpa and is established for and by operators to interoperate between each other in particular when a e164 number is not entered into the e164.arpa tree? i.e., not the operator's internal private ENUM tree nor e164.arpa but something else? i.e., in your own words of a few months ago not really ENUM but ENUM-like? Christian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 29 Jun 2004 10:06:12 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 10:06:12 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437BE@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R > Jim Reid [mailto:jim at rfc1035.com] writes: > > Sorry Richard, this is too simplistic. [Richard>] Maybe, I always thought the slogan of IETF is KISS ;-) > Your so-called silver tree > could only work ... This is not my silver tree (ask ITSPA). > On top of that I can't see how VoIP provider A would > be comfortable exposing their customer's "phone numbers" in some > private, shared tree to VoIP provider B. [Richard>] Fine. Then there will never be an OCI (operator, carrier, infrastructure) tree. But they trust the IAB?: > > Wrong. Operators can (and probably should) use a private version of > e164.arpa today. This doesn't need any involvement in the Tier-0 and > Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB > agreed domain name for ENUM. It's neutral and not controlled by any > commercial interest or nation. So it's the obvious choice for the > unique and consistent naming scheme that Infrastructure ENUM > needs. [Richard>] I do not see any difference to any other tree the operators agree upon. And the first thing is they have to agree on e164.arpa and this has to happen very quickly. > Richard> There is no problem having two trees in parallel, a > Richard> provider (or even the user himself) may query public User > Richard> ENUM first and public or private Infrastructure ENUM > Richard> afterwards. > > I don't understand this. An end user should never, ever see a private > ENUM tree. Even if querying both trees was possible, how is the user > or application supposed to know which one holds the data it's supposed > to use? If my phone number is in both places each with 1 NAPTR record > pointing at different SIP servers, which one does the application > connect to? Now suppose one of those SIP servers lives deep in some > telco's net and is unreachable from another operator's net. Or the > internet. Or vice versa. This is very simple (as the most things are I proposed) and Is used already in most Asterisk: The user itself or the SIP Server is querying user ENUM. If he finds an entry, fine. If not, instead of forwarding the call to the PSTN, it is querying OCI ENUM or whatever system the operator use to find each other (if there are still operators left. If the PSTN finally goes away, you cannot dump the call to something what is not existing, so something is needed. But this is not a technical problem, most ENUM-enabled Asterisk now query first e164.arpa and then e.g. fraenum.org. No problem. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 29 Jun 2004 10:20:46 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 10:20:46 -0400 To: "Stastny Richard" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BE@oefeg-s02.oefeg.loc> Message-ID: <1954.1088518153@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: >> Your so-called silver tree could only work ... Richard> This is not my silver tree (ask ITSPA). Well you're the first person to mention this term to me. :-) >> On top of that I can't see how VoIP provider A would be >> comfortable exposing their customer's "phone numbers" in some >> private, shared tree to VoIP provider B. Richard> Fine. Then there will never be an OCI Richard> (operator, carrier, infrastructure) tree. Richard> But they trust the IAB?: This trust issue has got nothing to do with the IAB. Or IETF. Or what the domain name is. >> Wrong. Operators can (and probably should) use a private >> version of e164.arpa today. This doesn't need any involvement >> in the Tier-0 and Tier-1 stuff or ITU's interim >> procedures. e164.arpa is the IETF/IAB agreed domain name for >> ENUM. It's neutral and not controlled by any commercial >> interest or nation. So it's the obvious choice for the unique >> and consistent naming scheme that Infrastructure ENUM needs. Richard> I do not see any difference to any other tree Richard> the operators agree upon. And the first thing is they Richard> have to agree on e164.arpa and this has to happen very Richard> quickly. Yes, agreement should be reached quickly. And if some other name is chosen for that tree, it is likely to be tainted in some way because it probably won't have come from a neutral source. I can't see Verizon (say) signing up for an Operator ENUM tree that's owned by say AT&T. Maybe IETF or ETSI could suggest a suitable domain name? IETF already have IMO. Even once the domain name is chosen, someone needs to document the DNS configuration and management processes. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Tue, 29 Jun 2004 10:52:09 -0400 From: James Seng Date: Tue, 29 Jun 2004 10:52:09 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BE@oefeg-s02.oefeg.loc> Message-ID: <40E17F79.4050502@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R it would be make sense to define goldentree, silvertree etc as i can see we going to use these term regularly in carrier ENUM. anyone wants to take a shot at this before san diego...if not, i forsee we going to have a lively debate just on the terminology. 1hr is not going to be enough. incidently, it might be worthwhile to look at the world as it exists first before thinking how we like it to be. the world right now is a world of silvertrees. james Stastny Richard wrote: Jim Reid [mailto:jim at rfc1035.com] writes: Sorry Richard, this is too simplistic. [Richard>] Maybe, I always thought the slogan of IETF is KISS ;-) Your so-called silver tree could only work ... This is not my silver tree (ask ITSPA). On top of that I can't see how VoIP provider A would be comfortable exposing their customer's "phone numbers" in some private, shared tree to VoIP provider B. [Richard>] Fine. Then there will never be an OCI (operator, carrier, infrastructure) tree. But they trust the IAB?: Wrong. Operators can (and probably should) use a private version of e164.arpa today. This doesn't need any involvement in the Tier-0 and Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB agreed domain name for ENUM. It's neutral and not controlled by any commercial interest or nation. So it's the obvious choice for the unique and consistent naming scheme that Infrastructure ENUM needs. [Richard>] I do not see any difference to any other tree the operators agree upon. And the first thing is they have to agree on e164.arpa and this has to happen very quickly. Richard> There is no problem having two trees in parallel, a Richard> provider (or even the user himself) may query public User Richard> ENUM first and public or private Infrastructure ENUM Richard> afterwards. I don't understand this. An end user should never, ever see a private ENUM tree. Even if querying both trees was possible, how is the user or application supposed to know which one holds the data it's supposed to use? If my phone number is in both places each with 1 NAPTR record pointing at different SIP servers, which one does the application connect to? Now suppose one of those SIP servers lives deep in some telco's net and is unreachable from another operator's net. Or the internet. Or vice versa. This is very simple (as the most things are I proposed) and Is used already in most Asterisk: The user itself or the SIP Server is querying user ENUM. If he finds an entry, fine. If not, instead of forwarding the call to the PSTN, it is querying OCI ENUM or whatever system the operator use to find each other (if there are still operators left. If the PSTN finally goes away, you cannot dump the call to something what is not existing, so something is needed. But this is not a technical problem, most ENUM-enabled Asterisk now query first e164.arpa and then e.g. fraenum.org. No problem. 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 Richard.Stastny@oefeg.at Tue, 29 Jun 2004 12:20:55 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 12:20:55 -0400 To: "James Seng" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437BF@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R James Seng [mailto:jseng at pobox.org.sg] wrote: > > it would be make sense to define goldentree, silvertree etc as i can see > we going to use these term regularly in carrier ENUM. anyone wants to > take a shot at this before san diego...if not, i forsee we going to have > a lively debate just on the terminology. 1hr is not going to be enough. > > incidently, it might be worthwhile to look at the world as it exists > first before thinking how we like it to be. the world right now is a > world of silvertrees. [Richard>] No, not really, there can only be one (or two) silvertrees, but many bronze trees I am somewhat reluctant to define the terms, because immediately somebody will come up (afterwards) and state that these definitions are wrong, or he disagrees and BW what about privacy. Nevertheless, I will try ;-) ENUM: as defined in RFC3761, implemented in e164.arpa, publicly accessible, NAPTRs must be retrieveable, ditto URIs, although the services pointed to by may not be accessible by anybody (see RFC3764). "User" ENUM = synonym for ENUM (used to distinguish between other types of ENUM. Golden tree: in ENUM = e164.arpa In other types of ENUM: a shared tree agreed upon by all operators Silver tree: a tree used as temporarily replacement for e164.arpa with the intention to move the whole tree over to e164.arpa if it is available for every E.164 number. One could also call this parking tree. Note: if not every E.164 number will be finally in e164.arpa, there is a possibility that the silver tree will be around forever. Since all operators may create their golden tree wherever they want, there is no need there for a silver tree. What may happen is maybe is wood of bronze trees ;-) The only silver tree I could imagine here is that everybody agrees on one tree, but there is no possibility to have this tree immediately in .arpa, so a parking silver tree may be useful. Other types of ENUM: First, there is no distinction between Operator, Carrier or Infrastructure (OCI) "ENUM", One may use each of this terms. But there is a distinction between: Private OCI ENUM: Private OCI ENUM is a tree set-up by a single operator or network provider within his network. He may choose any TLD for this tree, even not existing ones, but he may also choose to use the same tree as Shared OCI ENUM or even e164.arpa This may come in handy if they decide to use split DNS, providing different date inside and outside Shared OCI ENUM: Is a tree set-up by a confederation of operators. It is the choice of the confederation if this tree is private again (e.g. in an extranet), public, in which tree, and if the data in the tree is accessible. Only if the tree is public and accessible, they need to obey privacy For more information on the different options in Infrastucture (OCI) ENUM (although not complete yet and still a mess) see the latest ETSI draft on Infrastructure ENUM http://enum.nic.at/documents/ETSI/Drafts/0009-TD06r2%20Draft%20ts-102055%20200407%20London%20plus%20Paul.doc regards Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Tue, 29 Jun 2004 12:21:24 -0400 From: "Peter Williams" Date: Tue, 29 Jun 2004 12:21:24 -0400 To: jim at rfc1035.com Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R you wrote. . > Operators can (and probably should) use a private version of e164.arpa today. This doesn't need any involvement in the Tier-0 and Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB agreed domain name for ENUM. It's neutral and not controlled by any commercial interest or nation. So it's the obvious choice for the unique and consistent naming scheme that Infrastructure ENUM needs. There is no viable alternative. [BTW don't confuse the domain name e164.arpa with its public expression on the internet today.] This would also make it easier for operators to interwork and perhaps link their private trees: ie nobody has to figure out the DNS gunk needed to merge say enum.pulver.com with e164.at or enum.bt.intra. cdel:--< what specifically do you propose? It sounds like you are proposing non routable private e164.arpa zones behind firewalls? not firewalls: SSL VPNs... (which also give you the security negotiation, the single signon, and the layer-independent privacy handling) Adding ENUM discovery to SSL single signon makes a lot of sense, when the SSL layer is tuned for setting up the SIP proxys' sessions. The E.164 address can also be added to the SAML, which when signed and issued by authorities can implement the semantics of the national authorities that Richard seeks to preserve (who knows why some people wish to preserve dinosaurs). But as you imply, behind every VPN there is a private DNS. Inter-VPN routing can allow references to the DNS access points of some of the other providers in the n confederations. Jim's idea is use e164.arpa as a name, not as a zone administration point.If I go one step further, in the SSL world, we just have each SSL VPN issue a self-signed cert, asserting a binding between this .arpa name and the local tunnel endpoinf to the DNS server reachable to the community using the particular SSL-net interface. Dump DNS zone delegation, and use VPN management system mechanism, instead - and use the SSL culture to handle the politics of confederated naming (given SSL management works on an critical infrastructure scale). _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 29 Jun 2004 12:34:12 -0400 From: Mike Hammer Date: Tue, 29 Jun 2004 12:34:12 -0400 To: "Stastny Richard" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BC@oefeg-s02.oefeg.loc > Message-ID: <4.3.2.7.2.20040629113450.00b08b10@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, The discussion below triggered some (possibly related) thoughts: "NATs are evil!" Let's not recreate the issues that occurred with IP layer addressing, where public and private addressing spaces create problems. "Those who do not learn from history are condemned to repeat it." George Santyana KISS: Keep It Simple and Stupid (or to follow Occam's Razor: the simpler solution will be the better one) E.164 numbers are used for routing and it works globally because it is one coherent system. If you look at the Number Portability system, it is coordinated and consistent. There is no discussion of golden versus silver NP trees. The fact that some of these numbers are migrating to the IP domain should not change that characteristic. The reason E.164 numbers work is that a call can be routed to a switch where it can be determined that the number terminates at a terminal or it is unassigned. The ability to make that determination should either reside in the ENUM system or at the "switch/host" that ENUM points to (just like in NP). One of the consequences of pushing intelligence to the edge is that the edge devices have to take on the responsibilities that come with doing that. If the end-host want to be the switch (call controller), then it needs to handle all that being a "switch" entails. If not, it needs to hide behind a service provider device that is willing to step up to those responsibilities. Once an address is translated from an ENUM E.164 number to another address type, such as a sip: URI, then the ENUM work is done. Everything after that is a normal DNS process, or in the case of routing a SIP INVITE to that sip: URI, if further translation of one sip address to another is needed, that is a SIP process, no longer an ENUM concern. My forward-looking assumption is that service providers in the IP domain, will eventually want to base their network design and dependencies on the URI addressing schemes, not necessarily the E.164 addressing. (Remember when mail addresses were assigned numbers?) ENUM will work best if it does not try to solve all the problems that really belong solely to the pure non-E.164 IP domain technologies. Then again, my head may still be ringing from the concert I attended last night, and I will come to my senses before too long, and see that this complexity is somehow necessary and desirable. Mike At 10:20 AM 6/29/2004 +0200, Stastny Richard wrote: > There is no technical reason why 'public' > ENUM cannot be applied to this problem (I am purposely using 'public' and > ignoring the artificial and loosely defined concepts of 'user' and > 'carrier' > ENUM - everyone has their own understanding of each it seems). Hi Jason, Sorry for the somewhat delayed answer, I was busy. I think you made a very good point, but there may be a distinction between 'publi'! and 'private'. Let's try an analysis of the ENUM 'market' and the 'customers'. Historically ENUM started with the following idea: 1. A subscriber has already an E.164 number on the PSTN (this was the only way to get an ENUM entry), and he may now decide on his own to request an entry in ENUM (opt-in), given his country has also decided to opt-in. He may now place URI's in his ENUM entry, pointing in principle to whatever a URI may point to, e.g. a sip or mailto URI. Where he gets the URI from in the first place was his own business. This was not a good business model, because it was to complicated, confusing to have two terminations, one on the PSTN and one on the Internet, and finally after three years nobody is able to get a delegation in any country anyway. So only some freaks used it. There was only one potential business: linking IP PBX together: In this case you could reach the same extension from the PSTN and from the Internet, so from a end-user point the same device rings. The user may also just dial a number and the IP PBX checks ENUM First and if nothing is found, it dumps the call to the PSTN. If the company knows that some other companies they are dealing with are also in ENUM, they may save substantial money. Note: this may now also be an option again for residential subscribers considering the new ATA's with FXO-ports (e.g. the SPA-3000, Azatel, etc) 2. Where did the above mentioned freaks get the SIP URI's from? >From "providers" like FWD, sipphone, iptel, or DYI. Now these providers all had numeric userID. Why? Because it is easier to dial them on IP Phones and especially ATAs. These providers now started to link each other together using "cross trunking" access codes, but also some of them wanted to implement ENUM. This is useful, but where to get numbers from. What they needed where numbers NOT yet existing on the PSTN, so no opt-in is required. Some countries considered to open special number ranges for this purpose, but again these numbers are not available really, and if, they will be non-geographic numbers The above mentioned providers in most cases had no (direct) interworking with the PSTN. 3. Some providers started to interwork with the PSTN and here it showed clearly that customer primarily wanted local geographic numbers. Period. These numbers differ from the above mentioned opt-in scheme in 1. that they really terminate on IP, either single numbers ported out or whole number ranges. If these providers want to link each other via ENUM, ALL numbers must be in ENUM, so we have now a clash with the original opt-in model. This problem may still be solved insofar that a user may opt-in with a PSTN line on his own, but with a VoIP service automatically by his provider (e.g. he agrees that his number will be in ENUM (privacy provided) if he is using this service). There are even ways to accommodate both in one tree. Note: one basic attribute of all these options is that the user has in addition to his E.164 number a public URI assigned. He may be reached via this URI regardless of ENUM. So if a calling user knows the URI, he may reach the called party in any case. Or in other words, ENUM is opt-in for the CALLING User also. Sofar the story of public "User" ENUM in e164.arpa. The major problem of e164.arpa is that it is simply not available, so one may get the idea to set up the same principle just in another tree (temporarily?) (silver tree), so every operator may join with his number ranges. 4. Now we have other customers for "ENUM" in addition. Any provider using VoIP internally in his network (e.g YahooBB!, Comcast, etc.) is currently interconnecting via the PSTN. Logically both the providers and the users may benefit if these operators would interconnect via IP. The big difference between these providers and the above mentioned three options is that the subscribers of these operators DO NOT GET AN URI (at least not a public reachable one). There are many reason for this, e.g. the providers do not want to make the internals of there networks public, privacy again (because ALL numbers of an operator needs to be in), but the major reason is: if you make a URI public, you also need to agree on zero-termination. There will also be a clash with already opted-in users. This tree may finally be the authoritative NP tree pointing for each E.164 number to the provider hosting it and MUST be able to do this even if the PSTN ceases to exist. 5. I just want to add one option for completeness: some providers want also to announce not only the numbers they host, but also the number they may make available on the PSTN via their gateways. ENUM is not designed for this, one should use TRIP or OSP for this purpose. I currently do not see a possibility to get all requirements for all 4 options workable in one tree. I also do not see any advantage for option 4 candidates to go for e164.arpa, because they need a solution NOW and they may do this in any tree (public or private) (see also ETSI draft TS 102 055) So I see two possibilities for User and Infrastructure ENUM are: 1. Find a way to implement everything in one tree (which I consider not possible, but I am open for proposals) 2. Make two trees, one for above option 1.-3. and another one for option 4. There is no problem having two trees in parallel, a provider (or even the user himself) may query public User ENUM first and public or private Infrastructure ENUM afterwards. Talking about two trees, of course there will be more trees at the beginning, but if every operator gets delegated only the numbers he is hosting, any two trees may be merged without any problem (if no transit routes are in). This leaves the question of e164.arpa itself. For Infrastructure ENUM there is no need to go into e164.arpa and wait until hell freezes over until all countries have decided eventually to opt-in. Sorry to say, but the same is valid for "User" ENUM. The proposal here is to set up a silver tree immediately by all interested parties, which may or may not be folded back to e164.arpa if it gets useful. Countries already having e164.arpa implemented may be copied over to the silver tree in the meantime. Best regards Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > Sent: Friday, June 25, 2004 5:16 PM > To: 'Fullbrook Kim (UK)'; 'enum at ietf.org' > Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > Kim wrote: > > > The intent of the ENUM DNS (from RFC 2916) is that it can be "used for > identifying > > available services connected to one E.164 number" giving examples of > re-directs, email > > > address and web page. > > Someone can wardial the DNS using E.164 numbers to get back a list of > SIP > URIs and > > potentially other information such as email addresses. My definition of > a > phone book > > obtained by this means is a list of valid SIP URIs which contain some > user-specific > > information. > > I agree that this is possible, which begs the question of *why* a rational > person would choose to register a number in ENUM and request with their SP > that service addresses (email addr, IM ID, mobile #, etc.) be associated > with their E.164 number? > > The only use case I can reasonably imagine is one for businesses, whereby > 1-800-COMPANY is associated in ENUM with a variety addresses for that > company (www.company.com, support at company.com, etc.). These are entities > which want to share as much contact information as possible, compared to > consumers which generally wish to share as little as possible. This > business use is perhaps not a sufficient justification for investment in > ENUM infrastructure in various countries (unless establishing a working > business model is a thing of the past - but I think the bubble days are > gone). > > What we seem to have, however, is a massive new market for VoIP services > that would find ENUM to be a very helpful solution to enable softswitches > (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions. > The > ultimate goal for these providers is to route calls over IP networks, > without touching the PSTN (and therefore incurring various charges > according > to the PSTN regulatory regime). There is no technical reason why 'public' > ENUM cannot be applied to this problem (I am purposely using 'public' and > ignoring the artificial and loosely defined concepts of 'user' and > 'carrier' > ENUM - everyone has their own understanding of each it seems). > > Going back to Steve Lind's question of (paraphrasing) what problem the > IETF > is trying to solve, I still don't see an answer. IMHO, ENUM can be used > by > Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, CLECs, > IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is for > describing voice). It will be impossible to solve some constantly- > shifting > debate about 'privacy' in ENUM since no one seems to be able to agree on > what privacy is (which is quite natural). > > However, privacy can be more readily defined and agreed upon at the > national > level, which is how the public ENUM delegations occur. Each country is > likely to have different ways of viewing personal information and privacy, > and have different laws, rules, and regulations to this effect. Within > countries, different providers may be treated differently and have > different > standards to meet for notifying or seeking the consent of customers of > the > entry of their TN into ENUM (such as a highly regulated traditional telco > vs. an unregulated ISP). So it appears to me, at least, that privacy > issues > are best addressed locally, in each country. And if that is the case, > what > is the point of much of the discussion on this list in the past several > weeks? What is the technical problem at hand? > > Jason Livingood > > > > > > > > > _______________________________________________ > 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 Tue, 29 Jun 2004 12:45:23 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 12:45:23 -0400 To: "Mike Hammer" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437C0@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, I agree what you said below, but there a some minor caveats: -Most "network" operators are still dreaming of NATs, Session Border Controller, etc. you name it. -regarding golden NP databases: you live in a country with a centralized NP databases, there a many countries (including my own) where very operator is running his own (private) NP database. - I also agree with end-to-end and that the final routing method on IP is DNS and URI, but then URIs need to be routable and public. Exactly that is what some "network" operators do not want. -These operators are also dreaming of termination charges for incoming calls to their network. If I ask them if I get charged (maybe also on distance) accessing a webpage, I earn a blank stare. I think many people from telco (NGN) land still need a learning phase how the Internet works. Richard > -----Original Message----- > From: Mike Hammer [mailto:mhammer at cisco.com] > Sent: Tuesday, June 29, 2004 6:23 PM > To: Stastny Richard; Livingood, Jason; enum at ietf.org > Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > Richard, > > The discussion below triggered some (possibly related) thoughts: > > "NATs are evil!" Let's not recreate the issues that occurred with IP > layer > addressing, where public and private addressing spaces create problems. > > "Those who do not learn from history are condemned to repeat it." George > Santyana > > KISS: Keep It Simple and Stupid (or to follow Occam's Razor: the simpler > solution will be the better one) > > E.164 numbers are used for routing and it works globally because it is one > coherent system. If you look at the Number Portability system, it is > coordinated and consistent. There is no discussion of golden versus > silver > NP trees. The fact that some of these numbers are migrating to the IP > domain should not change that characteristic. > > The reason E.164 numbers work is that a call can be routed to a switch > where it can be determined that the number terminates at a terminal or it > is unassigned. The ability to make that determination should either > reside > in the ENUM system or at the "switch/host" that ENUM points to (just like > in NP). > > One of the consequences of pushing intelligence to the edge is that the > edge devices have to take on the responsibilities that come with doing > that. If the end-host want to be the switch (call controller), then it > needs to handle all that being a "switch" entails. If not, it needs to > hide behind a service provider device that is willing to step up to those > responsibilities. > > Once an address is translated from an ENUM E.164 number to another address > type, such as a sip: URI, then the ENUM work is done. Everything after > that is a normal DNS process, or in the case of routing a SIP INVITE to > that sip: URI, if further translation of one sip address to another is > needed, that is a SIP process, no longer an ENUM concern. > > My forward-looking assumption is that service providers in the IP domain, > will eventually want to base their network design and dependencies on the > URI addressing schemes, not necessarily the E.164 addressing. (Remember > when mail addresses were assigned numbers?) ENUM will work best if it > does > not try to solve all the problems that really belong solely to the pure > non-E.164 IP domain technologies. > > Then again, my head may still be ringing from the concert I attended last > night, and I will come to my senses before too long, and see that this > complexity is somehow necessary and desirable. > > Mike > > > At 10:20 AM 6/29/2004 +0200, Stastny Richard wrote: > > > There is no technical reason why 'public' > > > ENUM cannot be applied to this problem (I am purposely using 'public' > and > > > ignoring the artificial and loosely defined concepts of 'user' and > > > 'carrier' > > > ENUM - everyone has their own understanding of each it seems). > > > >Hi Jason, > > > >Sorry for the somewhat delayed answer, I was busy. > >I think you made a very good point, but there may be a distinction > >between 'publi'! and 'private'. > > > >Let's try an analysis of the ENUM 'market' and the 'customers'. > > > >Historically ENUM started with the following idea: > >1. A subscriber has already an E.164 number on the PSTN > >(this was the only way to get an ENUM entry), > >and he may now decide on his own to request an > >entry in ENUM (opt-in), given his country has > >also decided to opt-in. > > > >He may now place URI's in his ENUM entry, pointing in principle > >to whatever a URI may point to, e.g. a sip or mailto URI. > > > >Where he gets the URI from in the first place was his own business. > > > >This was not a good business model, because it was to complicated, > >confusing to have two terminations, one on the PSTN and one on > >the Internet, and finally after three years nobody is able to > >get a delegation in any country anyway. So only some freaks > >used it. > > > >There was only one potential business: linking IP PBX together: > >In this case you could reach the same extension from the PSTN and > >from the Internet, so from a end-user point the same device rings. > >The user may also just dial a number and the IP PBX checks ENUM > >First and if nothing is found, it dumps the call to the PSTN. > >If the company knows that some other companies they are dealing > >with are also in ENUM, they may save substantial money. > > > >Note: this may now also be an option again for residential subscribers > >considering the new ATA's with FXO-ports (e.g. the SPA-3000, Azatel, etc) > > > >2. Where did the above mentioned freaks get the SIP URI's from? > > >From "providers" like FWD, sipphone, iptel, or DYI. > >Now these providers all had numeric userID. Why? Because it > >is easier to dial them on IP Phones and especially ATAs. > >These providers now started to link each other together using > >"cross trunking" access codes, but also some of them wanted to implement > >ENUM. This is useful, but where to get numbers from. What they needed > >where numbers NOT yet existing on the PSTN, so no opt-in is required. > >Some countries considered to open special number ranges for this > >purpose, but again these numbers are not available really, > >and if, they will be non-geographic numbers > >The above mentioned providers in most cases had no (direct) > >interworking with the PSTN. > > > >3. Some providers started to interwork with the PSTN and here > >it showed clearly that customer primarily wanted local geographic > >numbers. Period. These numbers differ from the above mentioned opt-in > >scheme in 1. that they really terminate on IP, either single numbers > >ported out or whole number ranges. If these providers want to link > >each other via ENUM, ALL numbers must be in ENUM, so we have now > >a clash with the original opt-in model. This problem may still be > >solved insofar that a user may opt-in with a PSTN line on his > >own, but with a VoIP service automatically by his provider (e.g. > >he agrees that his number will be in ENUM (privacy provided) if > >he is using this service). There are even ways to accommodate > >both in one tree. > > > >Note: one basic attribute of all these options is that the user > >has in addition to his E.164 number a public URI assigned. He may > >be reached via this URI regardless of ENUM. So if a calling > >user knows the URI, he may reach the called party in any case. > > > >Or in other words, ENUM is opt-in for the CALLING User also. > > > >Sofar the story of public "User" ENUM in e164.arpa. The major > >problem of e164.arpa is that it is simply not available, so one > >may get the idea to set up the same principle just in another > >tree (temporarily?) (silver tree), so every operator may join > >with his number ranges. > > > >4. Now we have other customers for "ENUM" in addition. Any provider > >using VoIP internally in his network (e.g YahooBB!, Comcast, etc.) > >is currently interconnecting via the PSTN. Logically both the > >providers and the users may benefit if these operators would > >interconnect via IP. The big difference between these providers > >and the above mentioned three options is that the subscribers > >of these operators DO NOT GET AN URI (at least not a public reachable > >one). There are many reason for this, e.g. the providers do not > >want to make the internals of there networks public, privacy again > >(because ALL numbers of an operator needs to be in), > >but the major reason is: if you make a URI public, you also need > >to agree on zero-termination. There will also be a clash with > >already opted-in users. > >This tree may finally be the authoritative NP tree pointing > >for each E.164 number to the provider hosting it and MUST be able > >to do this even if the PSTN ceases to exist. > > > >5. I just want to add one option for completeness: some providers > >want also to announce not only the numbers they host, but also the > >number they may make available on the PSTN via their gateways. ENUM > >is not designed for this, one should use TRIP or OSP for this purpose. > > > > > >I currently do not see a possibility to get all requirements > >for all 4 options workable in one tree. I also do not see > >any advantage for option 4 candidates to go for e164.arpa, > >because they need a solution NOW and they may do this in any > >tree (public or private) (see also ETSI draft TS 102 055) > > > >So I see two possibilities for User and Infrastructure ENUM are: > > > >1. Find a way to implement everything in one tree > >(which I consider not possible, but I am open for proposals) > > > >2. Make two trees, one for above option 1.-3. and another > >one for option 4. > > > >There is no problem having two trees in parallel, a provider > >(or even the user himself) may query public User ENUM first > >and public or private Infrastructure ENUM afterwards. > > > >Talking about two trees, of course there will be more trees at > >the beginning, but if every operator gets delegated only > >the numbers he is hosting, any two trees may be merged without > >any problem (if no transit routes are in). > > > >This leaves the question of e164.arpa itself. For Infrastructure > >ENUM there is no need to go into e164.arpa and wait until hell freezes > >over until all countries have decided eventually to opt-in. > > > >Sorry to say, but the same is valid for "User" ENUM. The proposal > >here is to set up a silver tree immediately by all interested parties, > >which may or may not be folded back to e164.arpa if it gets useful. > >Countries already having e164.arpa implemented may be copied over > >to the silver tree in the meantime. > > > > > >Best regards > >Richard > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > > > Sent: Friday, June 25, 2004 5:16 PM > > > To: 'Fullbrook Kim (UK)'; 'enum at ietf.org' > > > Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > > > > > Kim wrote: > > > > > > > The intent of the ENUM DNS (from RFC 2916) is that it can be "used > for > > > identifying > > > > available services connected to one E.164 number" giving examples of > > > re-directs, email > > > > > address and web page. > > > > Someone can wardial the DNS using E.164 numbers to get back a list > of > > > SIP > > > URIs and > > > > potentially other information such as email addresses. My definition > of > > > a > > > phone book > > > > obtained by this means is a list of valid SIP URIs which contain > some > > > user-specific > > > > information. > > > > > > I agree that this is possible, which begs the question of *why* a > rational > > > person would choose to register a number in ENUM and request with > their SP > > > that service addresses (email addr, IM ID, mobile #, etc.) be > associated > > > with their E.164 number? > > > > > > The only use case I can reasonably imagine is one for businesses, > whereby > > > 1-800-COMPANY is associated in ENUM with a variety addresses for that > > > company (www.company.com, support at company.com, etc.). These are > entities > > > which want to share as much contact information as possible, compared > to > > > consumers which generally wish to share as little as possible. This > > > business use is perhaps not a sufficient justification for investment > in > > > ENUM infrastructure in various countries (unless establishing a > working > > > business model is a thing of the past - but I think the bubble days > are > > > gone). > > > > > > What we seem to have, however, is a massive new market for VoIP > services > > > that would find ENUM to be a very helpful solution to enable > softswitches > > > (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions. > > > The > > > ultimate goal for these providers is to route calls over IP networks, > > > without touching the PSTN (and therefore incurring various charges > > > according > > > to the PSTN regulatory regime). There is no technical reason why > 'public' > > > ENUM cannot be applied to this problem (I am purposely using 'public' > and > > > ignoring the artificial and loosely defined concepts of 'user' and > > > 'carrier' > > > ENUM - everyone has their own understanding of each it seems). > > > > > > Going back to Steve Lind's question of (paraphrasing) what problem the > > > IETF > > > is trying to solve, I still don't see an answer. IMHO, ENUM can be > used > > > by > > > Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, > CLECs, > > > IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is > for > > > describing voice). It will be impossible to solve some constantly- > > > shifting > > > debate about 'privacy' in ENUM since no one seems to be able to agree > on > > > what privacy is (which is quite natural). > > > > > > However, privacy can be more readily defined and agreed upon at the > > > national > > > level, which is how the public ENUM delegations occur. Each country > is > > > likely to have different ways of viewing personal information and > privacy, > > > and have different laws, rules, and regulations to this effect. > Within > > > countries, different providers may be treated differently and have > > > different > > > standards to meet for notifying or seeking the consent of customers > of > > > the > > > entry of their TN into ENUM (such as a highly regulated traditional > telco > > > vs. an unregulated ISP). So it appears to me, at least, that privacy > > > issues > > > are best addressed locally, in each country. And if that is the case, > > > what > > > is the point of much of the discussion on this list in the past > several > > > weeks? What is the technical problem at hand? > > > > > > Jason Livingood > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Tue, 29 Jun 2004 12:59:11 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 12:59:11 -0400 To: cdel at firsthand.net Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <2373.1088527733@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Christian" == Christian de Larrinaga writes: Christian> cdel:--< what specifically do you propose? It sounds Christian> like you are proposing non routable private e164.arpa Christian> zones behind firewalls? In simple terms, yes. Sort of. Each operator has their own e164.arpa tree which is private to them and used for internal purposes like call routing. These trees won't need any opt-in principle as they could be used for all numbers served by the operator, including unlisted ones. Some operators may want to share or link their private trees, for example in some sort of joint venture. This is one reason why these trees should be anchored under a single domain name. Christian> cdel:---< By infrasructure ENUM do you mean ENUM that Christian> is not e164.arpa and is established for and by Christian> operators to interoperate between each other in Christian> particular when a e164 number is not entered into the Christian> e164.arpa tree? i.e., not the operator's internal Christian> private ENUM tree nor e164.arpa but something else? No. ENUM is when an E.164 number is entered under e164.arpa according to RFC3761. Infrastructure ENUM is when an operator populates their private e164.arpa tree and uses the data there for internal purposes such as call routing. End users will have no access to this tree or direct control over what's stored there. Operators might or might not choose to expose these private trees to each other. E.164 numbers entered under any domain name other than e164.arpa don't comply with my understanding of ENUM: ie RFC3761. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 29 Jun 2004 13:12:47 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 13:12:47 -0400 To: "Peter Williams" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <2411.1088528462@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Peter" == Peter Williams writes: Peter> Jim's idea is use e164.arpa as a name, not as a zone Peter> administration point. EXACTLY!!! Thanks for saying this more clearly than I could! :-) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 29 Jun 2004 13:15:04 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 13:15:04 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1622B0673@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid wrote: > These trees won't need any opt-in principle as they could be > used for all numbers served by the operator, including unlisted ones. [Richard>] So I can reach unlisted numbers only from within the same operator? Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 29 Jun 2004 13:35:52 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 13:35:52 -0400 To: "Stastny Richard" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1622B0673@oefeg-s02.oefeg.loc> Message-ID: <2483.1088530014@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "richard" == Stastny Richard writes: >> These trees won't need any opt-in principle as they could be >> used for all numbers served by the operator, including unlisted >> ones. richard> So I can reach unlisted numbers only from richard> within the same operator? Depends on the operator, what they choose to make available to other operators and how it's made available. Suppose +10123456789 is an unlisted number living in a block belonging to TelcoA. TelcoB is in Austria. They have a private ENUM tree that points all +1 numbers at a SIP server in TelcoC's net in the USA. TelcoC knows that block 0123456 belongs to TelcoA. TelcoC's private tree points calls begining with this prefix at a SIP server in TelcoA's network which can then terminate the call by making the phone on +10123456789 ring. There's lots of hand-waving going on here, but you get the general idea. And of course if there's a shared operator ENUM tree, routing the call gets a whole lot simpler. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Tue, 29 Jun 2004 13:44:26 -0400 From: "Christian de Larrinaga" Date: Tue, 29 Jun 2004 13:44:26 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <2373.1088527733@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: 29 June 2004 17:49 To: cdel at firsthand.net Cc: Stastny Richard; enum at ietf.org Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) >>>>> "Christian" == Christian de Larrinaga writes: Christian> cdel:--< what specifically do you propose? It sounds Christian> like you are proposing non routable private e164.arpa Christian> zones behind firewalls? In simple terms, yes. Sort of. Each operator has their own e164.arpa tree which is private to them and used for internal purposes like call routing. These trees won't need any opt-in principle as they could be used for all numbers served by the operator, including unlisted ones. Some operators may want to share or link their private trees, for example in some sort of joint venture. This is one reason why these trees should be anchored under a single domain name. christian:-> just so I've got this straight! You propose we use the name of the domain e164.arpa (ONLY) by all operators on their private DNS (for infrastructure use and some intra-operator connections) as well as e164.arpa for public (for public open delegations)? i.e., rather than setup a separate domain name by operators such as e164.operator.foo all ENUM is handled in e164.arpa public and private trees. And then to rely on the network configuration around that DNS to route ENUM lookups to the appropriate DNS server whether public or private (infrastructure)? This suggests to me that you might get different answers to an ENUM (e164.arpa) look up depending on where you are? How do you ensure that public e164.arpa has first priority so that users public ENUM NAPTR records take precedence over operator (private ENUM)? Christian> cdel:---< By infrasructure ENUM do you mean ENUM that Christian> is not e164.arpa and is established for and by Christian> operators to interoperate between each other in Christian> particular when a e164 number is not entered into the Christian> e164.arpa tree? i.e., not the operator's internal Christian> private ENUM tree nor e164.arpa but something else? No. ENUM is when an E.164 number is entered under e164.arpa according to RFC3761. Infrastructure ENUM is when an operator populates their private e164.arpa tree and uses the data there for internal purposes such as call routing. End users will have no access to this tree or direct control over what's stored there. Operators might or might not choose to expose these private trees to each other. E.164 numbers entered under any domain name other than e164.arpa don't comply with my understanding of ENUM: ie RFC3761. cdel:--> a point well made :-) Christian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Tue, 29 Jun 2004 14:00:54 -0400 From: "Christian de Larrinaga" Date: Tue, 29 Jun 2004 14:00:54 -0400 To: "Peter Williams" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Peter Williams Sent: 29 June 2004 17:14 >cdel:--< what specifically do you propose? It sounds like you are proposing >non routable private e164.arpa zones behind firewalls? not firewalls: SSL VPNs... (which also give you the security negotiation, the single signon, and the layer-independent privacy handling) Adding ENUM discovery to SSL single signon makes a lot of sense, when the SSL layer is tuned for setting up the SIP proxys' sessions. The E.164 address can also be added to the SAML, which when signed and issued by authorities can implement the semantics of the national authorities that Richard seeks to preserve (who knows why some people wish to preserve dinosaurs). But as you imply, behind every VPN there is a private DNS. Inter-VPN routing can allow references to the DNS access points of some of the other providers in the n confederations. Jim's idea is use e164.arpa as a name, not as a zone administration point.If I go one step further, in the SSL world, we just have each SSL VPN issue a self-signed cert, asserting a binding between this .arpa name and the local tunnel endpoinf to the DNS server reachable to the community using the particular SSL-net interface. Dump DNS zone delegation, and use VPN management system mechanism, instead - and use the SSL culture to handle the politics of confederated naming (given SSL management works on an critical infrastructure scale). christian :--> Thanks for the clear presentation of this idea. But does it matter if it is SSL or IPSEC with or without BGP4 policy? i.e., would it be better to allow user to define network architecture rather than imposing SSL only for ENUM use as a one size fits all? Or have I misunderstood you? Christian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 29 Jun 2004 14:27:27 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 14:27:27 -0400 To: cdel at firsthand.net Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <2647.1088533299@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Christian" == Christian de Larrinaga writes: Christian> just so I've got this straight! You Christian> propose we use the name of the domain e164.arpa (ONLY) Christian> by all operators on their private DNS (for Christian> infrastructure use and some intra-operator connections) Christian> as well as e164.arpa for public (for public open Christian> delegations)? Yes. Christian> i.e., rather than setup a separate domain name by Christian> operators such as e164.operator.foo all ENUM is handled Christian> in e164.arpa public and private trees. Yes. ENUM => e164.arpa. Always. Anywhere else isn't ENUM. Christian> And then to rely on the network configuration around Christian> that DNS to route ENUM lookups to the appropriate DNS Christian> server whether public or private (infrastructure)? Yes. Christian> This suggests to me that you might get different Christian> answers to an ENUM (e164.arpa) look up depending on Christian> where you are? Yes. Christian> How do you ensure that public e164.arpa has first Christian> priority so that users public ENUM NAPTR records take Christian> precedence over operator (private ENUM)? You don't: that's a policy decision and implementation detail. And anyway who's to say whether the public or private tree takes precedence? Or even if precedence is appropriate? If my application is in some operator's net, it looks up .e164.arpa in their private tree and the answer determines what the application does. Likewise if it's on the internet, the application will query the public e164.arpa tree and uses that answer. ie Where the application lives determines what name space it gets to see and what answer the application gets *for the same query*. This is no different from how most big organisations do DNS today. If something's on the corporate intranet, they see the internal name space for example.com, complete with internal-only reachable web sites, mail servers and so on. When something's on the internet, they see the public face of example.com. That may or may not be very different from the internal name space. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 29 Jun 2004 14:29:55 -0400 From: Mike Hammer Date: Tue, 29 Jun 2004 14:29:55 -0400 To: Jim Reid Message-ID: <4.3.2.7.2.20040629133129.03afd2c0@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, A test of the adequacy of the system you propose should be the ability of a call to an E.164 number from any random entry point into the IP domain (e.g. from any -- confederated or not -- service provider's gateway) MUST be able to be completed, except where unassigned, out of service, or protected by a subscriber feature. Rather than relying on "joint ventures" to "share or link their private trees" (at which point privacy issues may arise) wouldn't it be better for the public ENUM to provide that linkage? If I understand correctly this could be a 3-stage process: 1) PSTN call causes NP dip and resolves to an IP-domain indication Local database determines TDM routing to IP Gateway PSTN call routed to nearest IP Gateway (optional if call originates in IP) 2) Public ENUM search resolves to Service Provider (SP) URI address DNS search gives corresponding IP address IP setup message routed to SP (SP is public operator/carrier, enterprise, or opt-in end-user) 3) Private "ENUM" search (on local part of URI) resolves to Subscriber URI address DNS search gives corresponding IP address IP setup message sent to Subscriber (optional if SP was end-user; subscriber is operator/carrier customer or enterprise end-point) I assume there will still be haggling over the design of the public ENUM, but at least it could be one complete, consistent, regulated, equal-access, market-neutral tree. Mike At 05:48 PM 6/29/2004 +0100, Jim Reid wrote: >>>>> "Christian" == Christian de Larrinaga writes: Christian> cdel:--< what specifically do you propose? It sounds Christian> like you are proposing non routable private e164.arpa Christian> zones behind firewalls? In simple terms, yes. Sort of. Each operator has their own e164.arpa tree which is private to them and used for internal purposes like call routing. These trees won't need any opt-in principle as they could be used for all numbers served by the operator, including unlisted ones. Some operators may want to share or link their private trees, for example in some sort of joint venture. This is one reason why these trees should be anchored under a single domain name. Christian> cdel:---< By infrasructure ENUM do you mean ENUM that Christian> is not e164.arpa and is established for and by Christian> operators to interoperate between each other in Christian> particular when a e164 number is not entered into the Christian> e164.arpa tree? i.e., not the operator's internal Christian> private ENUM tree nor e164.arpa but something else? No. ENUM is when an E.164 number is entered under e164.arpa according to RFC3761. Infrastructure ENUM is when an operator populates their private e164.arpa tree and uses the data there for internal purposes such as call routing. End users will have no access to this tree or direct control over what's stored there. Operators might or might not choose to expose these private trees to each other. E.164 numbers entered under any domain name other than e164.arpa don't comply with my understanding of ENUM: ie RFC3761. _______________________________________________ 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 Tue, 29 Jun 2004 14:43:58 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 14:43:58 -0400 To: Mike Hammer Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <4.3.2.7.2.20040629133129.03afd2c0@cia.cisco.com> Message-ID: <2684.1088534176@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Mike" == Mike Hammer writes: Mike> Rather than relying on "joint ventures" to "share or link Mike> their private trees" (at which point privacy issues may Mike> arise) wouldn't it be better for the public ENUM to provide Mike> that linkage? In an ideal world it would be better, yes. But in the real world, the answer has to be no. Because a linkage through some public tree creates even bigger privacy issues. Like publishing on the internet how to reach an unlisted phone number. Which might also violate the opt-in principle that most regulators are insisting on for any public "ENUM-like" tree. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 29 Jun 2004 14:45:41 -0400 From: Mike Hammer Date: Tue, 29 Jun 2004 14:45:41 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1622B0673@oefeg-s02.oefeg.loc> Message-ID: <4.3.2.7.2.20040629142558.03b20410@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 06:26 PM 6/29/2004 +0100, Jim Reid wrote: >>>>> "richard" == Stastny Richard writes: >> These trees won't need any opt-in principle as they could be >> used for all numbers served by the operator, including unlisted >> ones. richard> So I can reach unlisted numbers only from richard> within the same operator? Depends on the operator, what they choose to make available to other operators and how it's made available. Suppose +10123456789 is an unlisted number living in a block belonging to TelcoA. TelcoB is in Austria. They have a private ENUM tree that points all +1 numbers at a SIP server in TelcoC's net in the USA. TelcoC knows that block 0123456 belongs to TelcoA. TelcoC's private tree points calls begining with this prefix at a SIP server in TelcoA's network which can then terminate the call by making the phone on +10123456789 ring. Hmmm... TelcoC is in competition with TelcoA and decides to add a 10 second delay to call setup messages going to TelcoA (or put them in lower priority queue)... Meanwhile TV add by TelcoC touts how quickly they can setup calls compared to their competitors... Generally, I would suspect that anytime there is more than an originating and terminating session-setup "telco", then ENUM is suboptimal. (Optimal could be zero telcos, but security, privacy, mobility and other concerns suggest that at least one telco per endpoint is likely.) Mike There's lots of hand-waving going on here, but you get the general idea. And of course if there's a shared operator ENUM tree, routing the call gets a whole lot simpler. _______________________________________________ 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 Tue, 29 Jun 2004 17:16:25 -0400 From: Mike Hammer Date: Tue, 29 Jun 2004 17:16:25 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: Message-ID: <4.3.2.7.2.20040629153807.00ba45c8@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 07:36 PM 6/29/2004 +0100, Jim Reid wrote: >>>>> "Mike" == Mike Hammer writes: Mike> Rather than relying on "joint ventures" to "share or link Mike> their private trees" (at which point privacy issues may Mike> arise) wouldn't it be better for the public ENUM to provide Mike> that linkage? In an ideal world it would be better, yes. But in the real world, the answer has to be no. Because a linkage through some public tree creates even bigger privacy issues. Like publishing on the internet how to reach an unlisted phone number. Which might also violate the opt-in principle that most regulators are insisting on for any public "ENUM-like" tree. Jim, I think that limiting the linkage through the public tree solely to an indication that an E.164 number can be reached through a particular service provider to be a sufficient mitigation of the privacy question, since that SP can enforce privacy service for that number. What I have yet to see on this list is any valid argument my assertion that the E.164 number tree is a publicly shared resource that is damaged if E.164 number assignment can be made to IP endpoints such that they are not universally reachable from the PSTN TDM domain. I understand the privacy concerns related to "opt-in", but feel that the meaning of "opt-in" should be geared toward what information is linked to the E.164 number. I think that having large quantities of E.164 numbers turn up missing from the routing infrastructure would effectively mean that large incumbent carriers can effectively take ownership of those E.164 number ranges and force smaller competitors to go through the monopoly, conglomeration, confederation, or whatever you want to call it to route calls. That would put them at a distinct competitive disadvantage. I guess I would sum up my thoughts this way: No one should be able to hoard E.164 numbers. The use of E.164 numbers should be publicly accountable. E.164 numbers should be routable/reachable, even if they are "unlisted". E.164 numbers may be reachable only through SPs providing privacy service. To maintain parallel choices available in the PSTN, it would be good if the call originator (who might be conceivable paying for the QoS) could choose the long distance "carrier" used to reach the terminating service provider network. But, I am not entirely sure what that would mean in the context of ITSPs, ISPs, and current non-regulatory frameworks. I am absolutely sure that making that choice possible so as to avoid the need for any regulation would definitely be good. I'm just hoping that those seeking business advantage don't invite unintended consequences. Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortelnetworks.com Tue, 29 Jun 2004 17:37:21 -0400 From: "James McEachern" Date: Tue, 29 Jun 2004 17:37:21 -0400 To: "'Mike Hammer'" MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, > If I understand correctly this could be a 3-stage process: > > 1) PSTN call causes NP dip and resolves to an IP-domain indication > Local database determines TDM routing to IP Gateway > PSTN call routed to nearest IP Gateway > (optional if call originates in IP) Does this mean that ENUM is only available to numbers that have been "ported out" to the IP-domain, and are marked as such in NP databases? > > 2) Public ENUM search resolves to Service Provider (SP) URI address > DNS search gives corresponding IP address > IP setup message routed to SP > (SP is public operator/carrier, enterprise, or opt-in end-user) I thought that the ENUM search returned the full URI, although in the case of SIP the initial routing might be on the basis of just the domain. Again, in the case of SIP, isn't step 3 really performed by the SIP proxy the target user has registered with, rather than by ENUM? > > 3) Private "ENUM" search (on local part of URI) resolves to Subscriber > URI > address > DNS search gives corresponding IP address > IP setup message sent to Subscriber > (optional if SP was end-user; subscriber is operator/carrier > customer or > enterprise end-point) I thought that Private (or Carrier, or Infrastructure) "ENUM" was orthogonal to all of this, and could potentially be used even if the E.164 had never been ported to the IP-domain at all. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Tue, 29 Jun 2004 17:48:29 -0400 From: "Christian de Larrinaga" Date: Tue, 29 Jun 2004 17:48:29 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <2647.1088533299@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R From: Jim Reid Sent: 29 June 2004 19:22 Christian> This suggests to me that you might get different Christian> answers to an ENUM (e164.arpa) look up depending on Christian> where you are? Yes. Christian-> So much for DNS being the universal name space! Christian> How do you ensure that public e164.arpa has first Christian> priority so that users public ENUM NAPTR records take Christian> precedence over operator (private ENUM)? You don't: that's a policy decision and implementation detail. And anyway who's to say whether the public or private tree takes precedence? Or even if precedence is appropriate? If my application is in some operator's net, it looks up .e164.arpa in their private tree and the answer determines what the application does. Likewise if it's on the internet, the application will query the public e164.arpa tree and uses that answer. ie Where the application lives determines what name space it gets to see and what answer the application gets *for the same query*. This is no different from how most big organisations do DNS today. If something's on the corporate intranet, they see the internal name space for example.com, complete with internal-only reachable web sites, mail servers and so on. When something's on the internet, they see the public face of example.com. That may or may not be very different from the internal name space. Christian -> Leaving aside for the moment whether it is a good thing to encourage large corporates' to believe their view of the outside world is just an expression of their own world view and should be shaped to fit! The example you use of example.com has problems as of course example.com (in your example) owns the lease to the domain example.com and so has every godlike right to amend the world order for those living in its realm (irritatingly!) - but I would argue not outside it - thank goodness! Bearing that point in mind e164.arpa has absolutely nothing to do with example.com or carrier.foo for that matter. Now if you setup a domain such as ibm.com, that is recognised as a genuine registered existant domain with unique qualities on the Internet, within your own DNS and you serve information from this domain to members of the public as if you are that entity then you are I think placing yourself in a position of representing yourself as that domain. That has serious legal consequences. But also looking at this from a practical perspective. As a travelled user when I want to reach my family from my SIP phone using a hotel room's Internet access (just think wistfully ahead!) I will expect having spent my Sunday programming in their 25 various devices and lifestyle options to match, to be able to reach them through whatever device is on duty at that time as set up in the relevant ENUM NAPTR record that I worked so hard getting right. So I will be mighty slaked off to find some spotty Hotel network VoIP operator claims no knowledge of what's happened to the NS records for the appropriate domain in e164.arpa because of course his e164.arpa is the doublethink reality version. As Peter suggested using Application layer tunnelling to captivate user applications within these goldfish bowl domains I don't see why I shouldn't use similar to get through and around them should they become a reality! Christian _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 29 Jun 2004 18:18:28 -0400 From: Mike Hammer Date: Tue, 29 Jun 2004 18:18:28 -0400 To: "James McEachern" Message-ID: <4.3.2.7.2.20040629172429.03b18948@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 04:23 PM 6/29/2004 -0400, James McEachern wrote: Mike, > If I understand correctly this could be a 3-stage process: > > 1) PSTN call causes NP dip and resolves to an IP-domain indication > Local database determines TDM routing to IP Gateway > PSTN call routed to nearest IP Gateway > (optional if call originates in IP) Does this mean that ENUM is only available to numbers that have been "ported out" to the IP-domain, and are marked as such in NP databases? I was focusing on what happens to E.164 numbers that do port to the IP domain, but do not preclude the use for numbers that had not. My issue was not so much for those that do use ENUM as it is for those E.164 users in the IP domain that do not have some minimal ENUM presence even in the form of a fronting carrier. > > 2) Public ENUM search resolves to Service Provider (SP) URI address > DNS search gives corresponding IP address > IP setup message routed to SP > (SP is public operator/carrier, enterprise, or opt-in end-user) I thought that the ENUM search returned the full URI, although in the case of SIP the initial routing might be on the basis of just the domain. Again, in the case of SIP, isn't step 3 really performed by the SIP proxy the target user has registered with, rather than by ENUM? I was leaving the nature of the content of the local part of the URI to the agreement between the operator and the subscriber regarding privacy. But, yes, in either case the routing of the call is a SIP operation, not an ENUM directory operation. > > 3) Private "ENUM" search (on local part of URI) resolves to Subscriber > URI > address > DNS search gives corresponding IP address > IP setup message sent to Subscriber > (optional if SP was end-user; subscriber is operator/carrier > customer or > enterprise end-point) I thought that Private (or Carrier, or Infrastructure) "ENUM" was orthogonal to all of this, and could potentially be used even if the E.164 had never been ported to the IP-domain at all. That is possible. I use the quotes around ENUM in this step, because the nature of the database operation is a local implementation issue, that could be structured as an ENUM database or not. But, at this point the local part could be an E.164 number or some random variable. Mike Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 29 Jun 2004 18:23:01 -0400 From: "Stastny Richard" Date: Tue, 29 Jun 2004 18:23:01 -0400 To: Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437C1@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R I was now 6 hours off the list and now tried to catch up with the le-mails: 1. I have a headache 2. To Jim: I thought one big advantage of ENUM was that I save a lot of OPEX not having to manage weird routing tables. What you are trying to set up with your private e164.arpa tree is an adminstrative nightmare. AND, you are trying to use ENUM for routing between operators This is not what ENUM is designed for. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 29 Jun 2004 19:59:13 -0400 From: Richard Shockey Date: Tue, 29 Jun 2004 19:59:13 -0400 To: "James McEachern" Message-ID: <6.1.0.6.2.20040629193225.0384fec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 0 I thought that Private (or Carrier, or Infrastructure) "ENUM" was orthogonal to all of this, and could potentially be used even if the E.164 had never been ported to the IP-domain at all. Correct Now real answer to you question is what do you mean by ported into the IP domain..ported by the consumer under the rules of 3761 or ported by the carrier into a IP soft switch (proxy) environment where two or more service providers may wish to exchange URI's in order to facilate the something like LERG, NPAC or IMT trunking? One is globally visible in the DNS ..the other is not and in fact may or may not use DNS at all. Jim >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 29 Jun 2004 19:59:13 -0400 From: Richard Shockey Date: Tue, 29 Jun 2004 19:59:13 -0400 To: enum at ietf.org Subject: [Enum] Fwd: [Sipping] RFC 3824 on Using E.164 numbers with the Session Initiation Protocol (SIP) Message-ID: <6.1.0.6.2.20040629193930.03854ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: ietf-announce at ietf.org From: rfc-editor at rfc-editor.org Date: Tue, 29 Jun 2004 16:24:46 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed at isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-8.5 required=5.0 tests=AWL,BIZ_TLD, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Cc: sipping at ietf.org, rfc-editor at rfc-editor.org Subject: [Sipping] RFC 3824 on Using E.164 numbers with the Session Initiation Protocol (SIP) X-BeenThere: sipping at ietf.org X-Mailman-Version: 2.1.5 List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces at ietf.org A new Request for Comments is now available in online RFC libraries. RFC 3824 Title: Using E.164 numbers with the Session Initiation Protocol (SIP) Author(s): J. Peterson, H. Liu, J. Yu, B. Campbell Status: Informational Date: June 2004 Mailbox: jon.peterson at neustar.biz, hong.liu at neustar.biz, james.yu at neustar.biz, bcampbell at dynamicsoft.com Pages: 16 Characters: 36535 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-e164-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3824.txt There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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. Content-Type: text/plain Content-ID: <040629161550.RFC at RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3824 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 29 Jun 2004 20:18:16 -0400 From: Jim Reid Date: Tue, 29 Jun 2004 20:18:16 -0400 To: "Stastny Richard" Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437C1@oefeg-s02.oefeg.loc> Message-ID: <16773.1088554180@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, *please* fix your mail software. It is very annoying to get needless base-64 encodings of UTF-8 that's actually just ASCII text. Even more irritating is finding a mail tool to translate that encoding back to ASCII so that your words of wisdom can be read. Grrr! > I thought one big advantage of ENUM was that I save a lot of > OPEX not having to manage weird routing tables. So every operator having their own funky domain name populated with stuff is somehow going to reduce costs? I don't think so. All that's going to do is replace one set of weird routing tables with another. It will also make it harder to merge or migrate those tables whenever there's any sort of industry consolidation. Merging name spaces when everyone's got their own ad-hoc ideas about naming conventions is just awful. Try it. I have and still have the scars from that torture. That pain will be zillions of times worse if/when these name spaces have deployed DNSSEC. > What you are trying to set up with your private e164.arpa tree > is an adminstrative nightmare. Oh give me a break! First of all, I just posted something off the top of my head as a hypothetical example of how call routing could be done. This isn't a blueprint for how it would be done. It's just one of a number of possibilities. As for administrative nightmares, your idea of each operator having their own silver tree is far, far worse. For starters, it will mean every bit of ENUM-aware software in the operator world is going to have to have a table so it knows what domain name(s) to use for the network the software is running on today. Please think about this. Nothing that uses the DNS today does anything remotely so stupid. And as for maintaining & distributing these tables.... What were you saying about reducing operational expense? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Tue, 29 Jun 2004 21:15:13 -0400 From: Jeff Williams Date: Tue, 29 Jun 2004 21:15:13 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BC@oefeg-s02.oefeg.loc> Message-ID: <40E22BE2.90D45332@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, Your #2 possibility looks feasible. I would need to study and test the effects of #4 Idea before I could be comfortable with it though. So I will turn that over to our R&D folks with my personal participation, and see how well your #2 possibility actually works before committing.. Stastny Richard wrote: > > There is no technical reason why 'public' > > ENUM cannot be applied to this problem (I am purposely using 'public' and > > ignoring the artificial and loosely defined concepts of 'user' and > > 'carrier' > > ENUM - everyone has their own understanding of each it seems). > > Hi Jason, > > Sorry for the somewhat delayed answer, I was busy. > I think you made a very good point, but there may be a distinction > between 'publi'! and 'private'. > > Let's try an analysis of the ENUM 'market' and the 'customers'. > > Historically ENUM started with the following idea: > 1. A subscriber has already an E.164 number on the PSTN > (this was the only way to get an ENUM entry), > and he may now decide on his own to request an > entry in ENUM (opt-in), given his country has > also decided to opt-in. > > He may now place URI's in his ENUM entry, pointing in principle > to whatever a URI may point to, e.g. a sip or mailto URI. > > Where he gets the URI from in the first place was his own business. > > This was not a good business model, because it was to complicated, > confusing to have two terminations, one on the PSTN and one on > the Internet, and finally after three years nobody is able to > get a delegation in any country anyway. So only some freaks > used it. > > There was only one potential business: linking IP PBX together: > In this case you could reach the same extension from the PSTN and > from the Internet, so from a end-user point the same device rings. > The user may also just dial a number and the IP PBX checks ENUM > First and if nothing is found, it dumps the call to the PSTN. > If the company knows that some other companies they are dealing > with are also in ENUM, they may save substantial money. > > Note: this may now also be an option again for residential subscribers > considering the new ATA's with FXO-ports (e.g. the SPA-3000, Azatel, etc) > > 2. Where did the above mentioned freaks get the SIP URI's from? > >From "providers" like FWD, sipphone, iptel, or DYI. > Now these providers all had numeric userID. Why? Because it > is easier to dial them on IP Phones and especially ATAs. > These providers now started to link each other together using > "cross trunking" access codes, but also some of them wanted to implement > ENUM. This is useful, but where to get numbers from. What they needed > where numbers NOT yet existing on the PSTN, so no opt-in is required. > Some countries considered to open special number ranges for this > purpose, but again these numbers are not available really, > and if, they will be non-geographic numbers > The above mentioned providers in most cases had no (direct) > interworking with the PSTN. > > 3. Some providers started to interwork with the PSTN and here > it showed clearly that customer primarily wanted local geographic > numbers. Period. These numbers differ from the above mentioned opt-in > scheme in 1. that they really terminate on IP, either single numbers > ported out or whole number ranges. If these providers want to link > each other via ENUM, ALL numbers must be in ENUM, so we have now > a clash with the original opt-in model. This problem may still be > solved insofar that a user may opt-in with a PSTN line on his > own, but with a VoIP service automatically by his provider (e.g. > he agrees that his number will be in ENUM (privacy provided) if > he is using this service). There are even ways to accommodate > both in one tree. > > Note: one basic attribute of all these options is that the user > has in addition to his E.164 number a public URI assigned. He may > be reached via this URI regardless of ENUM. So if a calling > user knows the URI, he may reach the called party in any case. > > Or in other words, ENUM is opt-in for the CALLING User also. > > Sofar the story of public "User" ENUM in e164.arpa. The major > problem of e164.arpa is that it is simply not available, so one > may get the idea to set up the same principle just in another > tree (temporarily?) (silver tree), so every operator may join > with his number ranges. > > 4. Now we have other customers for "ENUM" in addition. Any provider > using VoIP internally in his network (e.g YahooBB!, Comcast, etc.) > is currently interconnecting via the PSTN. Logically both the > providers and the users may benefit if these operators would > interconnect via IP. The big difference between these providers > and the above mentioned three options is that the subscribers > of these operators DO NOT GET AN URI (at least not a public reachable > one). There are many reason for this, e.g. the providers do not > want to make the internals of there networks public, privacy again > (because ALL numbers of an operator needs to be in), > but the major reason is: if you make a URI public, you also need > to agree on zero-termination. There will also be a clash with > already opted-in users. > This tree may finally be the authoritative NP tree pointing > for each E.164 number to the provider hosting it and MUST be able > to do this even if the PSTN ceases to exist. > > 5. I just want to add one option for completeness: some providers > want also to announce not only the numbers they host, but also the > number they may make available on the PSTN via their gateways. ENUM > is not designed for this, one should use TRIP or OSP for this purpose. > > I currently do not see a possibility to get all requirements > for all 4 options workable in one tree. I also do not see > any advantage for option 4 candidates to go for e164.arpa, > because they need a solution NOW and they may do this in any > tree (public or private) (see also ETSI draft TS 102 055) > > So I see two possibilities for User and Infrastructure ENUM are: > > 1. Find a way to implement everything in one tree > (which I consider not possible, but I am open for proposals) > > 2. Make two trees, one for above option 1.-3. and another > one for option 4. > > There is no problem having two trees in parallel, a provider > (or even the user himself) may query public User ENUM first > and public or private Infrastructure ENUM afterwards. > > Talking about two trees, of course there will be more trees at > the beginning, but if every operator gets delegated only > the numbers he is hosting, any two trees may be merged without > any problem (if no transit routes are in). > > This leaves the question of e164.arpa itself. For Infrastructure > ENUM there is no need to go into e164.arpa and wait until hell freezes > over until all countries have decided eventually to opt-in. > > Sorry to say, but the same is valid for "User" ENUM. The proposal > here is to set up a silver tree immediately by all interested parties, > which may or may not be folded back to e164.arpa if it gets useful. > Countries already having e164.arpa implemented may be copied over > to the silver tree in the meantime. > > Best regards > Richard > > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] > > Sent: Friday, June 25, 2004 5:16 PM > > To: 'Fullbrook Kim (UK)'; 'enum at ietf.org' > > Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) > > > > Kim wrote: > > > > > The intent of the ENUM DNS (from RFC 2916) is that it can be "used for > > identifying > > > available services connected to one E.164 number" giving examples of > > re-directs, email > > > > address and web page. > > > Someone can wardial the DNS using E.164 numbers to get back a list of > > SIP > > URIs and > > > potentially other information such as email addresses. My definition of > > a > > phone book > > > obtained by this means is a list of valid SIP URIs which contain some > > user-specific > > > information. > > > > I agree that this is possible, which begs the question of *why* a rational > > person would choose to register a number in ENUM and request with their SP > > that service addresses (email addr, IM ID, mobile #, etc.) be associated > > with their E.164 number? > > > > The only use case I can reasonably imagine is one for businesses, whereby > > 1-800-COMPANY is associated in ENUM with a variety addresses for that > > company (www.company.com, support at company.com, etc.). These are entities > > which want to share as much contact information as possible, compared to > > consumers which generally wish to share as little as possible. This > > business use is perhaps not a sufficient justification for investment in > > ENUM infrastructure in various countries (unless establishing a working > > business model is a thing of the past - but I think the bubble days are > > gone). > > > > What we seem to have, however, is a massive new market for VoIP services > > that would find ENUM to be a very helpful solution to enable softswitches > > (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions. > > The > > ultimate goal for these providers is to route calls over IP networks, > > without touching the PSTN (and therefore incurring various charges > > according > > to the PSTN regulatory regime). There is no technical reason why 'public' > > ENUM cannot be applied to this problem (I am purposely using 'public' and > > ignoring the artificial and loosely defined concepts of 'user' and > > 'carrier' > > ENUM - everyone has their own understanding of each it seems). > > > > Going back to Steve Lind's question of (paraphrasing) what problem the > > IETF > > is trying to solve, I still don't see an answer. IMHO, ENUM can be used > > by > > Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, CLECs, > > IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is for > > describing voice). It will be impossible to solve some constantly- > > shifting > > debate about 'privacy' in ENUM since no one seems to be able to agree on > > what privacy is (which is quite natural). > > > > However, privacy can be more readily defined and agreed upon at the > > national > > level, which is how the public ENUM delegations occur. Each country is > > likely to have different ways of viewing personal information and privacy, > > and have different laws, rules, and regulations to this effect. Within > > countries, different providers may be treated differently and have > > different > > standards to meet for notifying or seeking the consent of customers of > > the > > entry of their TN into ENUM (such as a highly regulated traditional telco > > vs. an unregulated ISP). So it appears to me, at least, that privacy > > issues > > are best addressed locally, in each country. And if that is the case, > > what > > is the point of much of the discussion on this list in the past several > > weeks? What is the technical problem at hand? > > > > Jason Livingood > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Tue, 29 Jun 2004 21:40:39 -0400 From: Jeff Williams Date: Tue, 29 Jun 2004 21:40:39 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <1778.1088512653@gromit.rfc1035.com> Message-ID: <40E231D5.7222EA3D@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, Jim Reid wrote: > >>>>> "Richard" == Stastny Richard writes: > > Richard> Sofar the story of public "User" ENUM in e164.arpa. The > Richard> major problem of e164.arpa is that it is simply not > Richard> available, so one may get the idea to set up the same > Richard> principle just in another tree (temporarily?) (silver > Richard> tree), so every operator may join with his number ranges. > > Sorry Richard, this is too simplistic. Your so-called silver tree > could only work if all the operators reached a consensus on the domain > name of that tree and who got to operate and populate it. There's > probably about as much chance of that happening as I have of winning > Miss World. Good point here Jim, and of course your right IMHO. Oh and I prefer the Miss Nude World contest of which I have again been ask to be a judge. >:) But I am sure you would not qualify for that contest either, or at least I hope you wouldn't! >:) > A unique and consistent naming scheme needs to be deployed > in order to avoid all sorts of confusion and bad practices that will > deter users and cripple the uptake of ENUM-based services. And as soon > as anyone starts talking about entering E.164 numbers into the DNS, > the usual government and regulatory issues raise their head. For > instance I cannot imagine the Chinese government agreeing to +86 going > under a registry operated in Austria. Or vice versa. > > Maybe your silver tree could fly if all the VoIP providers and their > fellow travellers co-operated on setting this up. I don't see a chance of this happening either.. > But so far all I see > are competing, mutually exclusive naming schemes which seem to be > about protecting market share or locking service providers and end > users into a vendor-specific solution. Getting co-operation seems > unlikely, even if there was agreement on who did what and how costs > were recovered. On top of that I can't see how VoIP provider A would > be comfortable exposing their customer's "phone numbers" in some > private, shared tree to VoIP provider B. > > Richard> I currently do not see a possibility to get all > Richard> requirements for all 4 options workable in one tree. > > Indeed. User and Infrastucture ENUM (to use those weasel terms) are > different things and cannot possibly exist in the same tree. They can > of course use the same domain name, but with different sets of name > servers providing different data to different constituencies: one for > the public internet and one for private telco-like usage. Since the > same sorts of applications are likely to live in both places -- ie > VoIP to SIP servers -- it would be sensible to use the same domain > name. That would avoid the messy complexity of applications having to > figure out where they are today to decide what domain name they should > lookup. > > Richard> There is no problem having two trees in parallel, a > Richard> provider (or even the user himself) may query public User > Richard> ENUM first and public or private Infrastructure ENUM > Richard> afterwards. > > I don't understand this. An end user should never, ever see a private > ENUM tree. Even if querying both trees was possible, how is the user > or application supposed to know which one holds the data it's supposed > to use? If my phone number is in both places each with 1 NAPTR record > pointing at different SIP servers, which one does the application > connect to? Now suppose one of those SIP servers lives deep in some > telco's net and is unreachable from another operator's net. Or the > internet. Or vice versa. Very well stated points here Jim! Well done. And this in part was my and our members concerns with publicly viewable or available Assigned ENUM's to users. > > > Richard> Talking about two trees, of course there will be more > Richard> trees at the beginning, but if every operator gets > Richard> delegated only the numbers he is hosting, any two trees > Richard> may be merged without any problem (if no transit routes > Richard> are in). > > This can never work. Number portability means block delegations to > operators will become increasingly fragmented over time. Delegations > will probably have to be made for individual numbers (or perhaps an > organisation's DDI block). If not, providers could use their control > over the end user's DNS content for all sorts of anti-competitive > practices. Like making it difficult to change the customer's > delegation to another provider. Yes this was discussed some time ago, and also remained relatively unsolved, so that subject line was dropped... Glad you brought it back up though here. > > > FYI merging DNS trees is far from the simple exercise you seem to > think it is. Read on... > > Richard> This leaves the question of e164.arpa itself. For > Richard> Infrastructure ENUM there is no need to go into e164.arpa > Richard> and wait until hell freezes over until all countries have > Richard> decided eventually to opt-in. > > Wrong. Operators can (and probably should) use a private version of > e164.arpa today. This doesn't need any involvement in the Tier-0 and > Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB > agreed domain name for ENUM. It's neutral and not controlled by any > commercial interest or nation. So it's the obvious choice for the > unique and consistent naming scheme that Infrastructure ENUM > needs. Do you mean an agreed upon TLD for ENUM here? > There is no viable alternative. [BTW don't confuse the domain > name e164.arpa with its public expression on the internet today.] This > would also make it easier for operators to interwork and perhaps link > their private trees: ie nobody has to figure out the DNS gunk need > to merge say enum.pulver.com with e164.at or enum.bt.intra. > > Richard> Sorry to say, but the same is valid for "User" ENUM. The > Richard> proposal here is to set up a silver tree immediately by > Richard> all interested parties, which may or may not be folded > Richard> back to e164.arpa if it gets useful. Countries already > Richard> having e164.arpa implemented may be copied over to the > Richard> silver tree in the meantime. > > Richard, you should not be making statements like this. Merging trees > and migrating domain names is a very, very painful process. [I know > because I've done it. Have you?] Even for the most trivial of cases in > controlled environments, this exercise is difficult, time-consuming > and all too easy to get wrong. In an ENUM world with as little as a > few hundred individually managed zones, migrating or merging them will > be effectively impossible. Now scale this to say a few million > delegations... For bonus points, deal with zones that have NAPTR > records pointing at URIs inside the tree that's being merged. > > Please remember that once a domain name is registered and gets used, > it lives forever in things like application software, configuration > files, address books, search engine databases, web links, documents & > stationery, web browser bookmarks, etc, etc. Once someone starts > populating phone numbers or whatever under RichardsSilverTree.at, > they're going to be pretty much stuck with that until long after hell > freezes over. I sometimes still get email sent to an address I stopped > using 10+ years and 5 jobs ago. > > This is one reason why there needs to be considerably more thought > about the choice of domain name for Infrastructure ENUM. You seem to > be saying that any old name can be used and moved elsewhere at some > point in future with a wave of a magic wand. It's not going to be that > simple. It can't be. Trust me on this. I've done fairly big domain > name migrations/mergers and know just how hard this is to do. It's > even harder when trying to maintain continuity of service. And harder > still when you've no idea what applications are out there and what > they look up or how they'll break if their favourite domain names get > changed. > > I think we agree there must be a single, consistent name space for > Infrastructure ENUM. The question then becomes one of implementation: > what domain name is used and how it gets realised. This is orthogonal > to what happens with the public e164.arpa name space. Please don't > confuse these two things even if the same domain name happens to apply > to both. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Tue, 29 Jun 2004 22:07:55 -0400 From: "Peter Williams" Date: Tue, 29 Jun 2004 22:07:55 -0400 To: jim at rfc1035.com Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R From: "Christian de Larrinaga" Reply-To: cdel at firsthand.net To: "Peter Williams" , CC: enum at ietf.org Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Date: Tue, 29 Jun 2004 18:49:56 +0100 christian :--> Thanks for the clear presentation of this idea. But does it matter if it is SSL or IPSEC with or without BGP4 policy? i.e., would it be better to allow user to define network architecture rather than imposing SSL only for ENUM use as a one size fits all? Or have I misunderstood you? It does not matter. I would agree that we need to let IP networks be designed according to the way the edges actually require services to ve delivered. I was thinking ahead by focussing on SSL VPNs, so we address the privacy issues created by E2U wholly within the IP stack. Im not sure Jim's proposal requires any IETF standards action. Its a purely operational matter. As the IAB mandates are only Informational RFCs (and mainly a statement of intent about the purposes of the .arpa zones), there is nothing binding in them on any operator. There is no lack of compliance in using private DNS sources for E2U discovery. Christian _______________________________________________ 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@nortelnetworks.com Tue, 29 Jun 2004 23:42:00 -0400 From: "James McEachern" Date: Tue, 29 Jun 2004 23:42:00 -0400 To: "'Mike Hammer'" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, > To maintain parallel choices available in the PSTN, it would be good if > the > call originator (who might be conceivable paying for the QoS) could > choose > the long distance "carrier" used to reach the terminating service > provider > network. But, I am not entirely sure what that would mean in the context > of ITSPs, ISPs, and current non-regulatory frameworks. I also am unsure what the concept of a "long distance carrier" would mean in the context of the end-to-end model, and in a universe where Session Border Controllers, NAT's B2BUAs and other evils do not exist. > I am absolutely > sure that making that choice possible so as to avoid the need for any > regulation would definitely be good. I'm just hoping that those seeking > business advantage don't invite unintended consequences. > > Mike > > > _______________________________________________ > 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@nortelnetworks.com Tue, 29 Jun 2004 23:53:37 -0400 From: "James McEachern" Date: Tue, 29 Jun 2004 23:53:37 -0400 To: "'Mike Hammer'" MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, > >Does this mean that ENUM is only available to numbers that have been > >"ported out" to the IP-domain, and are marked as such in NP databases? > > I was focusing on what happens to E.164 numbers that do port to the IP > domain, but do not preclude the use for numbers that had not. If an E.164 number has not been ported to the IP-domain, then would people who dial the number from the PSTN ever see the results of an ENUM query? Is that acceptable? Or is there an expectation that the PSTN switches would have to perform an ENUM dip even if the number had not been ported to the IP-domain? Am I missing something? > My issue was > not so much for those that do use ENUM as it is for those E.164 users in > the IP domain that do not have some minimal ENUM presence even in the > form > of a fronting carrier. If an E.164 user in the IP-domain does not opt-in to ENUM, and does not have even a minimal ENUM presence in the form of a fronting carrier, doesn't that mean that it is not possible to reach them by dialing an E.164 number? Isn't that likely their intent? James _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 30 Jun 2004 00:39:03 -0400 From: Jeff Williams Date: Wed, 30 Jun 2004 00:39:03 -0400 To: Stastny Richard Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <06CF906FE3998C4E944213062009F1624437BF@oefeg-s02.oefeg.loc> Message-ID: <40E25C82.B4578F36@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and all, I have no particular problem with your definitions below. However for reasons of clarity in discussions and deliberations, your reference terms/definitions seem to cause confusion. Hence I would like to kindly request and/or suggest that the more proper nomenclature for "ENUM's" be used. Stastny Richard wrote: > James Seng [mailto:jseng at pobox.org.sg] wrote: > > > > it would be make sense to define goldentree, silvertree etc as i can see > > we going to use these term regularly in carrier ENUM. anyone wants to > > take a shot at this before san diego...if not, i forsee we going to have > > a lively debate just on the terminology. 1hr is not going to be enough. > > > > incidently, it might be worthwhile to look at the world as it exists > > first before thinking how we like it to be. the world right now is a > > world of silvertrees. > [Richard>] > No, not really, there can only be one (or two) silvertrees, > but many bronze trees > > I am somewhat reluctant to define the terms, because immediately > somebody will come up (afterwards) and state that these definitions > are wrong, or he disagrees and BW what about privacy. > > Nevertheless, I will try ;-) > > ENUM: as defined in RFC3761, implemented in e164.arpa, > publicly accessible, NAPTRs must be retrieveable, ditto URIs, > although the services pointed to by may not be accessible by > anybody (see RFC3764). > > "User" ENUM = synonym for ENUM (used to distinguish between > other types of ENUM. > > Golden tree: in ENUM = e164.arpa > In other types of ENUM: a shared tree agreed upon by all operators > > Silver tree: a tree used as temporarily replacement for > e164.arpa with the intention to move the whole tree over > to e164.arpa if it is available for every E.164 number. > One could also call this parking tree. > Note: if not every E.164 number will be finally in e164.arpa, > there is a possibility that the silver tree will be around > forever. > > Since all operators may create their golden tree wherever > they want, there is no need there for a silver tree. > What may happen is maybe is wood of bronze trees ;-) > > The only silver tree I could imagine here is that everybody > agrees on one tree, but there is no possibility to have > this tree immediately in .arpa, so a parking silver tree > may be useful. > > Other types of ENUM: > > First, there is no distinction between > Operator, Carrier or Infrastructure (OCI) "ENUM", > One may use each of this terms. > > But there is a distinction between: > > Private OCI ENUM: > Private OCI ENUM is a tree set-up by a single operator > or network provider within his network. He may choose > any TLD for this tree, even not existing ones, but he may also > choose to use the same tree as Shared OCI ENUM or even e164.arpa > This may come in handy if they decide to use split DNS, providing > different date inside and outside > > Shared OCI ENUM: > Is a tree set-up by a confederation of operators. > It is the choice of the confederation if this > tree is private again (e.g. in an extranet), public, > in which tree, and if the data in the tree is accessible. > > Only if the tree is public and accessible, they need to > obey privacy > > For more information on the different options in > Infrastucture (OCI) ENUM (although not complete yet and still a mess) > see the latest ETSI draft on Infrastructure ENUM > > http://enum.nic.at/documents/ETSI/Drafts/0009-TD06r2%20Draft%20ts-102055%20200407%20London%20plus%20Paul.doc > > regards > Richard > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Wed, 30 Jun 2004 03:02:56 -0400 From: Marian Durkovic Date: Wed, 30 Jun 2004 03:02:56 -0400 To: Jim Reid Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) In-Reply-To: <2647.1088533299@gromit.rfc1035.com> Message-ID: <20040630064907.GA50016@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, I strongly disagree with your proposal to "overlay" public e164.arpa by each telco with its own private tree. This would mean, that completely unrelated and unathorized entities (i.e. telco X in country A) will be suggested to replace authoritative data from national (e.g. 1.2.4.e164.arpa) domain delegated by ITU/RIPE by any data (or garbage) they will. I think this undermines the basic principle of DNS operation, where only one entity is authoritative for a given domain and creates the state, where several thousand (!) different zone file versions could exist for the same domain. IMHO different tree is a must here, and lookups into different trees are supported in software now. With kind regards, M. > From: Jim Reid > Sent: 29 June 2004 19:22 > > Christian> This suggests to me that you might get different > Christian> answers to an ENUM (e164.arpa) look up depending on > Christian> where you are? > > Yes. > > Christian> How do you ensure that public e164.arpa has first > Christian> priority so that users public ENUM NAPTR records take > Christian> precedence over operator (private ENUM)? > > You don't: that's a policy decision and implementation detail. And > anyway who's to say whether the public or private tree takes > precedence? Or even if precedence is appropriate? If my application is > in some operator's net, it looks up .e164.arpa in their > private tree and the answer determines what the application > does. Likewise if it's on the internet, the application will query the > public e164.arpa tree and uses that answer. ie Where the application > lives determines what name space it gets to see and what answer the > application gets *for the same query*. > > This is no different from how most big organisations do DNS today. If > something's on the corporate intranet, they see the internal name > space for example.com, complete with internal-only reachable web > sites, mail servers and so on. When something's on the internet, they > see the public face of example.com. That may or may not be very > different from the internal name space. -------------------------------------------------------------------------- ---- ---- ---- 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 Wed, 30 Jun 2004 03:36:27 -0400 From: "Stastny Richard" Date: Wed, 30 Jun 2004 03:36:27 -0400 To: "Jim Reid" Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: <06CF906FE3998C4E944213062009F1624437C2@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim wrote: > > Richard, *please* fix your mail software. It is very annoying to get > needless base-64 encodings of UTF-8 that's actually just ASCII text. > Even more irritating is finding a mail tool to translate that encoding > back to ASCII so that your words of wisdom can be read. Grrr! [Richard>] I told you already many times that I have to use Microsoft Outlook(TM) Web Access if I am not in the office and that I have no choice here. On the other hand, I consider UTF-8 as a valid standard and seemingly most normal mail SW is able to understand it. Even the IETF archive has been updated to decipher it. Anyway, as a courtesy, I tried to send you a previous e-mail direct via a different account, but this mail got rejected by your mail server as spam and I was told to get lost. This btw happened to others too. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 30 Jun 2004 04:39:17 -0400 From: "Stastny Richard" Date: Wed, 30 Jun 2004 04:39:17 -0400 To: "James McEachern" Subject: [Enum] IETF, ENUM and NGN Message-ID: <06CF906FE3998C4E944213062009F1624437C3@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R James McEachern [mailto:jmce at nortelnetworks.com] wrote: > I also am unsure what the concept of a "long distance carrier" would mean > in > the context of the end-to-end model, and in a universe where Session > Border > Controllers, NAT's B2BUAs and other evils do not exist. > [Richard>] Still having my headache from yesterdays e-mails on this list, I think James remark is up to the point I wasn't sure if I am really on an IETF mailing list, it sounds more like ETSI TISPAN or 3GPP. May I throw in some buzzwords reminding you where we are: The Internet and it's success stands for Keep it simple, stupid Stupid network End-to-end connectivity End-user control Vertical layering VoIP is a SW application and a product etc. and NGN stands for: Intelligent network Walled garden Horizontal stove pipes Firewalls Session Border Controller Managed networks VPNs? Points of Interconnect Termination charges Transit networks = long distance carriers Voice is a service Provider control etc. I also want to remind everybody on the position of the FCC regarding VoIP: However, all participants in the broadband value chain should embrace a set of connectivity principles which ensure that consumers: -Can gain access to any content on the internet -Can run the applications they choose -Have adequate information regarding their service capabilities -Can attach any devices to their broadband connection that do not harm the network We should also not forget that the basic routing mechanism for connectivity on the Internet is the DNS and URI, so for VoIP this are sip and h323 URIs ENUM is only an add on and not basically necessary to route calls. Since URIs are used as address-of-record and contact-address, they are intended to be used to identify the terminating server and terminal and are NOT intended to be used for routing via transit "networks" Therefore ENUM should not be used for this purpose for two reasons: 1. ENUM is not designed for this and lacking the required information 2. it is contradicting the end-to-end philosophy of the Internet. If NGN proponents are trying to set up mechanism on IP to allow routing of E.164 numbers and also to transfer the complicated routing regime they have between "networks" and also the IN NP databases, they may do so, even they may use ENUM technology. And it is perfectly valid for ETSI and 3GPP dealing with these issues But we should be well aware of the complexity of the issue, and Maybe we should also give them a warning or tutorial that there Is no such thing as "networks" on the Internet. The Internet is only one network and therefore things could (and will be) implemented in a much simpler way. Summary: The basic mechanism for end-to-end connectivity for IP Communications including VoIP on the Internet is URIs. The usage of ENUM is an optional add-on. Important note: The model of end-user control seems to be flawed, at least for residential customers. Same holds true for the original idea for using ENUM as "business card" replacement. There seems to be no market for this, at least not at the moment. So one way forward could be to shift the control of the domain (at least for certain number ranges) to the entity providing the SIP service (either provider or enterprise) Second important note: this does NOT compromise the end-to-end connectivity model!! and also NOT the opt-in model, only that in this case the provider is opting-in on behalf of his customer. Joe Doe customers just do not want to fiddle around with ENUM-entries, they simply do not understand ENUM. (read my lips, not only Joe Does ;-) If the PSTN is moving to IP and therefore seeking for a routing mechanism for E.164 numbers on IP, this may be the DNS, but maybe be not (as Rich said). If the decide to use ENUM-technolgy, ok, but this will be very complex (as everything on the PSTN is), it will be not optional (it cannot be), and it will therefore be orthogonal and independent from (User) ENUM. This also implies that this CANNOT happen in the same tree, because ownership, administration and delegation path are completely different. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 30 Jun 2004 05:10:31 -0400 From: Jim Reid Date: Wed, 30 Jun 2004 05:10:31 -0400 To: "Stastny Richard" Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <06CF906FE3998C4E944213062009F1624437C3@oefeg-s02.oefeg.loc> Message-ID: <17086.1088586316@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: Richard> If the PSTN is moving to IP and therefore seeking for a Richard> routing mechanism for E.164 numbers on IP, this may be Richard> the DNS, but maybe be not (as Rich said). If the decide Richard> to use ENUM-technolgy, ok, but this will be very complex Richard> (as everything on the PSTN is), it will be not optional Richard> (it cannot be), and it will therefore be orthogonal and Richard> independent from (User) ENUM. Richard> This also implies that this CANNOT happen in the same Richard> tree, because ownership, administration and delegation Richard> path are completely different. AFAICT nobody is suggesting Infrastructure and User ENUM would use the same tree. The constraints and data models for these things are completely different. However some people seem to think that if these two flavours of ENUM use the same domain name, this means they both have to use the same tree with one model for ownership, administration and delegation. That doesn't necessarily follow. What some operator does with its private, internal-use-only version of e164.arpa and how they populate and manage that is nobody else's concern, apart from the usual regulatory issues like universal service obligations, fair competition and so on. What matters is the operators agree on a domain name for Infrastructure ENUM. This might as well be e164.arpa since (a) it's vendor neutral; (b) already an agreed IETF standard; (c) not controlled by any nation. It's hard to see how any other choice of domain name could be better (technically or politically). And it prevents VoIP/SIP applications from getting schizophrenia from figuring out which domain name they should use based on what network they're running in today. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 30 Jun 2004 06:19:21 -0400 From: "Stastny Richard" Date: Wed, 30 Jun 2004 06:19:21 -0400 To: "Jim Reid" Subject: RE: [Enum] IETF, ENUM and NGN Message-ID: <06CF906FE3998C4E944213062009F1624437C4@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid [mailto:jim at rfc1035.com] wrote: > > AFAICT nobody is suggesting Infrastructure and User ENUM would use the > same tree. The constraints and data models for these things are > completely different. However some people seem to think that if these > two flavours of ENUM use the same domain name, this means they both > have to use the same tree with one model for ownership, administration > and delegation. That doesn't necessarily follow. What some operator > does with its private, internal-use-only version of e164.arpa and how > they populate and manage that is nobody else's concern. [Richard>] This is correct. An operator may even decide to use e164.arpa. and this would make sense, if there would be only public e164.arpa and the operators private trees. But as we elaborated in ETSI TS 102 055, groups of operators (confederations) may decide to use a shared tree. This shared tree could either be "private" to the confederation (in an extranet) or in the public DNS. Different confederations may choose to use different shared trees. This may not be a good idea, but it is happening all over the place (ask Rich). And all these trees are NOT and cannot be e164.arpa So if an operator is joining such a confederation he will use for his "private" tree the same name as used out-side by the confederation and not e164.arpa. > > What matters is the operators agree on a domain name for > Infrastructure ENUM. This might as well be e164.arpa since (a) it's > vendor neutral; (b) already an agreed IETF standard; (c) not > controlled by any nation. It's hard to see how any other choice of > domain name could be better (technically or politically). And it > prevents VoIP/SIP applications from getting schizophrenia from > figuring out which domain name they should use based on what network > they're running in today. [Richard>] This is easy, as I already stated and many SER and Asterisk based SIP server already query more then one tree now. Its one line of code. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Wed, 30 Jun 2004 06:41:08 -0400 From: Marian Durkovic Date: Wed, 30 Jun 2004 06:41:08 -0400 To: Jim Reid Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: Message-ID: <20040630103652.GA62029@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: R > AFAICT nobody is suggesting Infrastructure and User ENUM would use the > same tree. The constraints and data models for these things are > completely different. However some people seem to think that if these > two flavours of ENUM use the same domain name, this means they both > have to use the same tree with one model for ownership, administration > and delegation. That doesn't necessarily follow. What some operator > does with its private, internal-use-only version of e164.arpa and how > they populate and manage that is nobody else's concern, apart from the > usual regulatory issues like universal service obligations, fair > competition and so on. Yes it is - as soon, as you start getting complaints from cutomers of this operator like "why did you put into the e164.arpa. records which routed me to such expensive path?" I'd be quite interested what will be your reaction, if someone makes a "private" tree overlaying the .UK TLD with any sort of (possibly invalid) data. Generally, using the same domain name for completely different purposes is IMHO _very_ bad idea. There's absolutely no problem to avoid this by agreeing on different domain name - and for completely private purposes even non-existent TLD like e164.nxd. could be used which definitely can't be reached from the public internet. 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 jcurran@istaff.org Wed, 30 Jun 2004 06:56:01 -0400 From: John Curran Date: Wed, 30 Jun 2004 06:56:01 -0400 To: Jim Reid Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R At 10:05 AM +0100 6/30/04, Jim Reid wrote: >AFAICT nobody is suggesting Infrastructure and User ENUM would use the >same tree. The constraints and data models for these things are >completely different. However some people seem to think that if these >two flavours of ENUM use the same domain name, this means they both >have to use the same tree with one model for ownership, administration >and delegation. That doesn't necessarily follow. What some operator >does with its private, internal-use-only version of e164.arpa and how >they populate and manage that is nobody else's concern, apart from the >usual regulatory issues like universal service obligations, fair >competition and so on. > >What matters is the operators agree on a domain name for >Infrastructure ENUM. This might as well be e164.arpa since (a) it's >vendor neutral; (b) already an agreed IETF standard; (c) not >controlled by any nation. It's hard to see how any other choice of >domain name could be better (technically or politically). Hmm... If some operators really and truly intend to run a data tree which is not publicly visible, than I see no need for any standard in this area. The operator (or set of operators which share such a data tree) can simply configure an appropriate domain of their choice. I don't believe that there needs to be a distinct Infstrastructure ENUM and User ENUM data tree. The only strong reason given for separate models is privacy and I'll assert that it is possible to put information in the tree for a given E.164 number that consists of nothing more than a record which directs one to the appropriate service provider (as noted by Mike Hammer earlier) and that this will indeed prove sufficient to provide connectivity without raising privacy concerns. The operator community should be encouraged to put some nominal information for their number blocks in the Public ENUM tree, even if this is nothing more than a single wildcard record pointing to a default server for that operator. As numbers port, it should be very straightforward to insert an appropriate specific DNS record to direct queries to the new provider as appropriate, including the degenerate case where a knowledgeable user (or user with knowledgeable party under contract) arranges to have richer connectivity information put in place under their entry. /John _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Nick.Russell@vodafone.com Wed, 30 Jun 2004 07:20:07 -0400 From: "Russell, Nick, VF UK - Technology (TS)" Date: Wed, 30 Jun 2004 07:20:07 -0400 To: Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B7128010E1665@UKWMXM01> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear All, Just a quick question from a newbie on this list on section 4 "Fax Service Registration" of the below draft. Why is the "tel:" URI proposed to be used not the "fax:" URI as the "URI Scheme"? Are "fax:" URIs being discontinued (draft-ietf-iptel-rfc2806bis-09 seems to hint at this)? Thanks, Nick > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Internet-Drafts at ietf.org > Sent: 23 June 2004 21:53 > To: i-d-announce at ietf.org > Cc: enum at ietf.org > Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Telephone Number Mapping > Working Group of the IETF. > > Title : IANA Registration for ENUMservices > email, fax, mms, ems and sms > Author(s) : R. Brandner, et al. > Filename : draft-ietf-enum-msg-02.txt > Pages : 19 > Date : 2004-6-23 > > This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms', > 'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and > 'sips:' as per the IANA registration process defined in the ENUM > specification RFC3761 [6]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request at ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-enum-msg-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-msg-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 30 Jun 2004 07:20:14 -0400 From: "Stastny Richard" Date: Wed, 30 Jun 2004 07:20:14 -0400 To: "John Curran" Subject: RE: [Enum] IETF, ENUM and NGN Message-ID: <06CF906FE3998C4E944213062009F1624437C5@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R John Curran [mailto:jcurran at istaff.org] wrote: > > Hmm... If some operators really and truly intend to run a data tree > which is not publicly visible, than I see no need for any standard in > this area. The operator (or set of operators which share such a data > tree) can simply configure an appropriate domain of their choice. [Richard>] Good point. On the other hand, if somebody wants to query both trees one after the other, it would be nice if the same algorithms and SW could be used. This was the basic question I had on Infrastructure ENUM: Is there anything carriers would like to have in RFC3761 we do not now, speak up. If not, fine. > The operator community should be encouraged to put some nominal > information for their number blocks in the Public ENUM tree, even if this > is nothing more than a single wildcard record pointing to a default server > for that operator. As numbers port, it should be very straightforward > to insert an appropriate specific DNS record to direct queries to the > new provider as appropriate, including the degenerate case where a > knowledgeable user (or user with knowledgeable party under contract) > arranges to have richer connectivity information put in place under their > entry. [Richard>] That was exactly what I proposed in a previous e-mail. There is only one drawback: since wildcards do not work in this case, there is no straightforward solution. There is one, but it is not straightforward (provided by Jim) It requires a second query for the enclosing zone. It has also be discussed on this list some two month ago and is already contained in ETSI TS 102 172 V2. Richard > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 30 Jun 2004 08:13:40 -0400 From: Jim Reid Date: Wed, 30 Jun 2004 08:13:40 -0400 To: "Stastny Richard" Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <06CF906FE3998C4E944213062009F1624437C4@oefeg-s02.oefeg.loc> Message-ID: <17258.1088596785@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Richard" == Stastny Richard writes: >> What matters is the operators agree on a domain name for >> Infrastructure ENUM. This might as well be e164.arpa since (a) >> it's vendor neutral; (b) already an agreed IETF standard; (c) >> not controlled by any nation. It's hard to see how any other >> choice of domain name could be better (technically or >> politically). And it prevents VoIP/SIP applications from >> getting schizophrenia from figuring out which domain name they >> should use based on what network they're running in today. Richard> This is easy, as I already stated and many SER Richard> and Asterisk based SIP server already query more then one Richard> tree now. Its one line of code. That must be a very long line of code if it can query multiple domain names, prioritise the order they're used, arbitrate between conflicting answers and do all of the other policy stuff that's needed. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Wed, 30 Jun 2004 08:30:54 -0400 From: Jim Reid Date: Wed, 30 Jun 2004 08:30:54 -0400 To: Marian Durkovic Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <20040630103652.GA62029@us.svf.stuba.sk> Message-ID: <17290.1088598235@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Marian" == Marian Durkovic writes: >> AFAICT nobody is suggesting Infrastructure and User ENUM would >> use the same tree. The constraints and data models for these >> things are completely different. However some people seem to >> think that if these two flavours of ENUM use the same domain >> name, this means they both have to use the same tree with one >> model for ownership, administration and delegation. That >> doesn't necessarily follow. What some operator does with its >> private, internal-use-only version of e164.arpa and how they >> populate and manage that is nobody else's concern, apart from >> the usual regulatory issues like universal service obligations, >> fair competition and so on. Marian> Yes it is - as soon, as you start getting complaints from Marian> cutomers of this operator like "why did you put into the Marian> e164.arpa. records which routed me to such expensive Marian> path?" I think you've missed the point. If an operator has a private tree which they use for the operation of their network, it won't ever be visible to their end customers. No matter what that domain name is. And if we take the way the phone system works today, nobody apart from some telco network engineers know how calls get routed. Presumably this is done to minimise the telco's costs and maximise its revenues. But who can tell? You and I have no idea if our calls from Europe to America go by satellite or under the sea or even if they're carried over VoIP. That isn't going to change once our telcos deploy their own DNS trees for Infrastructure ENUM. Marian> I'd be quite interested what will be your reaction, if Marian> someone makes a "private" tree overlaying the .UK TLD with Marian> any sort of (possibly invalid) data. People do this already. Some people even do this on the internet for the root zone. Provided these silly things don't interfere with the operation of real internet, who cares what these people get up to in their private little clubs? DNSSEC will eventually take care of those who impersonate a domain and try to propagate bogus data. Marian> Generally, using the same domain name for completely Marian> different purposes is IMHO _very_ bad idea. There's Marian> absolutely no problem to avoid this by agreeing on Marian> different domain name - and for completely private Marian> purposes even non-existent TLD like e164.nxd. could be Marian> used which definitely can't be reached from the public Marian> internet. Choosing a non-existent TLD is very unwise. What happens when ICANN in its infinite wisdom decides to one day create the .nxd TLD? Domain names should never just be plucked out of the air. Especially for infrastructure things. And yes, I am aware of the bogus .gprs TLD that mobile telcos are using on the internet today. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 30 Jun 2004 09:00:06 -0400 From: "Stastny Richard" Date: Wed, 30 Jun 2004 09:00:06 -0400 To: "Jim Reid" Subject: RE: [Enum] IETF, ENUM and NGN Message-ID: <06CF906FE3998C4E944213062009F1624437C6@oefeg-s02.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid [mailto:jim at rfc1035.com] wrote: > > Richard> This is easy, as I already stated and many SER > Richard> and Asterisk based SIP server already query more then one > Richard> tree now. Its one line of code. > > That must be a very long line of code if it can query multiple domain > names, prioritise the order they're used, arbitrate between conflicting > answers and do all of the other policy stuff that's needed. [Richard>] Yes, these a clever guys ;-) No Jim, KISS. Easiest thing to do is query one tree after the other, first ENUM and then Infrastructure ENUM. If you get an answer in ENUM, you are done, no arbitration necessary. As I said: Infrastructure ENUM is the equivalent to "dump the call to the PSTN". I also said here on the list many times: they do it already with e164.arpa, freenum.org for 800 numbers and then to the PSTN (1 2 3). As a user I just dial a phone number. BTW, freenum.org is very convenient for long phone conferences with the US, this is a service the PSTN cannot provide. No problem whatsoever. Richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lwc@roke.co.uk Wed, 30 Jun 2004 09:21:27 -0400 From: "Conroy, Lawrence (SMTP)" Date: Wed, 30 Jun 2004 09:21:27 -0400 To: "Russell, Nick, VF UK - Technology (TS)" Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt In-Reply-To: <6FC554FA1F33BE4C9AC844FC3B3B7128010E1665@UKWMXM01> Message-ID: <47FF20EE-CA97-11D8-81C7-000393A70BB2@roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R On 30 Jun 2004, at 12:13, Russell, Nick, VF UK - Technology (TS) wrote: Dear All, Just a quick question from a newbie on this list on section 4 "Fax Service Registration" of the below draft. Why is the "tel:" URI proposed to be used not the "fax:" URI as the "URI Scheme"? Are "fax:" URIs being discontinued (draft-ietf-iptel-rfc2806bis-09 seems to hint at this)? Thanks, Nick Yes. the update to RFC2806 does not include them, so they're, in effect, deprecated. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From md@bts.sk Wed, 30 Jun 2004 10:53:00 -0400 From: Marian Durkovic Date: Wed, 30 Jun 2004 10:53:00 -0400 To: Jim Reid Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <20040630103652.GA62029@us.svf.stuba.sk> Message-ID: <20040630144359.GA79413@us.svf.stuba.sk> MIME-Version: 1.0 Content-Type: text/plain Status: R > I think you've missed the point. If an operator has a private tree > which they use for the operation of their network, it won't ever be > visible to their end customers. No matter what that domain name is. Jim, even if the overlay is running on some secret server used just for the internal telco operations, there's at least one big problem left - the private tree overlays the public ENUM tree making it inaccessible and unusable. However, if the intrastructure ENUM is sitting in some other domain, both are accessible and it's a matter of local policy in which order they get consulted. > Marian> I'd be quite interested what will be your reaction, if > Marian> someone makes a "private" tree overlaying the .UK TLD with > Marian> any sort of (possibly invalid) data. > > People do this already. Some people even do this on the internet for > the root zone. Provided these silly things don't interfere with the > operation of real internet... Well, but The question is whether IETF should recommend/advice/support such silly implementations. 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 mhammer@cisco.com Wed, 30 Jun 2004 10:54:42 -0400 From: Mike Hammer Date: Wed, 30 Jun 2004 10:54:42 -0400 To: "James McEachern" Message-ID: <4.3.2.7.2.20040630103702.00b02588@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 11:46 PM 6/29/2004 -0400, James McEachern wrote: Mike, > >Does this mean that ENUM is only available to numbers that have been > >"ported out" to the IP-domain, and are marked as such in NP databases? > > I was focusing on what happens to E.164 numbers that do port to the IP > domain, but do not preclude the use for numbers that had not. If an E.164 number has not been ported to the IP-domain, then would people who dial the number from the PSTN ever see the results of an ENUM query? Is that acceptable? Or is there an expectation that the PSTN switches would have to perform an ENUM dip even if the number had not been ported to the IP-domain? Am I missing something? If you are calling from a TDM switch and the call should terminate to a TDM switch, then ENUM will likely not be involved. I thought the earlier question was whether an ENUM entry for a number could exist that indicates to go direct to a PSTN GW, because it is in the TDM domain. My original issue was that if a number had ported from TDM to IP domains, and a call is routed to PSTN GW, then when GW does an ENUM dip to try to further route it, it ought to have a hit and not a miss. There is no sense having an E.164 number in the IP domain if you can not route a call to it. > My issue was > not so much for those that do use ENUM as it is for those E.164 users in > the IP domain that do not have some minimal ENUM presence even in the > form > of a fronting carrier. If an E.164 user in the IP-domain does not opt-in to ENUM, and does not have even a minimal ENUM presence in the form of a fronting carrier, doesn't that mean that it is not possible to reach them by dialing an E.164 number? That seems very likely. Isn't that likely their intent? I view using up an E.164 and it not being reachable as malfeasance. Would it be acceptable to have a range of IPv4 addresses assigned, but not reachable? The problem here is that there are both "names" (e.g. URI) and "addresses" (IP) on the Internet, but for PSTN the E.164 serves both purposes, which is why ability to route is a concern. Also, to address another email comment, the "Inter" in Internet means that it is a "network of networks" where the interworking at GWs needs to work well. And as I had noted before, the "opt-in" aspect is not compatible with the end-to-end principle, where addressing and routing are concerned. Mike James _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Wed, 30 Jun 2004 12:27:35 -0400 From: "Peter Williams" Date: Wed, 30 Jun 2004 12:27:35 -0400 To: jim at rfc1035.com Subject: Re: [Enum] IETF, ENUM and NGN Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Well, but The question is whether IETF should recommend/advice/support such silly implementations. IAB has already recognized ENUM providers will, and must inevitably use name spaces other than those standardized by IAB. It specifically called out this in the Informational RFCs disclosing their rationales for the IAB mandates, and certain communications with ITU-T. IETF has never objected before to operators running private zones. Such zones often carry enhanced resource definitions/data, shared only with custom resolvers. Do you feel an joint I-D coming on, Jim? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Wed, 30 Jun 2004 12:39:12 -0400 From: "Peter Williams" Date: Wed, 30 Jun 2004 12:39:12 -0400 To: jim at rfc1035.com Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R As Peter suggested using Application layer tunnelling to captivate user applications within these goldfish bowl domains I don't see why I shouldn't use similar to get through and around them should they become a reality! Christian Dont get too upset at common practice. Privacy and control are orthognal axies of operational security. To get privacy, public ENUM providers (or their TTPs) wil have to cede some control. Security and Privacy via comparmentalization is a well understood practice. IF we reason by analogy,PABXs have long had public number to private exchange number mappings, to save costs, and route the call across the preferred providers network (as selected by the PABX). Im not aware of the PSTN having collapsed because of a private zone was created to manage public E.164 names. Quite the opposite, US telcos started offering "VPN services" to manage those names way back in 1950! Can the determined corporate user use a calling card, and use source routing via AT&T 1800CALLATT number to avoid the local poilicy? of course. Im a security engineer; I dont get to trust provider or operator conformance to standards, or make assumptiosn that software works correctly _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortelnetworks.com Wed, 30 Jun 2004 15:22:26 -0400 From: "James McEachern" Date: Wed, 30 Jun 2004 15:22:26 -0400 To: "'Stastny Richard'" Subject: [Enum] A Modest Proposal Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, In your excellent summary of ENUM you said that: > > ENUM is only an add on and not basically necessary to route calls. > Since URIs are used as address-of-record and contact-address, they are > intended to be used to identify the terminating server and terminal and > are NOT intended to be used for routing via transit "networks" > Therefore ENUM should not be used for this purpose for two reasons: > 1. ENUM is not designed for this and lacking the required information > 2. it is contradicting the end-to-end philosophy of the Internet. > > If NGN proponents are trying to set up mechanism on IP to allow > routing of E.164 numbers and also to transfer the complicated routing > regime they have between "networks" and also the IN NP databases, > they may do so, even they may use ENUM technology. And it > is perfectly valid for ETSI and 3GPP dealing with these issues > and ... > > If the PSTN is moving to IP and therefore seeking for a routing > mechanism for E.164 numbers on IP, this may be the DNS, but maybe > be not (as Rich said). If the decide to use ENUM-technolgy, ok, > but this will be very complex (as everything on the PSTN is), > it will be not optional (it cannot be), and it will therefore > be orthogonal and independent from (User) ENUM. > > This also implies that this CANNOT happen in the same tree, because > ownership, administration and delegation path are completely > different. > > Richard Considering this, and the circular debates of the last few weeks, I'm starting to think that "our work here is done", and that continuing on to consider Infrastructure ENUM is at best unnecessary, and a worst down right harmful. Am I missing something? James _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From cdel@firsthand.net Wed, 30 Jun 2004 17:04:39 -0400 From: "Christian de Larrinaga" Date: Wed, 30 Jun 2004 17:04:39 -0400 To: "Peter Williams" Subject: RE: [Enum] IETF, ENUM and NGN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R I think seeing this proposed in a structured way would be very helpful to understanding what the implications might be. thanks Christian -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Peter Williams Sent: 30 June 2004 17:13 To: md at bts.sk; jim at rfc1035.com Cc: enum at ietf.org Subject: Re: [Enum] IETF, ENUM and NGN >Well, but The question is whether IETF should recommend/advice/support >such silly implementations. IAB has already recognized ENUM providers will, and must inevitably use name spaces other than those standardized by IAB. It specifically called out this in the Informational RFCs disclosing their rationales for the IAB mandates, and certain communications with ITU-T. IETF has never objected before to operators running private zones. Such zones often carry enhanced resource definitions/data, shared only with custom resolvers. Do you feel an joint I-D coming on, Jim? _______________________________________________ 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 james.f.baskin@verizon.com Wed, 30 Jun 2004 18:08:48 -0400 From: james.f.baskin@verizon.com Date: Wed, 30 Jun 2004 18:08:48 -0400 To: enum at ietf.org Subject: RE: [Enum] A Modest Proposal Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Yes, the work may well be done. Neither "Infrastructure ENUM" nor "end-user ENUM" may need further IETF enum wg technical work. However, it seems a shame that so many people on this list have come to blanket conclusions about the need for multiple trees without valid logic in their arguments. Under certain circumstances, if service providers REALLY need to do certain things in the DNS in certain ways, then the arguments hold up. But taking the leap to the conclusion that infrastructure ENUM NAPTRs cannot peacefully and easily coexist with other ENUM NAPTRs in a standard e164.arpa tree seems to be self-serving. The detailed rules for e164.arpa ENUM implementation will be determined on a country code by country code basis. This includes privacy/opt-in aspects, and I expect that privacy will be given its proper weight. Additionally, countries will realize that with very limited exceptions E.164 numbers should only be assigned to/through service providers who will ensure universal connectivity. As a minimum, for example, this means that no matter who holds an E.164 (public) number for voice service, it should be technically dialable and reachable from any other public voice service user, and vice versa. (Of course, end users may make use of optional services that could restrict the completion of incoming calls based on various criteria.) So: 1) If infrastructure NAPTRs are restricted to revealing only number at provider.foo then privacy is maintained. I believe any arguments to the contrary are unfounded. I also believe that concerns on the part of potential service providers about the need for secrecy regarding which E.164 numbers they hold is overblown. That information will be readily available to other service providers through national numbering resource administrators, portability databases, etc. 2) If individual numbers, not number blocks, are populated in e164.arpa, then the concern about locating individual numbers in contaminated blocks is a non-issue. In some major country codes around the world blocks won't even be a consideration. 3) If end users want to add NAPTRs for their own purposes, independent of the infrastructure needs of the service provider that is the source of their E.164 number, there are several ways to accommodate them -- none of which require gaming the nameservers. One way is to put them side by side with the infrastructure NAPTR. It should be trivial for client software to determine which NAPTR is appropriate for a given purpose. 4) If a country wants to give end users more flexibility or control over the nameserver where their "end-user" NAPTRs reside, the DNS entry containing the infrastructure NAPTR could also be populated with NS records pointing to the end user's nameserver of choice. Again, it should be trivial for client software to continue down the tree if the infrastructure NAPTR isn't what it is looking for. I believe the "public" ENUM under the single e164.arpa tree can accommodate both service provider and end user needs without significant administrative complexity. Those who are unwilling to consider implementing e164.arpa ENUM in such a way are free to try one or another of the multi-tree, split DNS, etc. approaches that I believe will ultimately prove unworkable for effective inter-carrier routing and universal connectivity. BUT, those who think they need to go down those other paths should NOT claim that there cannot be a single-tree, e164.arpa solution. Can we talk about this during the enum wg session in August? Jim ======================= James McEachern wrote: >Richard, >In your excellent summary of ENUM you said that: >> >> ENUM is only an add on and not basically necessary to route calls. >> Since URIs are used as address-of-record and contact-address, they are >> intended to be used to identify the terminating server and terminal and >> are NOT intended to be used for routing via transit "networks" >> Therefore ENUM should not be used for this purpose for two reasons: >> 1. ENUM is not designed for this and lacking the required information >> 2. it is contradicting the end-to-end philosophy of the Internet. >> >> If NGN proponents are trying to set up mechanism on IP to allow >> routing of E.164 numbers and also to transfer the complicated routing >> regime they have between "networks" and also the IN NP databases, >> they may do so, even they may use ENUM technology. And it >> is perfectly valid for ETSI and 3GPP dealing with these issues >> >and ... >> >> If the PSTN is moving to IP and therefore seeking for a routing >> mechanism for E.164 numbers on IP, this may be the DNS, but maybe >> be not (as Rich said). If the decide to use ENUM-technolgy, ok, >> but this will be very complex (as everything on the PSTN is), >> it will be not optional (it cannot be), and it will therefore >> be orthogonal and independent from (User) ENUM. >> >> This also implies that this CANNOT happen in the same tree, because >> ownership, administration and delegation path are completely >> different. >> >> Richard >Considering this, and the circular debates of the last few weeks, I'm >starting to think that "our work here is done", and that continuing on to >consider Infrastructure ENUM is at best unnecessary, and a worst down right >harmful. >Am I missing something? >James _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 30 Jun 2004 21:25:33 -0400 From: Jeff Williams Date: Wed, 30 Jun 2004 21:25:33 -0400 To: Marian Durkovic Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: Message-ID: <40E37F7B.9B98A575@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Marian and all, Marian Durkovic wrote: > > AFAICT nobody is suggesting Infrastructure and User ENUM would use the > > same tree. The constraints and data models for these things are > > completely different. However some people seem to think that if these > > two flavours of ENUM use the same domain name, this means they both > > have to use the same tree with one model for ownership, administration > > and delegation. That doesn't necessarily follow. What some operator > > does with its private, internal-use-only version of e164.arpa and how > > they populate and manage that is nobody else's concern, apart from the > > usual regulatory issues like universal service obligations, fair > > competition and so on. > > Yes it is - as soon, as you start getting complaints from cutomers of > this operator like "why did you put into the e164.arpa. records > which routed me to such expensive path?" > > I'd be quite interested what will be your reaction, if someone makes > a "private" tree overlaying the .UK TLD with any sort of (possibly invalid) > data. > > Generally, using the same domain name for completely different purposes is > IMHO _very_ bad idea. Agreed. However it doesn't matter which or how many domains are used in the public internet/DNS, exposing any user specific private data is not necessary for operation, and endangers the user or users. > There's absolutely no problem to avoid this by > agreeing on different domain name - and for completely private purposes > even non-existent TLD like e164.nxd. could be used which definitely can't > be reached from the public internet. > > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 30 Jun 2004 21:25:36 -0400 From: Jeff Williams Date: Wed, 30 Jun 2004 21:25:36 -0400 To: John Curran Subject: Re: [Enum] IETF, ENUM and NGN In-Reply-To: <17086.1088586316@gromit.rfc1035.com> Message-ID: <40E380F7.44117BFF@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R John and all, Of course your right, John. However what we are all seeing here is a distinct difference in agenda's and philosophy regarding the need for users should have the right to use ENUM in the public DNS and still have an opt-out or opt-in of their personal and private data such as their name, ENUM number, address, and direct contact phone number. John Curran wrote: > At 10:05 AM +0100 6/30/04, Jim Reid wrote: > >AFAICT nobody is suggesting Infrastructure and User ENUM would use the > >same tree. The constraints and data models for these things are > >completely different. However some people seem to think that if these > >two flavours of ENUM use the same domain name, this means they both > >have to use the same tree with one model for ownership, administration > >and delegation. That doesn't necessarily follow. What some operator > >does with its private, internal-use-only version of e164.arpa and how > >they populate and manage that is nobody else's concern, apart from the > >usual regulatory issues like universal service obligations, fair > >competition and so on. > > > >What matters is the operators agree on a domain name for > >Infrastructure ENUM. This might as well be e164.arpa since (a) it's > >vendor neutral; (b) already an agreed IETF standard; (c) not > >controlled by any nation. It's hard to see how any other choice of > >domain name could be better (technically or politically). > > Hmm... If some operators really and truly intend to run a data tree > which is not publicly visible, than I see no need for any standard in > this area. The operator (or set of operators which share such a data > tree) can simply configure an appropriate domain of their choice. > > I don't believe that there needs to be a distinct Infstrastructure ENUM > and User ENUM data tree. The only strong reason given for separate > models is privacy and I'll assert that it is possible to put information in > the tree for a given E.164 number that consists of nothing more than > a record which directs one to the appropriate service provider (as noted > by Mike Hammer earlier) and that this will indeed prove sufficient to > provide connectivity without raising privacy concerns. > > The operator community should be encouraged to put some nominal > information for their number blocks in the Public ENUM tree, even if this > is nothing more than a single wildcard record pointing to a default server > for that operator. As numbers port, it should be very straightforward > to insert an appropriate specific DNS record to direct queries to the > new provider as appropriate, including the degenerate case where a > knowledgeable user (or user with knowledgeable party under contract) > arranges to have richer connectivity information put in place under their > entry. > > /John > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum