Subject: [Enum] three different views (draft-shockey-enum-)

From: "Stastny Richard" <[email-masked]>
Date: Thu, 21 Nov 2002 16:51:16 +0100

Hi Rich,
 
in your draft-shockey-enum-privacy-security-00.txt you point out three different views:
"Even within the technical community there are differnt views of what ENUM is and what
it is designed to accomplish."
 
and then you list
3.1 number translation database
3.2.called party control (ENUM subscriber)
3.3 calling party control (ENUM user)
 
and you link these different views to different security and privacy issues. This is sofar ok,
but IMHO the views need more differentiation (there are at least 2 x 2=4):
 
From the discussions during this week at the IETF55 and on the list, we may have at least 
two dimensions, so we may end up in four corners:
 
There is on one side the (say) horizontal axis of called vs. calling party control, as you mentioned.
 
On the other hand there is the (say) vertical axis of
ENUM subscriber control vs. service provider (operator) control of the domain and the NAPTR records
 
The latter dimension is linked to the opt-in principle With ENUM subscriber control
the opt-in principle is required, with SP or operator control the opt-in principle does not work,
because to establsh a feasible service, all your subscribers, or ported numbers or whatever, need to
be in ENUM and therefore privacy is mandatory.
 
So if you now draw the four quadrants (mentally, it hard in text;-), 
1. in the upper left hand corner 
you will have calling party control and ENUM subscriber control (opt-in). What is
required here is the bandner-compendium. The privacy is taken care of with the opt-in principle
of the ENUM subscriber.
 
2. in the upper right hand corner
you will have called party control and ENUM subscriber control (opt-in). What is required here
is a service resulution service ala sip or h323. It is up to the ENUM subscriber if he takes care
of privacy by using URI not exposing information or not, and if he adds additional information
using enumservices from the brandner-compendium. This implies, that the two approached need to
be compatible, what they are.
 
3. in the lower right hand corner
you will have called party control and SP or operator control (no-opt-in). This will be necessary
for all applications using ENUM as IN-replacment and for network routing purposes. Because the user
is not asked wether to be in ENUM or not, privacy is necessary and therefore only URIs shall
be used which do NOT expose information about the called user. These are mainly sip, h323 and
tel records with the extensions proposed in draft-yu-tel-url-06.
 
eg sip:[email-masked]
sip:[email-masked]
tel:+1-800-xxx-xxxx;cic=+10234
the latter may also be used from the PSTN via LDAP and a mediation device SCP-ENUM
 
4. the lower left hand corner is interesting. It may either not be applicable or may not exist in public
DNS, but it may exist within networks, providing the services from the brandner-compendium packed
to the user in "ENUM" without asking him. Since the data is not exposed to the public, no privacy concerns
and also no regulatory issues exist. Especially mobile operators are happily exploring this corner.
 
IMHO many of the misunderstandings during the discussions of this week just simple came from
the fact, that one party had in mind during the discussion e.g. corner 1 and 2, while the other party
had in mind corner 2 and 3 and of course did not understand what the hell the other party is talking
about, because both were sitting in opposite corners. I include myself in not understanding what
the other corner is talking about, but now I hope I got it;-)
 
Since I consider the draft-shockey as very important to discuss and clarify these issues, 
I hope that this mail may contribute to the draft-shockey and also may open a way forward in the discussion
on the enumservices (variants) and why all of them are needed. It is just depending on the corner you
are sitting in.
 
best regards
Richard Stastny

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum