From jseng@pobox.org.sg Mon, 02 Aug 2004 01:42:53 -0400 From: James Seng Date: Mon, 02 Aug 2004 01:42:53 -0400 To: enum at ietf.org Subject: [Enum] Agenda for Carrier ENUM mini-BoF Message-ID: <410DD2F7.40405@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R Agenda for Carrier ENUM mini-BoF Wed 2pm to 3pm 1400 Agenda bashing 1405 Setting the stage - Richard Shockey & Patrick Falstrom 1410 ESTI perspective on Carrier ENUM - Richard Stansty 1415 NEXT - Richard Stansty (on the behalf of Thilo) http://www.e164.info/documents/proposal-next.txt 1425 E2C - Penn Lind draft-pfautz-lind-enum-carrier-00.txt 1435 Requirements - James Seng 1440 Discussion 1500 End -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mcfadden@21st-century-texts.com Mon, 02 Aug 2004 14:30:24 -0400 From: "Mark McFadden" Date: Mon, 02 Aug 2004 14:30:24 -0400 To: Subject: [Enum] Carrier enum mini-BOF location? Message-ID: <20040802140202.GA14646@mail07d.vwh1.net> MIME-Version: 1.0 Content-Type: text/plain Status: R For those of us in San Diego . . . Where is the mini-BOF going to be held?? mark _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jseng@pobox.org.sg Mon, 02 Aug 2004 14:59:06 -0400 From: James Seng Date: Mon, 02 Aug 2004 14:59:06 -0400 To: mcfadden at 21st-century-texts.com Subject: Re: [Enum] Carrier enum mini-BOF location? In-Reply-To: <20040802140202.GA14646@mail07d.vwh1.net> Message-ID: <410E8C3B.6030905@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R immediately after enum. james Mark McFadden wrote: For those of us in San Diego . . . Where is the mini-BOF going to be held?? mark _______________________________________________ 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 Mon, 02 Aug 2004 16:12:00 -0400 From: Richard Shockey Date: Mon, 02 Aug 2004 16:12:00 -0400 To: enum at ietf.org Subject: Re: [Enum] Carrier enum mini-BOF location? In-Reply-To: <20040802140202.GA14646@mail07d.vwh1.net> Message-ID: <6.1.0.6.2.20040802160320.03a87e80@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 02:47 PM 8/2/2004, you wrote: immediately after enum ENUM WG is 2 hours on Wed afternoon the first hour will be devoted to normal business as previously announced on the agenda the 2nd hour will be the mini-BOF james Mark McFadden wrote: For those of us in San Diego . . . Where is the mini-BOF going to be held?? mark _______________________________________________ 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 james@seng.cc Tue, 03 Aug 2004 12:21:01 -0400 From: James Seng Date: Tue, 03 Aug 2004 12:21:01 -0400 To: Richard.Stastny at oefeg.at> Subject: [Enum] Carrier ENUM mini-BoF agenda Message-ID: <410DB7A7.1080107@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: R Agenda for Carrier ENUM mini-BoF Wed 2pm to 3pm 1400 Agenda bashing 1405 Setting the stage - Richard Shockey & Patrick Falstrom 1410 ESTI perspective on Carrier ENUM - Richard Stansty 1415 NEXT - Richard Stansty (on the behalf of Thilo) http://www.e164.info/documents/proposal-next.txt 1425 E2C - Penn Lind draft-pfautz-lind-enum-carrier-00.txt 1435 Requirements - James Seng 1440 Discussion 1500 End -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 05 Aug 2004 17:19:57 -0400 From: Richard Shockey Date: Thu, 05 Aug 2004 17:19:57 -0400 To: enum at ietf.org Subject: [Enum] Slides from ENUM WG Meeting Message-ID: <6.1.0.6.2.20040805170453.039a5270@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R For those of you who are interested attached are the ID's and Relevant Presentations from Wednesday's WG meeting http://www.shockey.us/enum/IETF60_SanDiego_ENUM_WG.zip >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 fujiwara@jprs.co.jp Thu, 05 Aug 2004 22:04:22 -0400 From: fujiwara@jprs.co.jp Date: Thu, 05 Aug 2004 22:04:22 -0400 To: richard at shockey.us Subject: experiences draft presentation file(Re: [Enum] Slides from ENUM WG Meeting) In-Reply-To: <6.1.0.6.2.20040805170453.039a5270@joy.songbird.com> Message-ID: <20040806.105840.21912945.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain Status: R I didn't send my presentation file : ENUM experiences draft update I attach my presentation file in this mail. (magic point format) -- Fujiwara, Kazunori JPRS > From: Richard Shockey > For those of you who are interested attached are the ID's and Relevant > Presentations from Wednesday's WG meeting > > http://www.shockey.us/enum/IETF60_SanDiego_ENUM_WG.zip %include "default.mgp" %% %%IETF60 San Diego %% %% %page %center draft-ietf-enum-experiences-00.txt %size 4 IETF60 ENUM-WG 2004/8/04 Kazunori Fujiwara, JPRS Lawrence Conroy, Roke Manor Research %page draft-ietf-enum-experiences-00 status become working group draft Updated from draft-conroy-enum-experiences-01.txt Added new items which fujiwara pointed at Seoul IETF meeting Separated into "Server" side issues and "Client" side issues Server: ENUM zone population side Number holder MUST write valid data in DNS. Client: ENUM data lookup side To be safe and avoid bugs, Clients MAY ignore unrecognized DNS data %size 3 Because clients must accept any data from DNS without crashing Assume bad guys may write malicious data in DNS. %page Issues from the original draft 2.2. Case Sensitivity SHOULD NOT assume that the field delimiter is the last character (CLIENT) 3.2. Treatment of NAPTRs with identical ORDER/PRIORITY values SHOULD process all NAPTRs (CLIENT) 4.2. Non-final NAPTRs - loop detection and response SHOULD parse 5 non-final NAPTRs (CLIENT) %page New issues (1) 2.1 Character Sets - Non-ASCII considered harmful (NEW) %% no previous discussion SHOULD use ASCII characters (IDN and URI specific ascii encoding) Client MAY ignore NAPTR RR which contains Non-ASCII 2.3 Regexp field delimiter (from seoul) Use '!' (SERVER) Client MAY ignore NAPTR RR whose delimiter is not '!' . 2.4 Regexp meta-character issue (from seoul) escape meta character \+ (SERVER) %page New issues (2) 3.1. Order/Priority values - general processing use fixed ORDER 100 (from seoul) 4.1. Non-final NAPTRs - general issues (from seoul) (details are explained later) 5. Backward Compatibility (NEW) 5.1. Service field syntax: MUST populate RFC3761 style data (SERVER) MUST accept RFC3761 style (CLIENT) SHOULD accept RFC2916 style (CLIENT) %page Open Issues 4.1 Non-Final processing - general issues To support non-final DDDS NAPTRs: non-final NAPTR's service field SHOULD be ignored. error processing in DDDS non-final NAPTRs must be consistent but, Non-final NAPTR processing is expensive and cause large delay in Telephone switches and embeded terminals therefore, some may not be able to support non-final NAPTRs I-D authors' recommend: SHOULD NOT generate non-final NAPTRs (SERVER) MAY discard non-final NAPTRs (CLIENT) %page Need comments Beware - there are some typos in the draft. Those we have noticed have been posted to the list. Please check and post to the list or mail the authors. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 06 Aug 2004 13:57:32 -0400 From: Richard Shockey Date: Fri, 06 Aug 2004 13:57:32 -0400 To: fujiwara at jprs.co.jp Subject: Re: experiences draft presentation file(Re: [Enum] Slides from ENUM WG Meeting) In-Reply-To: <6.1.0.6.2.20040805170453.039a5270@joy.songbird.com> Message-ID: <6.1.0.6.2.20040806132817.0399c118@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 09:58 PM 8/5/2004, fujiwara at jprs.co.jp wrote: I didn't send my presentation file : ENUM experiences draft update I attach my presentation file in this mail. (magic point format) Would you please send it to me personally and I'll add it to the archive ..several people requested the documentation as soon as I could make it avaiable. -- Fujiwara, Kazunori JPRS > From: Richard Shockey > For those of you who are interested attached are the ID's and Relevant > Presentations from Wednesday's WG meeting > > http://www.shockey.us/enum/IETF60_SanDiego_ENUM_WG.zip %include "default.mgp" %% %%IETF60 San Diego %% %% %pages://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 enumvoipsip.cs@schiefner.de Sun, 08 Aug 2004 12:35:25 -0400 From: Carsten Schiefner Date: Sun, 08 Aug 2004 12:35:25 -0400 To: fujiwara at jprs.co.jp Subject: Re: experiences draft presentation file(Re: [Enum] Slides from ENUM WG Meeting) In-Reply-To: <6.1.0.6.2.20040805170453.039a5270@joy.songbird.com> Message-ID: <41165583.1070101@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Kazunori - Richard Shockey wrote: At 09:58 PM 8/5/2004, fujiwara at jprs.co.jp wrote: I didn't send my presentation file : ENUM experiences draft update I attach my presentation file in this mail. (magic point format) Would you please send it to me personally and I'll add it to the archive ..several people requested the documentation as soon as I could make it avaiable. could you convert the MPF (magic point format) to a format that is likely to be shared by more people - such as PDF, for example? That would be helpful. Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From shollenbeck@verisign.com Mon, 09 Aug 2004 10:31:10 -0400 From: "Hollenbeck, Scott" Date: Mon, 09 Aug 2004 10:31:10 -0400 To: "'enum at ietf.org> Subject: [Enum] Document Review Requested Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D7837@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R The VPIM working group has asked me to review a pair of documents and request an IETF last call for them when I have completed my review. One of the documents includes ENUM service registrations. Would someone (or multiple someones) from the ENUM working group please take a look at these documents and let me know what you think of the service registration requests? http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-06.txt and http://www.ietf.org/internet-drafts/draft-ietf-vpim-vpimdir-07.txt Comments should be sent to me, Greg Vaudreuil (gregv at ieee.org, document editor) and Glenn Parsons (gparsons at nortelnetworks.com, VPIM WG chair). I've already noted that the references to the ENUM and NAPTR specifications are outdated. Thank you, -Scott- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From fujiwara@jprs.co.jp Mon, 09 Aug 2004 22:18:13 -0400 From: fujiwara@jprs.co.jp Date: Mon, 09 Aug 2004 22:18:13 -0400 To: enumvoipsip.cs at schiefner.de Subject: [Enum] Re: experiences draft presentation file In-Reply-To: <20040806.105840.21912945.fujiwara@jprs.co.jp> Message-ID: <20040810.111048.102569697.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain Status: R now I put pdf version on my page. http://member.wide.ad.jp/~fujiwara/enum/draft-ietf-enum-experiences-00.mgp.pdf -- Fujiwara, Kazunori JPRS > From: Carsten Schiefner > Richard, Kazunori - > > Richard Shockey wrote: > > At 09:58 PM 8/5/2004, fujiwara at jprs.co.jp wrote: > >> I didn't send my presentation file : ENUM experiences draft update > >> I attach my presentation file in this mail. (magic point format) > > > > Would you please send it to me personally and I'll add it to the archive > > ..several people requested the documentation as soon as I could make it > > avaiable. > > could you convert the MPF (magic point format) to a format that is > likely to be shared by more people - such as PDF, for example? That > would be helpful. > > Cheers, > > -C. > > > _______________________________________________ > 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 Mon, 09 Aug 2004 22:26:20 -0400 From: Richard Shockey Date: Mon, 09 Aug 2004 22:26:20 -0400 To: "Hollenbeck, Scott" Subject: Re: [Enum] Document Review Requested In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF040D7837@vsvapostal8.vcorp.ad.vrsn.com> Message-ID: <6.1.0.6.2.20040809221639.03a1cec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 10:29 AM 8/9/2004, Hollenbeck, Scott wrote: I'll provide comments shortly and I encourage the ENUM list to do so as well. I've worked closely with both Glenn and Greg and the VPIM WG on these documents for some time and yes the normative references are out of date. The VPIM working group has asked me to review a pair of documents and request an IETF last call for them when I have completed my review. One of the documents includes ENUM service registrations. Would someone (or multiple someones) from the ENUM working group please take a look at these documents and let me know what you think of the service registration requests? http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-06.txt and http://www.ietf.org/internet-drafts/draft-ietf-vpim-vpimdir-07.txt Comments should be sent to me, Greg Vaudreuil (gregv at ieee.org, document editor) and Glenn Parsons (gparsons at nortelnetworks.com, VPIM WG chair). I've already noted that the references to the ENUM and NAPTR specifications are outdated. Thank you, -Scott- _______________________________________________ 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 enumvoipsip.cs@schiefner.de Tue, 10 Aug 2004 07:50:41 -0400 From: Carsten Schiefner Date: Tue, 10 Aug 2004 07:50:41 -0400 To: fujiwara at jprs.co.jp Subject: Re: [Enum] Re: experiences draft presentation file In-Reply-To: <20040806.105840.21912945.fujiwara@jprs.co.jp> Message-ID: <4118B584.3090702@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Kazunori, fujiwara at jprs.co.jp wrote: now I put pdf version on my page. http://member.wide.ad.jp/~fujiwara/enum/draft-ietf-enum-experiences-00.mgp.pdf thank you! :-) Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Tue, 10 Aug 2004 08:56:29 -0400 From: "Fullbrook Kim (UK)" Date: Tue, 10 Aug 2004 08:56:29 -0400 To: "'enum at ietf.org> Subject: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R Although the debate about ENUM privacy issues has subsided, having read the new RFC 3824 I feel that it's worth summarising the key points of the privacy discussion and the implications for the RFC, as well as making some general suggestions for ENUM deployment. This is my understanding of the summary of the privacy debate:  With the privacy concerns about personal information put in a publicly accessible DNS, particularly with the "opt in" privacy policies in some countries, we would not expect SIP URIs of the format johndoe at bigtelco.com in the DNS to be available for all subscribers globally.  However, if John Doe's E.164 number is 1234567890 you could put the SIP URI  sip:1234567890 at bigtelco.com in the public DNS because this doesn't cause any privacy difficulties while also providing a necessary link in the call routing chain.  If there was no SIP URI record for a particular E.164 number in the DNS you couldn't route SIP calls which are addressed via E.164 number and the service would break unless some other routing solution was provided. In "opt in" countries John Doe could "opt in" to include his SIP URI in the DNS or in certain countries everyone would automatically be added unless they "opted out".  There is no need to have separate "user" and "operator" ENUM infrastructures for resolving E.164 numbers into a SIP URI: everything as described above can go in the public "user" DNS because the privacy concerns are gone. (You might need operator ENUM for something else but that's not the topic for debate here).  Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in the DNS but only suggests using a SIP URI like anonymous00045 at example.com  for those concerned about privacy.  I'd suggest that this section of the RFC should reflect the outcome of our privacy debate and include the principles summarised in this note, or whatever we agree if my words and suggestions aren't right. An implication of the summary above is that the "lowest common denominator" for SIP URI would be the numeric format  e.g. sip:1234567 at domain.com  if we choose to recommend it. With this in mind, let's test the suggestion by moving forward a few years into a future where SIP-based telephony is more widespread, including 3GPP-based IMS systems and where DNS provisioning issues are important.  Take the example of a SIP user who wishes to make a call to another SIP customer using their E.164 number.  If the called customer has "opted in" to ENUM and a SIP URI exists such as sip:johndoe at siptelco.com  this will work in the normal way. If they are not "opted in", then provided the DNS datafill has been done in line with the "lowest common denominator" format, a numeric SIP URI exists in the ENUM DNS e.g. sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call routes via siptelco.com     This works fine but what about the implications for DNS provisioning ?  If we said that all customers (SIP and non-SIP) have an entry in the ENUM DNS using the numeric SIP URI format we would need to build a huge DNS table containing entries like: 4412345678  ->   sip:4412345678 at owning-operator.com Although there would be a huge number of DNS entries, an individual entry would only need to change if the number was ported to a different operator e.g. sip:987654321@ owning-operator.com  changed to  sip:987654321 at alternatesipco.com Having an individual DNS record for each phone number is simple conceptually but involves creating a huge number of records which look something like this: e.g.  8.7.6.5.4.3.2.1.4.4.e164.arpa  ->  !^.*$!sip:4412345678 at big-uk-telco.co.uk However, if it is possible to do full wildcarding in DNS in conjunction with a rewrite rule this could be fairly easy to set up.  The idea is that a single line for a whole dial code range combined with a clever rewrite rule could rewrite any matching E.164 number in that range to a suitable SIP URI: *.8.0.2.4.4.e164.arpa  ->   sip: @uk-sip-telco.co.uk    So that, using letters to represent the generalised E.164 number  44208abcdef f.e.d.c.b.a.8.0.2.4.4.e164.arpa ->  sip:44208abcdef at uk-sip-telco.co.uk Having experimented with a test DNS the wildcarding part works fine: you can have a general wildcarding rule for the whole number range pointing to the "owning" operator together with specific entries to over-ride the wild card where a particular E.164 number has been ported to a different operator.  Unfortunately my skills in regular expressions are not good enough to figure out whether you could create a rewrite rule to do what's needed in the above example. Any "regular _expression_" experts out there interested in this challenge ? Summarising the suggestions. - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - There shouldn't be any privacy concerns with the above - In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. johndoe at bigsipco.com - You could add non-SIP customers to the DNS using the numeric SIP URI format, allowing SIP calls to them to route to the right interconnect point (SIP to POTS interworking) - DNS wildcarding in conjunction with a clever rewrite rule might allow easy creation of these numeric SIP URIs without needing to create millions of individual DNS records Kim Fullbrook O2 UK ========================================================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 axelm@nic.at Tue, 10 Aug 2004 09:20:37 -0400 From: Alexander Mayrhofer Date: Tue, 10 Aug 2004 09:20:37 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <20040810131948.GA13101@kahua.nona.net> MIME-Version: 1.0 Content-Type: text/plain Status: R On (10.08.04 13:53), Fullbrook Kim (UK) wrote: > Although there would be a huge number of DNS entries, an individual entry > would only need to change if the number was ported to a different operator > e.g. sip:987654321@ owning-operator.com changed to > sip:987654321 at alternatesipco.com > > Having an individual DNS record for each phone number is simple conceptually > but involves creating a huge number of records which look something like > this: > e.g. 8.7.6.5.4.3.2.1.4.4.e164.arpa -> > !^.*$!sip:4412345678 at big-uk-telco.co.uk I would expect that those entries do not reside in a static zone file, but are generated on the fly when a corresponding query comes in. DNS servers which use databases as backend are readily available (and free!) as of today. Provisioning would be done by simply inserting an additional row in the backend database when the customer enrolls for service. What about an ENUM DNS powered by your HLR? ;) cheers axelm _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Tue, 10 Aug 2004 09:41:37 -0400 From: Otmar Lendl Date: Tue, 10 Aug 2004 09:41:37 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <20040810133815.GA15706@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2004/08/10 14:08, "Fullbrook Kim (UK)" wrote: > > However, if it is possible to do full wildcarding in DNS in conjunction with > a rewrite rule this could be fairly easy to set up. The idea is that a > single line for a whole dial code range combined with a clever rewrite rule > could rewrite any matching E.164 number in that range to a suitable SIP URI: > *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk > So that, using letters to represent the generalised E.164 number > 44208abcdef > f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk The rewriting rule for such a mapping is rather trivial as the input to the NAPTR regex algorithm is the E.164 number (with leading +) and not the ENUM domain name. Thus !^\+44208(......)$!sip:44208\1 at uk-sip-telco.co.uk! should do the trick. > Having experimented with a test DNS the wildcarding part works fine: you can > have a general wildcarding rule for the whole number range pointing to the > "owning" operator together with specific entries to over-ride the wild card > where a particular E.164 number has been ported to a different operator. > Unfortunately my skills in regular expressions are not good enough to figure > out whether you could create a rewrite rule to do what's needed in the above > example. Any "regular expression" experts out there interested in this > challenge ? The regex is not the problem. The problem is mixing wildcards and individual delegations. Go to your local watering hole with a seasoned DNS operator and he will tell you nasty stories about the horrors and pure evilness of wildcards DNS records. But generally speaking: While it may be true right now that ENUM DNS servers run standard DNS software like bind or powerdns, I fully expect them to be special software which exports a view of a national (or in case of +1 or +878: international) line information / number allocation database (and not you HLR, he will act as SIP proxy ;-) via DNS answers. > - DNS wildcarding in conjunction with a clever rewrite rule might allow easy > creation of these numeric SIP URIs without needing to create millions of > individual DNS records Wildcards may be a quick fix now, but when you consider porting number away from your blocks then a more clever way of on-demand generation of DNS answers seems to be a better solution. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Tue, 10 Aug 2004 10:16:40 -0400 From: "Pfautz, Penn L, ALABS" Date: Tue, 10 Aug 2004 10:16:40 -0400 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: <34DA635B184A644DA4588E260EC0A25A07E22143@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Title: ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R Kim: I still see a couple of issues that would motivate separate user and operator ENUM Tier 2s. In at least some opt-in countries, the user would be allowed to choose the Tier 2 that actually held the NAPTR records. So you have a problem as soon as user and operator both want entries which are different and want them in different Tier 2s. The existing implementation with NS records in Tier doesn't support this. The I-D Steve Lind and I offered ( "draft-pfautz-lind-enum-carrier-00.txt) was an attempt to get around that problem but the problem is real.   Penn Pfautz -----Original Message-----From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Fullbrook Kim (UK)Sent: Tuesday, August 10, 2004 8:54 AMTo: 'enum at ietf.org'Subject: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Although the debate about ENUM privacy issues has subsided, having read the new RFC 3824 I feel that it's worth summarising the key points of the privacy discussion and the implications for the RFC, as well as making some general suggestions for ENUM deployment. This is my understanding of the summary of the privacy debate:  With the privacy concerns about personal information put in a publicly accessible DNS, particularly with the "opt in" privacy policies in some countries, we would not expect SIP URIs of the format johndoe at bigtelco.com in the DNS to be available for all subscribers globally.  However, if John Doe's E.164 number is 1234567890 you could put the SIP URI  sip:1234567890 at bigtelco.com in the public DNS because this doesn't cause any privacy difficulties while also providing a necessary link in the call routing chain.  If there was no SIP URI record for a particular E.164 number in the DNS you couldn't route SIP calls which are addressed via E.164 number and the service would break unless some other routing solution was provided. In "opt in" countries John Doe could "opt in" to include his SIP URI in the DNS or in certain countries everyone would automatically be added unless they "opted out".  There is no need to have separate "user" and "operator" ENUM infrastructures for resolving E.164 numbers into a SIP URI: everything as described above can go in the public "user" DNS because the privacy concerns are gone. (You might need operator ENUM for something else but that's not the topic for debate here).  Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in the DNS but only suggests using a SIP URI like anonymous00045 at example.com  for those concerned about privacy.  I'd suggest that this section of the RFC should reflect the outcome of our privacy debate and include the principles summarised in this note, or whatever we agree if my words and suggestions aren't right. An implication of the summary above is that the "lowest common denominator" for SIP URI would be the numeric format  e.g. sip:1234567 at domain.com  if we choose to recommend it. With this in mind, let's test the suggestion by moving forward a few years into a future where SIP-based telephony is more widespread, including 3GPP-based IMS systems and where DNS provisioning issues are important.  Take the example of a SIP user who wishes to make a call to another SIP customer using their E.164 number.  If the called customer has "opted in" to ENUM and a SIP URI exists such as sip:johndoe at siptelco.com  this will work in the normal way. If they are not "opted in", then provided the DNS datafill has been done in line with the "lowest common denominator" format, a numeric SIP URI exists in the ENUM DNS e.g. sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call routes via siptelco.com     This works fine but what about the implications for DNS provisioning ?  If we said that all customers (SIP and non-SIP) have an entry in the ENUM DNS using the numeric SIP URI format we would need to build a huge DNS table containing entries like: 4412345678  ->   sip:4412345678 at owning-operator.com Although there would be a huge number of DNS entries, an individual entry would only need to change if the number was ported to a different operator e.g. sip:987654321@ owning-operator.com  changed to  sip:987654321 at alternatesipco.com Having an individual DNS record for each phone number is simple conceptually but involves creating a huge number of records which look something like this: e.g.  8.7.6.5.4.3.2.1.4.4.e164.arpa  ->  !^.*$!sip:4412345678 at big-uk-telco.co.uk However, if it is possible to do full wildcarding in DNS in conjunction with a rewrite rule this could be fairly easy to set up.  The idea is that a single line for a whole dial code range combined with a clever rewrite rule could rewrite any matching E.164 number in that range to a suitable SIP URI: *.8.0.2.4.4.e164.arpa  ->   sip: @uk-sip-telco.co.uk    So that, using letters to represent the generalised E.164 number  44208abcdef f.e.d.c.b.a.8.0.2.4.4.e164.arpa ->  sip:44208abcdef at uk-sip-telco.co.uk Having experimented with a test DNS the wildcarding part works fine: you can have a general wildcarding rule for the whole number range pointing to the "owning" operator together with specific entries to over-ride the wild card where a particular E.164 number has been ported to a different operator.  Unfortunately my skills in regular expressions are not good enough to figure out whether you could create a rewrite rule to do what's needed in the above example. Any "regular _expression_" experts out there interested in this challenge ? Summarising the suggestions. - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - There shouldn't be any privacy concerns with the above - In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. johndoe at bigsipco.com - You could add non-SIP customers to the DNS using the numeric SIP URI format, allowing SIP calls to them to route to the right interconnect point (SIP to POTS interworking) - DNS wildcarding in conjunction with a clever rewrite rule might allow easy creation of these numeric SIP URIs without needing to create millions of individual DNS records Kim Fullbrook O2 UK ========================================================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 Tue, 10 Aug 2004 10:59:14 -0400 From: James Seng Date: Tue, 10 Aug 2004 10:59:14 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4118E1B1.9080704@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. james Fullbrook Kim (UK) wrote: Although the debate about ENUM privacy issues has subsided, having read the new RFC 3824 I feel that it's worth summarising the key points of the privacy discussion and the implications for the RFC, as well as making some general suggestions for ENUM deployment. This is my understanding of the summary of the privacy debate: With the privacy concerns about personal information put in a publicly accessible DNS, particularly with the "opt in" privacy policies in some countries, we would not expect SIP URIs of the format johndoe at bigtelco.com in the DNS to be available for all subscribers globally. However, if John Doe's E.164 number is 1234567890 you could put the SIP URI sip:1234567890 at bigtelco.com in the public DNS because this doesn't cause any privacy difficulties while also providing a necessary link in the call routing chain. If there was no SIP URI record for a particular E.164 number in the DNS you couldn't route SIP calls which are addressed via E.164 number and the service would break unless some other routing solution was provided. In "opt in" countries John Doe could "opt in" to include his SIP URI in the DNS or in certain countries everyone would automatically be added unless they "opted out". There is no need to have separate "user" and "operator" ENUM infrastructures for resolving E.164 numbers into a SIP URI: everything as described above can go in the public "user" DNS because the privacy concerns are gone. (You might need operator ENUM for something else but that's not the topic for debate here). Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in the DNS but only suggests using a SIP URI like anonymous00045 at example.com for those concerned about privacy. I'd suggest that this section of the RFC should reflect the outcome of our privacy debate and include the principles summarised in this note, or whatever we agree if my words and suggestions aren't right. An implication of the summary above is that the "lowest common denominator" for SIP URI would be the numeric format e.g. sip:1234567 at domain.com if we choose to recommend it. With this in mind, let's test the suggestion by moving forward a few years into a future where SIP-based telephony is more widespread, including 3GPP-based IMS systems and where DNS provisioning issues are important. Take the example of a SIP user who wishes to make a call to another SIP customer using their E.164 number. If the called customer has "opted in" to ENUM and a SIP URI exists such as sip:johndoe at siptelco.com this will work in the normal way. If they are not "opted in", then provided the DNS datafill has been done in line with the "lowest common denominator" format, a numeric SIP URI exists in the ENUM DNS e.g. sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call routes via siptelco.com This works fine but what about the implications for DNS provisioning ? If we said that all customers (SIP and non-SIP) have an entry in the ENUM DNS using the numeric SIP URI format we would need to build a huge DNS table containing entries like: 4412345678 -> sip:4412345678 at owning-operator.com Although there would be a huge number of DNS entries, an individual entry would only need to change if the number was ported to a different operator e.g. sip:987654321@ owning-operator.com changed to sip:987654321 at alternatesipco.com Having an individual DNS record for each phone number is simple conceptually but involves creating a huge number of records which look something like this: e.g. 8.7.6.5.4.3.2>.1.4.4.e164.arpa -> !^.*$!sip:4412345678 at big-uk-telco.co.uk However, if it is possible to do full wildcarding in DNS in conjunction with a rewrite rule this could be fairly easy to set up. The idea is that a single line for a whole dial code range combined with a clever rewrite rule could rewrite any matching E.164 number in that range to a suitable SIP URI: *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk So that, using letters to represent the generalised E.164 number 44208abcdef f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk Having experimented with a test DNS the wildcarding part works fine: you can have a general wildcarding rule for the whole number range pointing to the "owning" operator together with specific entries to over-ride the wild card where a particular E.164 number has been ported to a different operator. Unfortunately my skills in regular expressions are not good enough to figure out whether you could create a rewrite rule to do what's needed in the above example. Any "regular expression" experts out there interested in this challenge ? Summarising the suggestions. - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - There shouldn't be any privacy concerns with the above - In "opt in" countries a SIP customer could add their SIP URI if they wished e.g. johndoe at bigsipco.com *- You could add non-SIP customers to the DNS using the numeric SIP URI format, allowing SIP calls to them to route to the right interconnect point (SIP to POTS interworking)* *- DNS wildcarding in conjunction with a clever rewrite rule might allow easy creation of these numeric SIP URIs without needing to create millions of individual DNS records* * * *Kim Fullbrook O2 UK * * * ------------------------------------------------------------------------ *======================================================== 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 Kim.Fullbrook@O2.COM Tue, 10 Aug 2004 11:23:21 -0400 From: "Fullbrook Kim (UK)" Date: Tue, 10 Aug 2004 11:23:21 -0400 To: "'James Seng'" Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R James, I don't believe I've said anything about enforcing what usernames people wish to use and would be very grateful if you can point out where this is described. Thanks, Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 15:55 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. james Fullbrook Kim (UK) wrote: > Although the debate about ENUM privacy issues has subsided, having read > the new RFC 3824 I feel that it's worth summarising the key points of > the privacy discussion and the implications for the RFC, as well as > making some general suggestions for ENUM deployment. > > This is my understanding of the summary of the privacy debate: > > > With the privacy concerns about personal information put in a publicly > accessible DNS, particularly with the "opt in" privacy policies in some > countries, we would not expect SIP URIs of the format > johndoe at bigtelco.com in the DNS to be available for all subscribers > globally.  However, if John Doe's E.164 number is 1234567890 you could > put the SIP URI  sip:1234567890 at bigtelco.com in the public DNS because > this doesn't cause any privacy difficulties while also providing a > necessary link in the call routing chain.  If there was no SIP URI > record for a particular E.164 number in the DNS you couldn't route SIP > calls which are addressed via E.164 number and the service would break > unless some other routing solution was provided. In "opt in" countries > John Doe could "opt in" to include his SIP URI in the DNS or in certain > countries everyone would automatically be added unless they "opted > out& quot;.  There is no need to have separate "user" and "operator" ENUM > infrastructures for resolving E.164 numbers into a SIP URI: everything > as described above can go in the public "user" DNS because the privacy > concerns are gone. (You might need operator ENUM for something else but > that's not the topic for debate here). > > > > Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in > the DNS but only suggests using a SIP URI like > anonymous00045 at example.com  for those concerned about privacy.  I'd > suggest that this section of the RFC should reflect the outcome of our > privacy debate and include the principles summarised in this note, or > whatever we agree if my words and suggestions aren't right. > > An implication of the summary above is that the "lowest common > denominator" for SIP URI would be the numeric format  e.g. > sip:1234567 at domain.com  if we choose to recommend it. With this in mind, > let's test the suggestion by moving forward a few years into a future > where SIP-based telephony is more widespread, including 3GPP-based IMS > systems and where DNS provisioning issues are important.  Take the > example of a SIP user who wishes to make a call to another SIP customer > using their E.164 number.  If the called customer has "opted in" to ENUM > and a SIP URI exists such as sip:johndoe at siptelco.com  this will work in > the normal way. If they are not "opted in", then provided the DNS > datafill has been done in line with the "lowest common denominator" > format, a numeric SIP URI exists in the ENUM DNS e.g. > sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call > routes via siptelco.com    > > This works fine but what about the implications for DNS provisioning ?  > If we said that all customers (SIP and non-SIP) have an entry in the > ENUM DNS using the numeric SIP URI format we would need to build a huge > DNS table containing entries like: > > 4412345678  ->   sip:4412345678 at owning-operator.com > > Although there would be a huge number of DNS entries, an individual > entry would only need to change if the number was ported to a different > operator > > e.g. sip:987654321@ owning-operator.com  changed to  > sip:987654321 at alternatesipco.com > > Having an individual DNS record for each phone number is simple > conceptually but involves creating a huge number of records which look > something like this: > > e.g.  8.7.6.5.4.3.2>.1.4.4.e164.arpa  ->  > !^.*$!sip:4412345678 at big-uk-telco.co.uk > > However, if it is possible to do full wildcarding in DNS in conjunction > with a rewrite rule this could be fairly easy to set up.  The idea is > that a single line for a whole dial code range combined with a clever > rewrite rule could rewrite any matching E.164 number in that range to a > suitable SIP URI: > > *.8.0.2.4.4.e164.arpa  ->   sip: @uk-sip-telco.co.uk   > So that, using letters to represent the generalised E.164 number  > 44208abcdef > f.e.d.c.b.a.8.0.2.4.4.e164.arpa ->  sip:44208abcdef at uk-sip-telco.co.uk > > Having experimented with a test DNS the wildcarding part works fine: you > can have a general wildcarding rule for the whole number range pointing > to the "owning" operator together with specific entries to over-ride the > wild card where a particular E.164 number has been ported to a different > operator.  Unfortunately my skills in regular expressions are not good > enough to figure out whether you could create a rewrite rule to do > what's needed in the above example. Any "regular _expression_" experts out > there interested in this challenge ? > > Summarising the suggestions. > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com > > - There shouldn't be any privacy concerns with the above > - In "opt in" countries a SIP customer could add their SIP URI if they > wished  e.g. johndoe at bigsipco.com *- You could add non-SIP customers to > the DNS using the numeric SIP URI format, allowing SIP calls to them to > route to the right interconnect point (SIP to POTS interworking)* > > *- DNS wildcarding in conjunction with a clever rewrite rule might allow
> easy creation of these numeric SIP URIs without needing to create > millions of individual DNS records* > > * > * > > *Kim Fullbrook > O2 UK * > > * > > > > * > ------------------------------------------------------------------------ > > *======================================================== > 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 > * ========================================================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 Tue, 10 Aug 2004 11:23:28 -0400 From: James Seng Date: Tue, 10 Aug 2004 11:23:28 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4118E716.9090802@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com -James Seng Fullbrook Kim (UK) wrote: James, I don't believe I've said anything about enforcing what usernames people wish to use and would be very grateful if you can point out where this is described. Thanks, Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 15:55 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. james Fullbrook Kim (UK) wrote: > Although the debate about ENUM privacy issues has subsided, having read > the new RFC 3824 I feel that it's worth summarising the key points of > the privacy discussion and the implications for the RFC, as well as > making some general suggestions for ENUM deployment>. > > This is my understanding of the summary of the privacy debate: > > > With the privacy concerns about personal information put in a publicly > accessible DNS, particularly with the "opt in" privacy policies in some > countries, we would not expect SIP URIs of the format > johndoe at bigtelco.com in the DNS to be available for all subscribers > globally. However, if John Doe's E.164 number is 1234567890 you could > put the SIP URI sip:1234567890 at bigtelco.com in the public DNS because > this doesn't cause any privacy difficulties while also providing a > necessary link in the call routing chain. If there was no SIP URI > record for a particular E.164 number in the DNS you couldn't route SIP > calls which are addressed via E.164 number and the service would break > unless some other routing solution was provided. In "opt in" countries > John Doe could "opt in" to include his SIP URI in the DNS or in certain > countries everyone would automatically be added unless they "opted > out& quot;. There is no need to have separate "user" and "operator" ENUM > infrastructures for resolving E.164 numbers into a SIP URI: everything > as described above can go in the public "user" DNS because the privacy > concerns are gone. (You might need operator ENUM for something else but > that's not the topic for debate here). > > > > Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in > the DNS but only suggests using a SIP URI like > anonymous00045 at example.com for those concerned about privacy. I'd > suggest that this section of the RFC should reflect the outcome of our > privacy debate and include the principles summarised in this note, or > whatever we agree if my words and suggestions aren't right. > > An implication of the summary above is that the "lowest common > denominator" for SIP URI would be the numeric format e.g. > sip:1234567 at domain.com if we choose to recommend it. With this in mind, > let's test the suggestion by moving forward a few years into a future > where SIP-based telephony is more widespread, including 3GPP-based IMS > systems and where DNS provisioning issues are important. Take the > example of a SIP user who wishes to make a call to another SIP customer > using their E.164 number. If the called customer has "opted in" to ENUM > and a SIP URI exists such as sip:johndoe at siptelco.com this will work in > the normal way. If they are not "opted in", then provided the DNS > datafill has been done in line with the "lowest common denominator" > format, a numeric SIP URI exists in the ENUM DNS e.g. > sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call > routes via siptelco.com > > This works fine but what about the implications for DNS provisioning ? > If we said that all customers (SIP and non-SIP) have an entry in the > ENUM DNS using the numeric SIP URI format we would need to build a huge > DNS table containing entries like: > > 4412345678 -> sip:4412345678 at owning-operator.com > > Although there would be a huge number of DNS entries, an individual > entry would only need to change if the number was ported to a different > operator > > e.g. sip:987654321@ owning-operator.com changed to > sip:987654321 at alternatesipco.com > > Having an individual DNS record for each phone number is simple > conceptually but involves creating a huge number of records which look > something like this: > > e.g. 8.7.6.5.4.3.2>.1.4.4.e164.arpa -> > !^.*$!sip:4412345678 at big-uk-telco.co.uk > > However, if it is possible to do full wildcarding in DNS in conjunction > with a rewrite rule this could be fairly easy to set up. The idea is > that a single line for a whole dial code range combined with a clever > rewrite rule could rewrite any matching E.164 number in that range to a > suitable SIP URI: > > *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk > So that, using letters to represent the generalised E.164 number > 44208abcdef > f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk > > Having experimented with a test DNS the wildcarding part works fine: you > can have a general wildcarding rule for the whole number range pointing > to the "owning" operator together with specific entries to over-ride the > wild card where a particular E.164 number has been ported to a different > operator. Unfortunately my skills in regular expressions are not good > enough to figure out whether you could create a rewrite rule to do > what's needed in the above example. Any "regular expression" experts out > there interested in this challenge ? > > Summarising the suggestions. > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com > > - There shouldn't be any privacy concerns with the above > - In "opt in" countries a SIP customer could add their SIP URI if they > wished e.g. johndoe at bigsipco.com *- You could add non-SIP customers to > the DNS using the numeric SIP URI format, allowing SIP calls to them to > route to the right interconnect point (SIP to POTS interworking)* > > *- DNS wildcarding in conjunction with a clever rewrite rule might allow > easy creation of these numeric SIP URIs without needing to create > millions of individual DNS records* > > * > * > > *Kim Fullbrook > O2 UK * > > * > > > > * > ------------------------------------------------------------------------ > > *======================================================== > 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 > * ------------------------------------------------------------------------ ======================================================== 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 enumvoipsip.cs@schiefner.de Tue, 10 Aug 2004 11:41:48 -0400 From: Carsten Schiefner Date: Tue, 10 Aug 2004 11:41:48 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4118EBDD.3050307@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi James, James Seng wrote: i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. how about considering it as a default? I am sure any ISP will assign you an username in case you cant be bothered to pick one by yourself to form an email address. It's just that most people WANT [own_user_name] at [own_domain_name] - those who have privacy considerations can go for 123456 at [free_email_SP]. I consciously decided to have SIP URI "sip:carsten at schiefner.de" for my PSTN number +49308541452 (and this may change again!) - others may want to go for 49308541452 at [german_SIP_SP] instead... Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From robert.schafer@mci.com Tue, 10 Aug 2004 12:02:15 -0400 From: Robert Schafer Date: Tue, 10 Aug 2004 12:02:15 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4118EFA8.4050002@mci.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James: Possibly you could clarify what you meant by "...their own sip boxes"? Are you referring to the DNS or something else? Thanks...Robert James Seng wrote: > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com -James Seng Fullbrook Kim (UK) wrote: James, I don't believe I've said anything about enforcing what usernames people wish to use and would be very grateful if you can point out where this is described. Thanks, Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 15:55 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. james Fullbrook Kim (UK) wrote: > Although the debate about ENUM privacy issues has subsided, having read > the new RFC 3824 I feel that it's worth summarising the key points of > the privacy discussion and the implications for the RFC, as well as > making some general suggestions for ENUM deployment>. > > This is my understanding of the summary of the privacy debate: > > > With the privacy concerns about personal information put in a publicly > accessible DNS, particularly with the "opt in" privacy policies in some > countries, we would not expect SIP URIs of the format > johndoe at bigtelco.com in the DNS to be available for all subscribers > globally. However, if John Doe's E.164 number is 1234567890 you could > put the SIP URI sip:1234567890 at bigtelco.com in the public DNS because > this doesn't cause any privacy difficulties while also providing a > necessary link in the call routing chain. If there was no SIP URI > record for a particular E.164 number in the DNS you couldn't route SIP > calls which are addressed via E.164 number and the service would break > unless some other routing solution was provided. In "opt in" countries > John Doe could "opt in" to include his SIP URI in the DNS or in certain > countries everyone would automatically be added unless they "opted > out& quot;. There is no need to have separate "user" and "operator" ENUM > infrastructures for resolving E.164 numbers into a SIP URI: everything > as described above can go in the public "user" DNS because the privacy > concerns are gone. (You might need operator ENUM for something else but > that's not the topic for debate here). > > > > Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in > the DNS but only suggests using a SIP URI like > anonymous00045 at example.com for those concerned about privacy. I'd > suggest that this section of the RFC should reflect the outcome of our > privacy debate and include the principles summarised in this note, or > whatever we agree if my words and suggestions aren't right. > > An implication of the summary above is that the "lowest common > denominator" for SIP URI would be the numeric format e.g. > sip:1234567 at domain.com if we choose to recommend it. With this in mind, > let's test the suggestion by moving forward a few years into a future > where SIP-based telephony is more widespread, including 3GPP-based IMS > systems and where DNS provisioning issues are important. Take the > example of a SIP user who wishes to make a call to another SIP customer > using their E.164 number. If the called customer has "opted in" to ENUM > and a SIP URI exists such as sip:johndoe at siptelco.com this will work in > the normal way. If they are not "opted in", then provided the DNS > datafill has been done in line with the "lowest common denominator" > format, a numeric SIP URI exists in the ENUM DNS e.g. > sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call > routes via siptelco.com > > This works fine but what about the implications for DNS provisioning ? > If we said that all customers (SIP and non-SIP) have an entry in the > ENUM DNS using the numeric SIP URI format we would need to build a huge > DNS table containing entries like: > > 4412345678 -> sip:4412345678 at owning-operator.com > > Although there would be a huge number of DNS entries, an individual > entry would only need to change if the number was ported to a different > operator > > e.g. sip:987654321@ owning-operator.com changed to > sip:987654321 at alternatesipco.com > > Having an individual DNS record for each phone number is simple > conceptually but involves creating a huge number of records which look > something like this: > > e.g. 8.7.6.5.4.3.2>.1.4.4.e164.arpa -> > !^.*$!sip:4412345678 at big-uk-telco.co.uk > > However, if it is possible to do full wildcarding in DNS in conjunction > with a rewrite rule this could be fairly easy to set up. The idea is > that a single line for a whole dial code range combined with a clever > rewrite rule could rewrite any matching E.164 number in that range to a > suitable SIP URI: > > *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk > So that, using letters to represent the generalised E.164 number > 44208abcdef > f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk > > Having experimented with a test DNS the wildcarding part works fine: you > can have a general wildcarding rule for the whole number range pointing > to the "owning" operator together with specific entries to over-ride the > wild card where a particular E.164 number has been ported to a different > operator. Unfortunately my skills in regular expressions are not good > enough to figure out whether you could create a rewrite rule to do > what's needed in the above example. Any "regular expression" experts out > there interested in this challenge ? > > Summarising the suggestions. > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com > > - There shouldn't be any privacy concerns with the above > - In "opt in" countries a SIP customer could add their SIP URI if they > wished e.g. johndoe at bigsipco.com *- You could add non-SIP customers to > the DNS using the numeric SIP URI format, allowing SIP calls to them to > route to the right interconnect point (SIP to POTS interworking)* > > *- DNS wildcarding in conjunction with a clever rewrite rule might allow > easy creation of these numeric SIP URIs without needing to create > millions of individual DNS records* > > * > * > > *Kim Fullbrook > O2 UK * > > * > > > > * > ------------------------------------------------------------------------ > > *======================================================== > 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 > * ------------------------------------------------------------------------ ======================================================== 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 Tue, 10 Aug 2004 12:34:55 -0400 From: James Seng Date: Tue, 10 Aug 2004 12:34:55 -0400 To: Carsten Schiefner Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4118F28A.6090000@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R do we have 'default' recommendation for email addresses, personal websites url etc? you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. james Carsten Schiefner wrote: how about considering it as a default? I am sure any ISP will assign you an username in case you cant be bothered to pick one by yourself to form an email address. It's just that most people WANT [own_user_name] at [own_domain_name] - those who have privacy considerations can go for 123456 at [free_email_SP]. I consciously decided to have SIP URI "sip:carsten at schiefner.de" for my PSTN number +49308541452 (and this may change again!) - others may want to go for 49308541452 at [german_SIP_SP] instead... Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 10 Aug 2004 14:36:36 -0400 From: Mike Hammer Date: Tue, 10 Aug 2004 14:36:36 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4.3.2.7.2.20040810140435.05248970@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James, Chill. RFC3261 already defines how to convert a tel: URI to a sip URI: "19.1.6 Relating SIP URIs and tel URLs When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes sip:+358-555-1234567;postd=pp22 at foo.com;user=phone ..." The key here is that you need to add the parameter ;user=phone to distinguish the digit string in the local part as a phone number versus some other random string of digits/characters. Within that context the + indicates that it is a global E.164 number. It would be good to ensure that makes it into the transforms described in Kim's and others messages. One other thought: While these transforms can be created on the fly, there is still the need to register somewhere the default (non-ported) number block assignments to the particular carriers (e.g. +1703435 10,000 block belongs to US-Verizon). Whether you embed that in DNS or in some other database, the mapping has to be recorded somewhere. Mike At 10:54 PM 8/10/2004 +0800, James Seng wrote: i find it ridiclous that you think you can enforced how people wants to assign username on their own sip boxes. this is like saying 'you cannot have email address with your name in their' and publish it as an rfc. james Fullbrook Kim (UK) wrote: Although the debate about ENUM privacy issues has subsided, having read the new RFC 3824 I feel that it's worth summarising the key points of the privacy discussion and the implications for the RFC, as well as making some general suggestions for ENUM deployment. This is my understanding of the summary of the privacy debate: With the privacy concerns about personal information put in a publicly accessible DNS, particularly with the "opt in" privacy policies in some countries, we would not expect SIP URIs of the format johndoe at bigtelco.com in the DNS to be available for all subscribers globally. However, if John Doe's E.164 number is 1234567890 you could put the SIP URI sip:1234567890 at bigtelco.com in the public DNS because this doesn't cause any privacy difficulties while also providing a necessary link in the call routing chain. If there was no SIP URI record for a particular E.164 number in the DNS you couldn't route SIP calls which are addressed via E.164 number and the service would break unless some other routing solution was provided. In "opt in" countries John Doe could "opt in" to include his SIP URI in the DNS or in certain countries everyone would automatically be added unless they "opted out". There is no need to have separate "user" and "operator" ENUM infrastructures for resolving E.164 numbers into a SIP URI: everything as described above can go in the public "user" DNS because the privacy concerns are gone. (You might need operator ENUM for something else but that's not the topic for debate here). Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in the DNS but only suggests using a SIP URI like anonymous00045 at example.com for those concerned about privacy. I'd suggest that this section of the RFC should reflect the outcome of our privacy debate and include the principles summarised in this note, or whatever we agree if my words and suggestions aren't right. An implication of the summary above is that the "lowest common denominator" for SIP URI would be the numeric format e.g. sip:1234567 at domain.com if we choose to recommend it. With this in mind, let's test the suggestion by moving forward a few years into a future where SIP-based telephony is more widespread, including 3GPP-based IMS systems and where DNS provisioning issues are important. Take the example of a SIP user who wishes to make a call to another SIP customer using their E.164 number. If the called customer has "opted in" to ENUM and a SIP URI exists such as sip:johndoe at siptelco.com this will work in the normal way. If they are not "opted in", then provided the DNS datafill has been done in line with the "lowest common denominator" format, a numeric SIP URI exists in the ENUM DNS e.g. sip:987654321 at siptelco.com so the ENUM lookup will succeed and the call routes via siptelco.com This works fine but what about the implications for DNS provisioning ? If we said that all customers (SIP and non-SIP) have an entry in the ENUM DNS using the numeric SIP URI format we would need to build a huge DNS table containing entries like: 4412345678 -> sip:4412345678 at owning-operator.com Although there would be a huge number of DNS entries, an individual entry would only need to change if the number was ported to a different operator e.g. sip:987654321@ owning-operator.com changed to sip:987654321 at alternatesipco.com Having an individual DNS record for each phone number is simple conceptually but involves creating a huge number of records which look something like this: e.g. 8.7.6.5.4.3.2>.1.4.4.e164.arpa -> !^.*$!sip:4412345678 at big-uk-telco.co.uk However, if it is possible to do full wildcarding in DNS in conjunction with a rewrite rule this could be fairly easy to set up. The idea is that a single line for a whole dial code range combined with a clever rewrite rule could rewrite any matching E.164 number in that range to a suitable SIP URI: *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk So that, using letters to represent the generalised E.164 number 44208abcdef f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk Having experimented with a test DNS the wildcarding part works fine: you can have a general wildcarding rule for the whole number range pointing to the "owning" operator together with specific entries to over-ride the wild card where a particular E.164 number has been ported to a different operator. Unfortunately my skills in regular expressions are not good enough to figure out whether you could create a rewrite rule to do what's needed in the above example. Any "regular expression" experts out there interested in this challenge ? Summarising the suggestions. - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - There shouldn't be any privacy concerns with the above - In "opt in" countries a SIP customer could add their SIP URI if they wished e.g. johndoe at bigsipco.com *- You could add non-SIP customers to the DNS using the numeric SIP URI format, allowing SIP calls to them to route to the right interconnect point (SIP to POTS interworking)* *- DNS wildcarding in conjunction with a clever rewrite rule might allow easy creation of these numeric SIP URIs without needing to create millions of individual DNS records* * * *Kim Fullbrook O2 UK * * * ------------------------------------------------------------------------ *======================================================== 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 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 10 Aug 2004 16:23:16 -0400 From: Internet-Drafts@ietf.org Date: Tue, 10 Aug 2004 16:23:16 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-05.txt Message-ID: <200408101943.PAA25004@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-05.txt Pages : 17 Date : 2004-8-10 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-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From enumvoipsip.cs@schiefner.de Tue, 10 Aug 2004 16:23:25 -0400 From: Carsten Schiefner Date: Tue, 10 Aug 2004 16:23:25 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <41192794.2090205@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R James, James Seng wrote: do we have 'default' recommendation for email addresses, personal websites url etc? I truly believe that there are systems out there that have a fall-back/default behavior if you can't be bothered about your user id - as I outlined in my previous email. However, you may have a point when questioning whether a specific 'standard' behaviour should be 'recommended' here - when the aim is "only" privacy which can be ensured by any other (random) unique identifier in the respective realm, too... you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. It definitely would help, though! ;-> Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 11 Aug 2004 03:20:45 -0400 From: Jeff Williams Date: Wed, 11 Aug 2004 03:20:45 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4119E433.C5EA1128@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Well again as has been already debated and discussed the privacy concerns regarding ENUM structure are indeed being camouflaged by that same structure and still exposing ENM users to privacy invasion. Thanks again Kim for staying on top so closely to this very concerning and potentially damaging standards track shell game that is decidedly and seemingly purposefully based on ideology rather than good technical approaches to addressing privacy realities... Fullbrook Kim (UK) wrote: > Although the debate about ENUM privacy issues has subsided, having > read the > new RFC 3824 I feel that it's worth summarising the key points of the > privacy discussion and the implications for the RFC, as well as making > some > general suggestions for ENUM deployment. > > This is my understanding of the summary of the privacy debate: > > > With the privacy concerns about personal information put in a publicly > > accessible DNS, particularly with the "opt in" privacy policies in > some > countries, we would not expect SIP URIs of the format > johndoe at bigtelco.com > in the DNS to be available for all subscribers globally. However, if > John > Doe's E.164 number is 1234567890 you could put the SIP URI > sip:1234567890 at bigtelco.com in the public DNS because this doesn't > cause any > privacy difficulties while also providing a necessary link in the call > > routing chain. If there was no SIP URI record for a particular E.164 > number > in the DNS you couldn't route SIP calls which are addressed via E.164 > number > and the service would break unless some other routing solution was > provided. > In "opt in" countries John Doe could "opt in" to include his SIP URI > in the > DNS or in certain countries everyone would automatically be added > unless > they "opted out". There is no need to have separate "user" and > "operator" > ENUM infrastructures for resolving E.164 numbers into a SIP URI: > everything > as described above can go in the public "user" DNS because the privacy > > concerns are gone. (You might need operator ENUM for something else > but > that's not the topic for debate here). > > > Section 8 of RFC 3824 acknowledges security concerns over SIP URIs in > the > DNS but only suggests using a SIP URI like anonymous00045 at example.com > for > those concerned about privacy. I'd suggest that this section of the > RFC > should reflect the outcome of our privacy debate and include the > principles > summarised in this note, or whatever we agree if my words and > suggestions > aren't right. > > An implication of the summary above is that the "lowest common > denominator" > for SIP URI would be the numeric format e.g. sip:1234567 at domain.com > if we > choose to recommend it. With this in mind, let's test the suggestion > by > moving forward a few years into a future where SIP-based telephony is > more > widespread, including 3GPP-based IMS systems and where DNS > provisioning > issues are important. Take the example of a SIP user who wishes to > make a > call to another SIP customer using their E.164 number. If the called > customer has "opted in" to ENUM and a SIP URI exists such as > sip:johndoe at siptelco.com this will work in the normal way. If they > are not > "opted in", then provided the DNS datafill has been done in line with > the > "lowest common denominator" format, a numeric SIP URI exists in the > ENUM DNS > e.g. sip:987654321 at siptelco.com so the ENUM lookup will succeed and > the call > routes via siptelco.com > > This works fine but what about the implications for DNS provisioning > ? If > we said that all customers (SIP and non-SIP) have an entry in the ENUM > DNS > using the numeric SIP URI format we would need to build a huge DNS > table > containing entries like: > 4412345678 -> sip:4412345678 at owning-operator.com > > Although there would be a huge number of DNS entries, an individual > entry > would only need to change if the number was ported to a different > operator > e.g. sip:987654321@ owning-operator.com changed to > sip:987654321 at alternatesipco.com > > Having an individual DNS record for each phone number is simple > conceptually > but involves creating a huge number of records which look something > like > this: > e.g. 8.7.6.5.4.3.2.1.4.4.e164.arpa -> > !^.*$!sip:4412345678 at big-uk-telco.co.uk > > However, if it is possible to do full wildcarding in DNS in > conjunction with > a rewrite rule this could be fairly easy to set up. The idea is that > a > single line for a whole dial code range combined with a clever rewrite > rule > could rewrite any matching E.164 number in that range to a suitable > SIP URI: > *.8.0.2.4.4.e164.arpa -> sip: @uk-sip-telco.co.uk > So that, using letters to represent the generalised E.164 number > 44208abcdef > f.e.d.c.b.a.8.0.2.4.4.e164.arpa -> sip:44208abcdef at uk-sip-telco.co.uk > > Having experimented with a test DNS the wildcarding part works fine: > you can > have a general wildcarding rule for the whole number range pointing to > the > "owning" operator together with specific entries to over-ride the wild > card > where a particular E.164 number has been ported to a different > operator. > Unfortunately my skills in regular expressions are not good enough to > figure > out whether you could create a rewrite rule to do what's needed in the > above > example. Any "regular expression" experts out there interested in this > > challenge ? > > Summarising the suggestions. > - All SIP customers have a "minimum" URI entry in the publicly visible > ENUM > DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com > - There shouldn't be any privacy concerns with the above > - In "opt in" countries a SIP customer could add their SIP URI if they > > wished e.g. johndoe at bigsipco.com > - You could add non-SIP customers to the DNS using the numeric SIP URI > > format, allowing SIP calls to them to route to the right interconnect > point > (SIP to POTS interworking) > - DNS wildcarding in conjunction with a clever rewrite rule might > allow easy > creation of these numeric SIP URIs without needing to create millions > of > individual DNS records > > > Kim Fullbrook > O2 UK > > > > > > > > > - > --------------------------------------------------------------------- > > ======================================================== > 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 shollenbeck@verisign.com Wed, 11 Aug 2004 08:49:42 -0400 From: "Hollenbeck, Scott" Date: Wed, 11 Aug 2004 08:49:42 -0400 To: "'enum at ietf.org> Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-05.txt Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF040D78D7@vsvapostal8.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Status: R The document described below has been updated per the discussion that took place during the enum WG meeting in San Diego. I would now like to ask the chairs to start a working group last call for the document. -Scott- > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > Sent: Tuesday, August 10, 2004 3:43 PM > To: i-d-announce at ietf.org > Cc: enum at ietf.org > Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-05.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 : E.164 Number Mapping for the > Extensible Provisioning Protocol > Author(s) : S. Hollenbeck > Filename : draft-ietf-enum-epp-e164-05.txt > Pages : 17 > Date : 2004-8-10 > > 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-05.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jcurran@istaff.org Wed, 11 Aug 2004 09:15:12 -0400 From: John Curran Date: Wed, 11 Aug 2004 09:15:12 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:06 AM +0800 8/11/04, James Seng wrote: >you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@O2.COM Wed, 11 Aug 2004 10:11:45 -0400 From: "Fullbrook Kim (UK)" Date: Wed, 11 Aug 2004 10:11:45 -0400 To: "'enum at ietf.org> Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R To clarify what I was trying to say in the original proposal note: - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. sip:johndoe at bigsipco.com In other words, those customers who wish to add their SIP URI - i.e. which username they wish to use - can do so, with a minimum DNS entry of just a numeric SIP URI Just to recap, I'm talking about the ENUM DNS here.  I can't see that there is a problem with a customer having two or more id's in here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood the RFCs here. On the other hand, in the cases where the customer wishes to publish a username type SIP URI, there would be no problem technically if the numeric SIP URI was removed.  The thinking was that having a numeric SIP URI for everyone ought to make DNS provisioning easier because it is always there. John Curran in his recent note summed up quite well what I'm trying to achieve (thanks John for your words which I've changed slightly here) - specify the common expectation of ENUM DNS contents necessary for interoperability. Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 16:18 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment  > - All SIP customers have a "minimum" URI entry in the publicly visible  > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com -James Seng Fullbrook Kim (UK) wrote: > James, > > I don't believe I've said anything about enforcing what usernames people > wish to use and would be very grateful if you can point out where this > is described. > > Thanks, > Kim. > > -----Original Message----- > From: James Seng [mailto:jseng at pobox.org.sg] > Sent: 10 August 2004 15:55 > To: Fullbrook Kim (UK) > Cc: 'enum@ ietf.org' > Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment > > > i find it ridiclous that you think you can enforced how people wants to > assign username on their own sip boxes. > > this is like saying 'you cannot have email address with your name in > their' and publish it as an rfc. > > james ========================================================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 ppfautz@att.com Wed, 11 Aug 2004 10:35:48 -0400 From: "Pfautz, Penn L, ALABS" Date: Wed, 11 Aug 2004 10:35:48 -0400 To: "Fullbrook Kim \(UK\)" Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: <34DA635B184A644DA4588E260EC0A25A07E515A7@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R Kim: Are you assuming that "bigsipco" represents the carrier of record for the number in the PSTN? Who owns the Tier 2 where these NAPTRS are when both carrier and end user want records which are different?   Penn Pfautz -----Original Message-----From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Fullbrook Kim (UK)Sent: Wednesday, August 11, 2004 10:09 AMTo: 'enum at ietf.org'Cc: 'James Seng'Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment To clarify what I was trying to say in the original proposal note: - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. sip:johndoe at bigsipco.com In other words, those customers who wish to add their SIP URI - i.e. which username they wish to use - can do so, with a minimum DNS entry of just a numeric SIP URI Just to recap, I'm talking about the ENUM DNS here.  I can't see that there is a problem with a customer having two or more id's in here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood the RFCs here. On the other hand, in the cases where the customer wishes to publish a username type SIP URI, there would be no problem technically if the numeric SIP URI was removed.  The thinking was that having a numeric SIP URI for everyone ought to make DNS provisioning easier because it is always there. John Curran in his recent note summed up quite well what I'm trying to achieve (thanks John for your words which I've changed slightly here) - specify the common expectation of ENUM DNS contents necessary for interoperability. Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 16:18 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment  > - All SIP customers have a "minimum" URI entry in the publicly visible  > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com -James Seng Fullbrook Kim (UK) wrote: > James, > > I don't believe I've said anything about enforcing what usernames people > wish to use and would be very grateful if you can point out where this > is described. > > Thanks, > Kim. > > -----Original Message----- > From: James Seng [mailto:jseng at pobox.org.sg] > Sent: 10 August 2004 15:55 > To: Fullbrook Kim (UK) > Cc: 'enum@ ietf.org' > Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment > > > i find it ridiclous that you think you can enforced how people wants to > assign username on their own sip boxes. > > this is like saying 'you cannot have email address with your name in > their' and publish it as an rfc. > > james ========================================================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 Wed, 11 Aug 2004 11:53:47 -0400 From: James Seng Date: Wed, 11 Aug 2004 11:53:47 -0400 To: John Curran Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <411A3EDE.40508@pobox.org.sg> MIME-Version: 1.0 Content-Type: text/plain Status: R you mean you wont interop with me if I have 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg instead of the 'privacy compatible' format 5.8.0.7.8.3.6.9.5.6.e164.arpa. NAPTR to sip:6596387085 at sip.tech.org.sg Get real. Privacy or not, proposed by Kim adds no additional technical value beyond restriction what people can put into their own sip boxes and enum records. ps: Those are *real* entries btw. -James Seng John Curran wrote: At 12:06 AM +0800 8/11/04, James Seng wrote: you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Wed, 11 Aug 2004 13:33:40 -0400 From: Mike Hammer Date: Wed, 11 Aug 2004 13:33:40 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <4.3.2.7.2.20040811132528.00b27438@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James, I think the point was that it is impossible to interop with you if you have no record at all. All that was suggested was the format for a default record that would allow a call to continue on to a service provider, who should know that: 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg Mike At 11:44 PM 8/11/2004 +0800, James Seng wrote: you mean you wont interop with me if I have 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg instead of the 'privacy compatible' format 5.8.0.7.8.3.6.9.5.6.e164.arpa. NAPTR to sip:6596387085 at sip.tech.org.sg Get real. Privacy or not, proposed by Kim adds no additional technical value beyond restriction what people can put into their own sip boxes and enum records. ps: Those are *real* entries btw. -James Seng John Curran wrote: At 12:06 AM +0800 8/11/04, James Seng wrote: you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ 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 Wed, 11 Aug 2004 13:57:43 -0400 From: Jim Reid Date: Wed, 11 Aug 2004 13:57:43 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <411A3EDE.40508@pobox.org.sg> Message-ID: <10579.1092246833@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "James" == James Seng writes: James> Privacy or not, proposed by Kim adds no additional James> technical value beyond restriction what people can put into James> their own sip boxes and enum records. This discussion is a dialogue of the deaf and it would be better if it terminated now as it's just going in circles. James, there are serious privacy and data protection issues surrounding ENUM. They may not be a concern in Singapore. But they are a concern in the EU. And probably elsewhere too. These issues could also touch on competition policy too: for instance when a telco/ISP controls an end-user's NAPTRs. Much of this stuff touches on legal issues that are far out of scope for IETF. While I would like to see someone write up a draft on these concerns, it should not be necessary for the WG to work on it IMO. Perhaps this hypothetical draft could be published as an Informational RFC. After all a solution to these concerns is inherently a National Matter. The rules in various jurisdictions are likely to conflict or even be mutually exclusive in some cases. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jon.peterson@neustar.biz Wed, 11 Aug 2004 14:16:21 -0400 From: "Peterson, Jon" Date: Wed, 11 Aug 2004 14:16:21 -0400 To: "'Fullbrook Kim (UK)'" Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: <7927C67249E4AD43BC05B539AF0D12980F7E66@stntexch04.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R Mandating, as you seem to suggest below, the use of telephone numbers in the user portion of a SIP AoR as the best way to achieve privacy might work for the ENUM case, but neglects the broader SIP case. RFC3824 was not a product of the ENUM WG (though the document was last-called here as well to make sure it didn't step on ENUM's toes), and the guidance for creation of private URIs in that document reflects SIP practices (e.g., RFC3323), without assuming that SIP is only used with an ENUM bootstrap. Strictly speaking, even revealing the hostname "bigsipco.com" (as you propose below) can be cause for privacy concerns in some cases - if my personal domain were to appear in the host portion, for example, that would be sufficient to identify that the record pointed to me. So, from a SIP privacy perspective, I would consider the mechanism below to be a partial solution that addresses a small segment of the total problem space.   Moreover, the hard fact of the matter is that there are, and will continue to be, greenfield SIP services unaffiliated with the PSTN, and ENUM NAPTR records should be able to point to those services, even if such services do not support usernames that happen to be E.164 numbers. While many greeenfield SIP deployments (like FWD or iptel.org) can provide users with numeric username identifiers, those identifiers are not E.164 numbers (my FWD numeric username is five digits long). In contrast, your proposal seems to at best assume, and at worst mandate, that the operator of my SIP service be authoritative for any telephone number for which I happen to provision a NAPTR record in ENUM. This assumption creates an unnecessary linkage between the operators of E.164 numbers and the operators of SIP services. The DNS (and this goes for ENUM too) just provides pointers to network resources; those resources may not know that they are being pointed to by the DNS, and certainly we should not try to constrain the internal naming conventions used by those resources just because something in the DNS may happen to be pointing at them at any given moment.   It is also probably worth mentioning that RFC3824 does discourage placing multiple SIP URIs in a given ENUM NAPTR RR set (see the third bullet in Section 4).   Jon Peterson NeuStar, Inc.
-----Original Message-----From: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM]Sent: Wednesday, August 11, 2004 7:09 AMTo: 'enum at ietf.org'Cc: 'James Seng'Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment To clarify what I was trying to say in the original proposal note: - All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com - In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. sip:johndoe at bigsipco.com In other words, those customers who wish to add their SIP URI - i.e. which username they wish to use - can do so, with a minimum DNS entry of just a numeric SIP URI Just to recap, I'm talking about the ENUM DNS here.  I can't see that there is a problem with a customer having two or more id's in here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood the RFCs here. On the other hand, in the cases where the customer wishes to publish a username type SIP URI, there would be no problem technically if the numeric SIP URI was removed.  The thinking was that having a numeric SIP URI for everyone ought to make DNS provisioning easier because it is always there. John Curran in his recent note summed up quite well what I'm trying to achieve (thanks John for your words which I've changed slightly here) - specify the common expectation of ENUM DNS contents necessary for interoperability. Kim. -----Original Message----- From: James Seng [mailto:jseng at pobox.org.sg] Sent: 10 August 2004 16:18 To: Fullbrook Kim (UK) Cc: 'enum at ietf.org' Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment  > - All SIP customers have a "minimum" URI entry in the publicly visible  > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com -James Seng Fullbrook Kim (UK) wrote: > James, > > I don't believe I've said anything about enforcing what usernames people > wish to use and would be very grateful if you can point out where this > is described. > > Thanks, > Kim. > > -----Original Message----- > From: James Seng [mailto:jseng at pobox.org.sg] > Sent: 10 August 2004 15:55 > To: Fullbrook Kim (UK) > Cc: 'enum@ ietf.org' > Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment > > > i find it ridiclous that you think you can enforced how people wants to > assign username on their own sip boxes. > > this is like saying 'you cannot have email address with your name in > their' and publish it as an rfc. > > james ========================================================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 iesg-secretary@ietf.org Wed, 11 Aug 2004 17:21:46 -0400 From: The IESG Date: Wed, 11 Aug 2004 17:21:46 -0400 To: IETF-Announce Subject: [Enum] Last Call: 'IANA Registration for ENUMservices email, fax, mms, ems and sms' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for ENUMservices email, fax, mms, ems and sms ' 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-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Wed, 11 Aug 2004 17:21:49 -0400 From: The IESG Date: Wed, 11 Aug 2004 17:21:49 -0400 To: IETF-Announce Subject: [Enum] Last Call: 'IANA Registration for ENUMservices web and ft' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for ENUMservices web and ft ' 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-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-01.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Wed, 11 Aug 2004 18:00:26 -0400 From: Mike Hammer Date: Wed, 11 Aug 2004 18:00:26 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <4.3.2.7.2.20040811132528.00b27438@cia.cisco.com> Message-ID: <4.3.2.7.2.20040811171817.0418dea0@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James, The important thing is not that you have an ITSP, but that there be an address to which the call can be routed onward. The E.164 number is the basis for routing calls in the PSTN. If the call arrives at my switch or PSTN gateway and I want to route the call to your assigned E.164 number where do I send the call next? And how do I know that? (Assume no membership in any special carrier's club.) Is the number portable? If so, what does the NP database point to? As far as I know there is one ENUM: e164.arpa It seems to me that breaking the ability to route calls to any E.164 number from any other E.164 number on the globe should be a clue that the design is incomplete or fundamentally flawed. I think that the suggestions thus far were to be able to get an ENUM DNS query response that says either: its unassigned (don't bother trying), it's in the PSTN (can be routed to a PTSN GW), or send the call to address X. Did I miss something? Mike At 04:38 AM 8/12/2004 +0800, James Seng wrote: but what if i dont have a ITSP? we are talking about *User* ENUM here right? james Mike Hammer wrote: James, I think the point was that it is impossible to interop with you if you have no record at all. All that was suggested was the format for a default record that would allow a call to continue on to a service provider, who should know that: 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg Mike At 11:44 PM 8/11/2004 +0800, James Seng wrote: you mean you wont interop with me if I have 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg instead of the 'privacy compatible' format 5.8.0.7.8.3.6.9.5.6.e164.arpa. NAPTR to sip:6596387085 at sip.tech.org.sg Get real. Privacy or not, proposed by Kim adds no additional technical value beyond restriction what people can put into their own sip boxes and enum records. ps: Those are *real* entries btw. -James Seng John Curran wrote: At 12:06 AM +0800 8/11/04, James Seng wrote: you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ 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 Wed, 11 Aug 2004 20:49:24 -0400 From: Richard Shockey Date: Wed, 11 Aug 2004 20:49:24 -0400 To: Jim Reid Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <10579.1092246833@gromit.rfc1035.com> Message-ID: <6.1.0.6.2.20040811203003.04514bb8@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 01:53 PM 8/11/2004, Jim Reid wrote: >>>>> "James" == James Seng writes:     James> Privacy or not, proposed by Kim adds no additional     James> technical value beyond restriction what people can put into     James> their own sip boxes and enum records. This discussion is a dialogue of the deaf and it would be better if it terminated now as it's just going in circles. James, there are serious privacy and data protection issues surrounding ENUM. They may not be a concern in Singapore. But they are a concern in the EU. And probably elsewhere too. These issues could also touch on competition policy too: for instance when a telco/ISP controls an end-user's NAPTRs. Much of this stuff touches on legal issues that are far out of scope for IETF. While I would like to see someone write up a draft on these concerns, it should not be necessary for the WG to work on it IMO. Perhaps this hypothetical draft could be published as an Informational RFC. After all a solution to these concerns is inherently a National Matter. The rules in various jurisdictions are likely to conflict or even be mutually exclusive in some cases. I dont find this discussion strange at all. I tried to out line it in my privacy and security draft. A draft BTW I have been asking for input to for quite some time. http://www.ietf.org/internet-drafts/draft-shockey-enum-privacy-security-00.txt Ive been waiting for this to come up again and Kim's comments seem perfectly in line with my comments. why would anyone see a conflict between two possible AOR's  sip:1234567 at domain.com the one I put in the DNS and sip:myfullname at domain.com the one I put on my business card _______________________________________________ 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 richard@shockey.us Wed, 11 Aug 2004 20:59:13 -0400 From: Richard Shockey Date: Wed, 11 Aug 2004 20:59:13 -0400 To: enum at ietf.org Subject: [Enum] LAST CALL E.164 mapping for EPP Message-ID: <6.1.0.6.2.20040811204833.03cb4ec0@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R It was the consensus of the WG in San Diego that we proceed to last call with this document. The intent of the last call is to solicit comments before submitting the ID to the IESG as a Proposed Standard. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend for 2 weeks from today to at least Friday August 27 though we can modify that if new issues come up. 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-05.txt Pages : 17 Date : 2004-8-10 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-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Wed, 11 Aug 2004 23:57:07 -0400 From: Jeff Williams Date: Wed, 11 Aug 2004 23:57:07 -0400 To: Jim Reid Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <10579.1092246833@gromit.rfc1035.com> Message-ID: <411B0457.C385C75D@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, Of course privacy concerns are very important in the US as well as other countries in Asia despite James's claims to the contrary. Jim Reid wrote: > >>>>> "James" == James Seng writes: > > James> Privacy or not, proposed by Kim adds no additional > James> technical value beyond restriction what people can put into > James> their own sip boxes and enum records. > > This discussion is a dialogue of the deaf and it would be better if it > terminated now as it's just going in circles. James, there are serious > privacy and data protection issues surrounding ENUM. They may not be a > concern in Singapore. But they are a concern in the EU. And probably > elsewhere too. These issues could also touch on competition policy > too: for instance when a telco/ISP controls an end-user's NAPTRs. > > Much of this stuff touches on legal issues that are far out of scope > for IETF. While I would like to see someone write up a draft on these > concerns, it should not be necessary for the WG to work on it IMO. > Perhaps this hypothetical draft could be published as an Informational > RFC. After all a solution to these concerns is inherently a National > Matter. The rules in various jurisdictions are likely to conflict or > even be mutually exclusive in some cases. > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum -- 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 james@seng.cc Thu, 12 Aug 2004 08:26:59 -0400 From: James Seng Date: Thu, 12 Aug 2004 08:26:59 -0400 To: John Curran Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <411A2302.1000407@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: R you mean you wont interop with me if I have 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg instead of the 'privacy compatible' format 5.8.0.7.8.3.6.9.5.6.e164.arpa. NAPTR to sip:6596387085 at sip.tech.org.sg Get real. Privacy or not, proposed by Kim adds no additional technical value beyond restriction what people can put into their own sip boxes and enum records. ps: Those are *real* entries btw. -James Seng sip:jseng at sip.tech.org.sg instead John Curran wrote: At 12:06 AM +0800 8/11/04, James Seng wrote: you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james@seng.cc Thu, 12 Aug 2004 08:26:59 -0400 From: James Seng Date: Thu, 12 Aug 2004 08:26:59 -0400 To: Mike Hammer Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <411A83D9.9070400@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: R but what if i dont have a ITSP? we are talking about *User* ENUM here right? james Mike Hammer wrote: James, I think the point was that it is impossible to interop with you if you have no record at all. All that was suggested was the format for a default record that would allow a call to continue on to a service provider, who should know that: 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg Mike At 11:44 PM 8/11/2004 +0800, James Seng wrote: you mean you wont interop with me if I have 0.4.0.1.1.1.4.6.5.6.e164.arpa. NAPTR to sip:jseng at sip.tech.org.sg instead of the 'privacy compatible' format 5.8.0.7.8.3.6.9.5.6.e164.arpa. NAPTR to sip:6596387085 at sip.tech.org.sg Get real. Privacy or not, proposed by Kim adds no additional technical value beyond restriction what people can put into their own sip boxes and enum records. ps: Those are *real* entries btw. -James Seng John Curran wrote: At 12:06 AM +0800 8/11/04, James Seng wrote: you just cant protect people from doing stupid things. we shouldn't pretend we are so smart that we know what is the best for the whole internet. and not to mention, we dont really have control over what people do on their own boxes and enum delegation. James, You can put whatever you want in your enum delegation, including a set of characters resembling random line noise. What is specified is simply the common expectation of contents necessary for interoperability. If you don't desire such, no problem, populate your records with any char string desired. /John _______________________________________________ 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 james@seng.cc Thu, 12 Aug 2004 08:27:00 -0400 From: James Seng Date: Thu, 12 Aug 2004 08:27:00 -0400 To: Jim Reid Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <10579.1092246833@gromit.rfc1035.com> Message-ID: <411A8656.6070507@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim Reid wrote: This discussion is a dialogue of the deaf and it would be better if it terminated now as it's just going in circles. James, there are serious privacy and data protection issues surrounding ENUM. They may not be a concern in Singapore. But they are a concern in the EU. And probably elsewhere too. These issues could also touch on competition policy too: for instance when a telco/ISP controls an end-user's NAPTRs. Discuss, make the issues open and let everyone who uses it understand - Yes. I support totally. But when you attempt to restrict what can be done or cannot be done in the protocol waving the flag of privacy, sorry, I think you're stepping over the line. Secondly, it is wrong to say SG isn't concern over Data Protection. We are but I am not sure we need to be all work-out over hypothical privacy issues. Or if I am wrong, pls point me to one violation of 'privacy' as you know it? Much of this stuff touches on legal issues that are far out of scope for IETF. While I would like to see someone write up a draft on these concerns, it should not be necessary for the WG to work on it IMO. Perhaps this hypothetical draft could be published as an Informational RFC. After all a solution to these concerns is inherently a National Matter. The rules in various jurisdictions are likely to conflict or even be mutually exclusive in some cases. Yes, I would love to see such document too. But as you rightly pointed out, these are inherently National matters. What I choose to do on privacy in SG is going to be very different from what you going to do in UK. -James Seng _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Fri, 13 Aug 2004 00:17:23 -0400 From: Jeff Williams Date: Fri, 13 Aug 2004 00:17:23 -0400 To: James Seng Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <10579.1092246833@gromit.rfc1035.com> Message-ID: <411C5A62.C3F587D6@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R James and all, James Seng wrote: > Jim Reid wrote: > > This discussion is a dialogue of the deaf and it would be better if it > > terminated now as it's just going in circles. James, there are serious > > privacy and data protection issues surrounding ENUM. They may not be a > > concern in Singapore. But they are a concern in the EU. And probably > > elsewhere too. These issues could also touch on competition policy > > too: for instance when a telco/ISP controls an end-user's NAPTRs. > > Discuss, make the issues open and let everyone who uses it understand - > Yes. I support totally. > > But when you attempt to restrict what can be done or cannot be done in > the protocol waving the flag of privacy, sorry, I think you're stepping > over the line. I don't and it seems from my companies customers in YOUR country, you are mistaken OR you cannot speak as though such privacy protections should not be a entragal part of ANY IT protocol in which ANY standards organization is developing or considering. Nor can anyone of reasonable IT standards development exposure and experience as well as stakeholders/users reasonably say that such privacy protections could not be entragal to said protocols... > > > Secondly, it is wrong to say SG isn't concern over Data Protection. We > are but I am not sure we need to be all work-out over hypothical privacy > issues. Again it seems that a increasing number of stakeholders/users that I know of personally in Singapore don't agree with your opinion here, and from what I have thus far read in your comments as well as from your countries government, it also seems that the level of concern for stakeholders/users in Singapore is very low. As such, and as that policy direction is continuing it may be that a certain amount of isolation from international business interests such as in the UK, US, as well as Canada, will find it increasingly difficult in certain areas of communications such as ENUM and VoIP... > Or if I am wrong, pls point me to one violation of 'privacy' as > you know it? James, this has been pointed out on this forum several times by several participants, including myself twice... > > > > Much of this stuff touches on legal issues that are far out of scope > > for IETF. While I would like to see someone write up a draft on these > > concerns, it should not be necessary for the WG to work on it IMO. > > Perhaps this hypothetical draft could be published as an Informational > > RFC. After all a solution to these concerns is inherently a National > > Matter. The rules in various jurisdictions are likely to conflict or > > even be mutually exclusive in some cases. > > Yes, I would love to see such document too. But as you rightly pointed > out, these are inherently National matters. What I choose to do on > privacy in SG is going to be very different from what you going to do in UK. Perhaps. And to do so may also accord a very different and changed business in communications between the UK and SG as well... > > > -James Seng > > _______________________________________________ > 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 james@seng.cc Fri, 13 Aug 2004 11:30:27 -0400 From: James Seng Date: Fri, 13 Aug 2004 11:30:27 -0400 To: Mike Hammer Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <4.3.2.7.2.20040811132528.00b27438@cia.cisco.com> Message-ID: <411B647D.8080301@seng.cc> MIME-Version: 1.0 Content-Type: text/plain Status: R I dont disagree with what you saying below. But it is kind of different from what Kim is proposing and what I am objecting to. -James Seng Mike Hammer wrote: It seems to me that breaking the ability to route calls to any E.164 number from any other E.164 number on the globe should be a clue that the design is incomplete or fundamentally flawed. I think that the suggestions thus far were to be able to get an ENUM DNS query response that says either: its unassigned (don't bother trying), it's in the PSTN (can be routed to a PTSN GW), or send the call to address X. Did I miss something? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From enumvoipsip.cs@schiefner.de Wed, 18 Aug 2004 05:43:37 -0400 From: Carsten Schiefner Date: Wed, 18 Aug 2004 05:43:37 -0400 To: enum at ietf.org Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <10579.1092246833@gromit.rfc1035.com> Message-ID: <4123231E.7040409@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Richard Shockey wrote: [...] Ive been waiting for this to come up again and Kim's comments seem perfectly in line with my comments. why would anyone see a conflict between two possible AOR's sip:1234567 at domain.com the one I put in the DNS and sip:myfullname at domain.com the one I put on my business card this certainly can make sense. However - and maybe it's me just missing a crucial point here - would that mean that you need to handle two SIP accounts at least? Or does sip:1234567 at domain.com refer to sip:myfullname at domain.com? Or vice versa? Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Wed, 18 Aug 2004 13:03:34 -0400 From: Mike Hammer Date: Wed, 18 Aug 2004 13:03:34 -0400 To: Carsten Schiefner Message-ID: <4.3.2.7.2.20040818125010.00afe988@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Both SIP addresses with the same domain name would likely route to the same proxy. Whether those addresses are linked (one an alias for the other) or not is a local issue. Mike At 11:36 AM 8/18/2004 +0200, Carsten Schiefner wrote: Richard, Richard Shockey wrote: [...] Ive been waiting for this to come up again and Kim's comments seem perfectly in line with my comments. why would anyone see a conflict between two possible AOR's sip:1234567 at domain.com the one I put in the DNS and sip:myfullname at domain.com the one I put on my business card this certainly can make sense. However - and maybe it's me just missing a crucial point here - would that mean that you need to handle two SIP accounts at least? Or does sip:1234567 at domain.com refer to sip:myfullname at domain.com? Or vice versa? Cheers, -C. _______________________________________________ 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, 20 Aug 2004 11:54:21 -0400 From: "Fullbrook Kim (UK)" Date: Fri, 20 Aug 2004 11:54:21 -0400 To: "'enum at ietf.org> Subject: [Enum] ENUM in the UK Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: ENUM in the UK Status: R For those that are interested, the UK Government has issued a consultation document on the proposed arrangements for the establishment of a Public ENUM database in the UK.  The document is available for download at  http://www.dti.gov.uk/consultations/consultation-1230.html Of relevance to earlier discussions in this forum is that they propose the database to be "opt in", confirming earlier views. Kim. ========================================================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 jwkckid1@ix.netcom.com Fri, 20 Aug 2004 20:52:40 -0400 From: Jeff Williams Date: Fri, 20 Aug 2004 20:52:40 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM in the UK In-Reply-To: Message-ID: <4126B31F.5F0C13ED@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Does this mean that future ENUM users either opt-in to have their personal and private information listed in the data base or not be able to use ENUM? OR, does this proposal mean that users UK can decide for themselves to opt-in or not, and still use ENUM? Fullbrook Kim (UK) wrote: > For those that are interested, the UK Government has issued a > consultation > document on the proposed arrangements for the establishment of a > Public ENUM > database in the UK. The document is available for download at > http://www.dti.gov.uk/consultations/consultation-1230.html > > > Of relevance to earlier discussions in this forum is that they propose > the > database to be "opt in", confirming earlier views. > > Kim. > > > > 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 enumvoipsip.cs@schiefner.de Sat, 21 Aug 2004 07:20:59 -0400 From: Carsten Schiefner Date: Sat, 21 Aug 2004 07:20:59 -0400 To: Mike Hammer Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <6.1.0.6.2.20040811203003.04514bb8@joy.songbird.com> Message-ID: <41272CED.7030506@schiefner.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, ok, point taken - make that sip:1234567 at telcodomain.net and sip:myfullname at mydomain.com then: two accounts? Referrals? If the latter, from which address to which address? To me, sip:myfullname at mydomain.com pointing to sip:1234567 at telcodomain.net appears to make more sense... -C. Mike Hammer wrote: Both SIP addresses with the same domain name would likely route to the same proxy. Whether those addresses are linked (one an alias for the other) or not is a local issue. Mike At 11:36 AM 8/18/2004 +0200, Carsten Schiefner wrote: Richard Shockey wrote: [...] Ive been waiting for this to come up again and Kim's comments seem perfectly in line with my comments. why would anyone see a conflict between two possible AOR's sip:1234567 at domain.com the one I put in the DNS and sip:myfullname at domain.com the one I put on my business card this certainly can make sense. However - and maybe it's me just missing a crucial point here - would that mean that you need to handle two SIP accounts at least? Or does sip:1234567 at domain.com refer to sip:myfullname at domain.com? Or vice versa? Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Sat, 21 Aug 2004 09:58:34 -0400 From: Jim Reid Date: Sat, 21 Aug 2004 09:58:34 -0400 To: Jeff Williams Subject: Re: [Enum] ENUM in the UK In-Reply-To: <4126B31F.5F0C13ED@ix.netcom.com> Message-ID: <27441.1093095361@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>>>> "Jeff" == Jeff Williams writes: Jeff> Kim and all, Does this mean that future ENUM users either Jeff> opt-in to have their personal and private information listed Jeff> in the data base or not be able to use ENUM? OR, does this Jeff> proposal mean that users UK can decide for themselves to Jeff> opt-in or not, and still use ENUM? Yes. The opt-in requirement comes from the government and regulator. This is likely to apply throughout Western Europe: certainly the EU anyway. The fundamental principle here is that numbers don't get entered into ENUM without the consent of the owner of that number. [ie You can't spoof the registration of my home number and then steal my phone service or divert it to a $1000/min sex line on the Space Station.] Telcos also want this opt-in provision so that their customers interests are protected. Though it doesn't take much to see how this might be in the telco's self-interest too. What the end user puts in the DNS under their ENUM registration is up to the end user. Though that may depend on the facilities for NAPTR manipulation that the end user gets from their registrar and/or applications service providers. Some hand-waving is done here however. There are of course issues of data protection and privacy. Then there's the obvious danger of publishing contact data that could be mined by spammers, telemarketers, junk mail operators and similar scum. Some user education will be needed, perhaps supported by a code of conduct for the ENUM entities that's supervised by the proposed Policy Committee. FWIW, Sections 7.1 & 7.2 of the government consultation document couldn't be any clearer about privacy consderations: 7.1 ENUM is a public database and the public have access to all the information held in DNS. The proposals for ENUM have been built on the principle that subscribers opt-in to ensure that they are aware that this information is being made public and have consented to its inclusion. 7.2 The existing legal requirements concerning data protection and privacy apply to the organisations involved in ENUM. Compliance with these legal requirements is a matter for the organisations concerned. No additional measures are proposed. So UK users can use ENUM whether they opt-in or not. But they MUST opt-in if they want others to use ENUM to reach them through DNS entries under 4.4.e164.arpa. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Sat, 21 Aug 2004 21:14:01 -0400 From: Jeff Williams Date: Sat, 21 Aug 2004 21:14:01 -0400 To: Jim Reid Subject: Re: [Enum] ENUM in the UK In-Reply-To: <27441.1093095361@gromit.rfc1035.com> Message-ID: <41280905.2C319AA4@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim and all, Ok I thought so, but wanted to get a second opinion at least. This is how the US should also handle it, but somehow I doubt that given the direction of the standards track thus far, it will be handled as the UK is handling it... I also agree with your analysis as well Jim as to the benefit to the providers/Telco's/ISP's. Kinda gets them off the hook as well as gives them the option in marketing and sales... However I am sure the anti-privacy bigots will not be so obliging or enthused... Jim Reid wrote: > >>>>> "Jeff" == Jeff Williams writes: > > Jeff> Kim and all, Does this mean that future ENUM users either > Jeff> opt-in to have their personal and private information listed > Jeff> in the data base or not be able to use ENUM? OR, does this > Jeff> proposal mean that users UK can decide for themselves to > Jeff> opt-in or not, and still use ENUM? > > Yes. > > The opt-in requirement comes from the government and regulator. This > is likely to apply throughout Western Europe: certainly the EU > anyway. The fundamental principle here is that numbers don't get > entered into ENUM without the consent of the owner of that number. > [ie You can't spoof the registration of my home number and then steal > my phone service or divert it to a $1000/min sex line on the Space > Station.] Telcos also want this opt-in provision so that their > customers interests are protected. Though it doesn't take much to see > how this might be in the telco's self-interest too. > > What the end user puts in the DNS under their ENUM registration is up > to the end user. Though that may depend on the facilities for NAPTR > manipulation that the end user gets from their registrar and/or > applications service providers. Some hand-waving is done here however. > There are of course issues of data protection and privacy. Then > there's the obvious danger of publishing contact data that could be > mined by spammers, telemarketers, junk mail operators and similar > scum. Some user education will be needed, perhaps supported by a code > of conduct for the ENUM entities that's supervised by the proposed > Policy Committee. > > FWIW, Sections 7.1 & 7.2 of the government consultation document > couldn't be any clearer about privacy consderations: > > 7.1 ENUM is a public database and the public have access to all > the information held in DNS. The proposals for ENUM have been > built on the principle that subscribers opt-in to ensure that > they are aware that this information is being made public and > have consented to its inclusion. > > 7.2 The existing legal requirements concerning data protection and > privacy apply to the organisations involved in ENUM. Compliance > with these legal requirements is a matter for the organisations > concerned. No additional measures are proposed. > > So UK users can use ENUM whether they opt-in or not. But they MUST > opt-in if they want others to use ENUM to reach them through DNS > entries under 4.4.e164.arpa. 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 Mon, 23 Aug 2004 10:53:41 -0400 From: Mike Hammer Date: Mon, 23 Aug 2004 10:53:41 -0400 To: Carsten Schiefner Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <4.3.2.7.2.20040818125010.00afe988@cia.cisco.com> Message-ID: <4.3.2.7.2.20040823102134.00b08ca8@cia.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Carsten, There will be many combinations decided upon by end-users or service providers. It is not necessary to constrain this arbitrarily. My main concern is two-fold: 1) E.164 numbers should be able to be routed from any other E.164 number (global inter-connectivity). 2) ENUM should not break Number Portability. I haven't seen anyone explain how ENUM could violate EU privacy directives, if it would contain the exact same information (and no more) as the NP database. If a minimal ENUM entries are really a privacy problem, then they need to revisit NP. Mike At 01:07 PM 8/21/2004 +0200, Carsten Schiefner wrote: Mike, ok, point taken - make that sip:1234567 at telcodomain.net and sip:myfullname at mydomain.com then: two accounts? Referrals? If the latter, from which address to which address? To me, sip:myfullname at mydomain.com pointing to sip:1234567 at telcodomain.net appears to make more sense... -C. Mike Hammer wrote: Both SIP addresses with the same domain name would likely route to the same proxy. Whether those addresses are linked (one an alias for the other) or not is a local issue. Mike At 11:36 AM 8/18/2004 +0200, Carsten Schiefner wrote: Richard Shockey wrote: [...] Ive been waiting for this to come up again and Kim's comments seem perfectly in line with my comments. why would anyone see a conflict between two possible AOR's sip:1234567 at domain.com the one I put in the DNS and sip:myfullname at domain.com the one I put on my business card this certainly can make sense. However - and maybe it's me just missing a crucial point here - would that mean that you need to handle two SIP accounts at least? Or does sip:1234567 at domain.com refer to sip:myfullname at domain.com? Or vice versa? Cheers, -C. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jwkckid1@ix.netcom.com Mon, 23 Aug 2004 21:47:25 -0400 From: Jeff Williams Date: Mon, 23 Aug 2004 21:47:25 -0400 To: Mike Hammer Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: <4.3.2.7.2.20040818125010.00afe988@cia.cisco.com> Message-ID: <412AB3E2.ADD5F5F0@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike and all, Well than a revisit to NP would certainly be in order according to our members already stated privacy concerns on this very forum, which I have posted on several occasions. I can also certainly understand the EU's privacy concerns as well which I believe Kim has on several occasions expressed on this forum as well, perhaps you missed those posts. Mike Hammer wrote: > Carsten, > > There will be many combinations decided upon by end-users or service > providers. It is not necessary to constrain this arbitrarily. My main > concern is two-fold: > > 1) E.164 numbers should be able to be routed from any other E.164 number > (global inter-connectivity). > > 2) ENUM should not break Number Portability. > > I haven't seen anyone explain how ENUM could violate EU privacy directives, > if it would contain the exact same information (and no more) as the NP > database. If a minimal ENUM entries are really a privacy problem, then > they need to revisit NP. > > Mike > > At 01:07 PM 8/21/2004 +0200, Carsten Schiefner wrote: > >Mike, > > > >ok, point taken - make that sip:1234567 at telcodomain.net and > >sip:myfullname at mydomain.com then: two accounts? Referrals? If the latter, > >from which address to which address? > > > >To me, sip:myfullname at mydomain.com pointing to sip:1234567 at telcodomain.net > >appears to make more sense... > > > > -C. > > > >Mike Hammer wrote: > >>Both SIP addresses with the same domain name would likely route to the > >>same proxy. Whether those addresses are linked (one an alias for the > >>other) or not is a local issue. > >>Mike > >>At 11:36 AM 8/18/2004 +0200, Carsten Schiefner wrote: > >>>Richard Shockey wrote: > >>>>[...] > >>>>Ive been waiting for this to come up again and Kim's comments seem > >>>>perfectly in line with my comments. > >>>>why would anyone see a conflict between two possible AOR's > >>>> sip:1234567 at domain.com the one I put in the DNS and > >>>>sip:myfullname at domain.com the one I put on my business card > >>> > >>>this certainly can make sense. However - and maybe it's me just missing > >>>a crucial point here - would that mean that you need to handle two SIP > >>>accounts at least? Or does sip:1234567 at domain.com refer to > >>>sip:myfullname at domain.com? Or vice versa? > >>> > >>>Cheers, > >>> > >>> -C. > > _______________________________________________ > 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@shockey.us Tue, 24 Aug 2004 11:59:06 -0400 From: Richard Shockey Date: Tue, 24 Aug 2004 11:59:06 -0400 To: enum at ietf.org Subject: [Enum] ENUM Goes Commercial : Contract for +43 ENUM Tier 1 Registry between RTR and enum.at Message-ID: <6.1.0.6.2.20040824113605.03e11280@joy.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R ENUM goes commercial in Austria RTR (the Austrian Regulator) and enum.at announced today officially in a common press conference the planned launch of a commercial ENUM service in Austria. The corresponding press releases can be found (in German) at enum.at Presseinformation (PDF) and RTR Presseinformation (PDF) During the press conference two presentations where given: Präsentation ENUM_was ist das.pdf (2986,77 kB) and Präsentation ENUM 24082004.pdf (553,99 kB) The major reason for the press conference was the presentation of the contract between RTR and enum.at regarding the operation of the ENUM Tier 1 Registry. The contract is also available at the RTR-webpage: ENUM_Vertrag.pdf (206,3 kB) Sorry, the contract is currently only available in German, and English version is under translation. The contract is about the ENUM Tier 1 Registry operation, but also gives obligations for the contracts between the ENUM Tier 1 Registry and the Registrars. It also defines the number ranges that will be available in ENUM and the validation and identification required for the different number ranges. The number ranges in ENUM will be: -geographic numbers -private networks (05) -mobile numbers (06xx) -non-geographic fixed numbers (0720) -ENUM-driven numbers (0780) -freephone numbers (0800) The validation and identification methods differ for the different number ranges, potential examples are given in the annex B of the contract. The contract also defines the data stored at the ENUM Tier 1 registry for each delegated number ("WHOIS capability"). In short: For control and escrow purposes the subscriber identity (name and address) is stored at the ENUM Tier 1 Registry (for numbers requiring identification), but not available for the general public. Publicly available is only the fact that the number is delegated and the registrar. This allows also for ENUM delegations without identification, given proper validation (e.g. for mobile prepaid numbers with SMS validation).       > 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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Kim.Fullbrook@O2.COM Wed, 25 Aug 2004 13:22:12 -0400 From: "Fullbrook Kim (UK)" Date: Wed, 25 Aug 2004 13:22:12 -0400 To: "'enum at ietf.org> Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Status: R Just to confirm that my views on privacy are as summarised by Mike.  If the ENUM database contains the same information as the number portability database there can't be any privacy concerns because this same information is already available.  There is, however, a concern in many (but maybe not all) countries about putting email addresses or "user-friendly" SIP usernames in the ENUM database, unless individuals "opt in" to do this. Putting it another way I would distinguish between ENUM data that accomplishes basic (and I mean basic, not all the redirection stuff) call routing, and the data that does all the clever stuff.  Basic stuff is needed to ensure that customers can call each other using the de-facto telecomms standard - E.164 numbers.  All the other stuff is optional and users who wish to take advantage of it can "opt in".  One other factor to throw into the pot is that a telco potentially could choose not to offer the ability to "opt in". My guess is that the number of customers who would want to "opt in" would be very tiny. Those customers who didn't like this limitation could then take their custom (and E.164 number) to another telco who did offer "opt in" as is their right in a competitive business environment. Kim. -----Original Message----- From: Jeff Williams [mailto:jwkckid1 at ix.netcom.com] Sent: 24 August 2004 04:20 To: Mike Hammer Cc: enum at ietf.org; Carsten Schiefner Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment Mike and all,   Well than a revisit to NP would certainly be in order according to our members already stated privacy concerns on this very forum, which I have posted on several occasions.   I can also certainly understand the EU's privacy concerns as well which I believe Kim has on several occasions expressed on this forum as well, perhaps you missed those posts. Mike Hammer wrote: > Carsten, > > There will be many combinations decided upon by end-users or service > providers.  It is not necessary to constrain this arbitrarily.  My main > concern is two-fold: > > 1) E.164 numbers should be able to be routed from any other E.164 number > (global inter-connectivity). > > 2) ENUM should not break Number Portability. > > I haven't seen anyone explain how ENUM could violate EU privacy directives, > if it would contain the exact same information (and no more) as the NP > database.  If a minimal ENUM entries are really a privacy problem, then > they need to revisit NP. > > Mike > > At 01:07 PM 8/21/2004 +0200, Carsten Schiefner wrote: > >Mike, > > > >ok, point taken  - make that sip:1234567 at telcodomain.net and > >sip:myfullname at mydomain.com then: two accounts? Referrals? If the latter, > >from which address to which address? > > > >To me, sip:myfullname at mydomain.com pointing to sip:1234567 at telcodomain.net > >appears to make more sense... > > ========================================================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 jwkckid1@ix.netcom.com Thu, 26 Aug 2004 10:51:06 -0400 From: Jeff Williams Date: Thu, 26 Aug 2004 10:51:06 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment In-Reply-To: Message-ID: <412DB07D.E4AF4D7D@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim and all, Understood Kim. I hope I didn't misrepresent your remarks/position in my earlier comments? If I did in your opinion I can assure you it wasn't my intention. I also agreed mostly but not completely with Mike's summary. Fullbrook Kim (UK) wrote: > Just to confirm that my views on privacy are as summarised by > Mike. If the > ENUM database contains the same information as the number portability > database there can't be any privacy concerns because this same > information > is already available. There is, however, a concern in many (but maybe > not > all) countries about putting email addresses or "user-friendly" SIP > usernames in the ENUM database, unless individuals "opt in" to do > this. > > Putting it another way I would distinguish between ENUM data that > accomplishes basic (and I mean basic, not all the redirection stuff) > call > routing, and the data that does all the clever stuff. Basic stuff is > needed > to ensure that customers can call each other using the de-facto > telecomms > standard - E.164 numbers. All the other stuff is optional and users > who > wish to take advantage of it can "opt in". > > One other factor to throw into the pot is that a telco potentially > could > choose not to offer the ability to "opt in". My guess is that the > number of > customers who would want to "opt in" would be very tiny. Those > customers who > didn't like this limitation could then take their custom (and E.164 > number) > to another telco who did offer "opt in" as is their right in a > competitive > business environment. > > Kim. > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1 at ix.netcom.com] > Sent: 24 August 2004 04:20 > To: Mike Hammer > Cc: enum at ietf.org; Carsten Schiefner > Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM > deployment > > > Mike and all, > > Well than a revisit to NP would certainly be in order according to > our > members already stated privacy concerns on this very forum, which I > have posted on several occasions. > > I can also certainly understand the EU's privacy concerns as well > which I believe Kim has on several occasions expressed on this forum > as well, perhaps you missed those posts. > > Mike Hammer wrote: > > > Carsten, > > > > There will be many combinations decided upon by end-users or service > > > providers. It is not necessary to constrain this arbitrarily. My > main > > concern is two-fold: > > > > 1) E.164 numbers should be able to be routed from any other E.164 > number > > (global inter-connectivity). > > > > 2) ENUM should not break Number Portability. > > > > I haven't seen anyone explain how ENUM could violate EU privacy > directives, > > if it would contain the exact same information (and no more) as the > NP > > database. If a minimal ENUM entries are really a privacy problem, > then > > they need to revisit NP. > > > > Mike > > > > At 01:07 PM 8/21/2004 +0200, Carsten Schiefner wrote: > > >Mike, > > > > > >ok, point taken - make that sip:1234567 at telcodomain.net and > > >sip:myfullname at mydomain.com then: two accounts? Referrals? If the > latter, > > >from which address to which address? > > > > > >To me, sip:myfullname at mydomain.com pointing to > sip:1234567 at telcodomain.net > > >appears to make more sense... > > > > > > > - > --------------------------------------------------------------------- > > ======================================================== > 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