Subject: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Tue, 10 Aug 2004 08:56:29 -0400

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:  

<summary>
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).  

</summary>

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: <reg exp> @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
<B
R>- 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: Alexander Mayrhofer <[email-masked]>
Date: Tue, 10 Aug 2004 09:20:37 -0400

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 
> 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

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 10 Aug 2004 09:41:37 -0400

On 2004/08/10 14:08, "Fullbrook Kim (UK)" <Kim.Fullbrook at O2.COM> 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:

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 >

---

From: James Seng <[email-masked]>
Date: Tue, 10 Aug 2004 10:59:14 -0400

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.

<summary>
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). 

</summary>
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: <reg exp> @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: Carsten Schiefner <[email-masked]>
Date: Tue, 10 Aug 2004 11:41:48 -0400

Hi James,
James Seng wrote:

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.

---

From: James Seng <[email-masked]>
Date: Tue, 10 Aug 2004 12:34:55 -0400

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:

Cheers,
    -C.

---

From: Mike Hammer <[email-masked]>
Date: Tue, 10 Aug 2004 14:36:36 -0400

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.

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:
<summary>
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).
</summary>
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: <reg exp> @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 *
*

*
distribution or use of the contents of this information is prohibited. If you

---

From: Carsten Schiefner <[email-masked]>
Date: Tue, 10 Aug 2004 16:23:25 -0400

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...

It definitely would help, though! ;->

---

From: Jeff Williams <[email-masked]>
Date: Wed, 11 Aug 2004 03:20:45 -0400

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
> 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
> 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.
>
> 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:
> entry
> conceptually
> ENUM
> DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com
> 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)
> -
> ---------------------------------------------------------------------
>
>    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

---

From: John Curran <[email-masked]>
Date: Wed, 11 Aug 2004 09:15:12 -0400

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

---

From: James Seng <[email-masked]>
Date: Wed, 11 Aug 2004 11:53:47 -0400

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,

/John

---

From: Mike Hammer <[email-masked]>
Date: Wed, 11 Aug 2004 13:33:40 -0400

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 11 Aug 2004 13:57:43 -0400

>>>>> "James" == James Seng <jseng at pobox.org.sg> 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.

---

From: Mike Hammer <[email-masked]>
Date: Wed, 11 Aug 2004 18:00:26 -0400

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

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 11 Aug 2004 20:49:24 -0400

At 01:53 PM 8/11/2004, Jim Reid wrote:
"James" == James Seng <jseng at pobox.org.sg>
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

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
<mailto:richard(at)shockey.us>
or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz>
;
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Jeff Williams <[email-masked]>
Date: Wed, 11 Aug 2004 23:57:07 -0400

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.

---

From: James Seng <[email-masked]>
Date: Thu, 12 Aug 2004 08:26:59 -0400

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,

/John

---

From: James Seng <[email-masked]>
Date: Thu, 12 Aug 2004 08:26:59 -0400

Mike
beyond restriction what people can put into their own sip boxes and 
enum records.

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

---

From: James Seng <[email-masked]>
Date: Thu, 12 Aug 2004 08:27:00 -0400

Jim Reid wrote:
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

---

From: Jeff Williams <[email-masked]>
Date: Fri, 13 Aug 2004 00:17:23 -0400

James and all,

> the protocol waving the flag of privacy, sorry, I think you're stepping

  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...

> 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...

> 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...

Regards,

---

From: James Seng <[email-masked]>
Date: Fri, 13 Aug 2004 11:30:27 -0400

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?

---

From: Carsten Schiefner <[email-masked]>
Date: Wed, 18 Aug 2004 05:43:37 -0400

Richard,
Richard Shockey wrote:
[...]

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.

---

From: Mike Hammer <[email-masked]>
Date: Wed, 18 Aug 2004 13:03:34 -0400

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.

---

From: Carsten Schiefner <[email-masked]>
Date: Sat, 21 Aug 2004 07:20:59 -0400

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.

---

From: Mike Hammer <[email-masked]>
Date: Mon, 23 Aug 2004 10:53:41 -0400

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:

Cheers,
        -C.

---

From: Jeff Williams <[email-masked]>
Date: Mon, 23 Aug 2004 21:47:25 -0400

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.

Regards,