Subject: RE: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt

From: "Mowafy, Hala" <[email-masked]>
Date: Mon, 23 Jan 2006 17:28:54 -0500

Richard,
A few comments and a few questions, please. 

1) Your draft touches on the Privacy Considerations (Sec 11) at a very
high level.  I don't need to reiterate what others have mentioned about
the different rules and jurisdictions but I do have to add that BEFORE
caller ID and CNAM were allowed to be delivered in the PSTN, all the
signaling elements and features necessary to preserve the privacy status
from the caller to the called party had to be worked out.  I understand
that was all mandated by the FCC and we're not expecting ENUM to be
regulated, but I assure you this topic is extremely sensitive I don't
expect any "exceptions" for ENUM or other.  And I'm sure we all agree
ENUM does not need any negative exposure.

2) You suggest a value of cnam=p or cnam=o in that database.
How do you know from call to call?
Today, I can make all my calls and my number would appear (public
status) to the called party.  Then, one day I have to call you and I
don't necessarily want my number or name to be displayed to you, I have
the option to change that status to "private" for just that call.  I
just have to dial a specific code that toggles the status to private for
a single call.
These codes are heavily used by law enforcement agencies and women's
shelters, etc. to block the delivery of the number+name. The codes alter
the signaled info in ISUP and the called party's serving switch has to
act accordingly.    

3) You refer to a new database for this cnam service.  Sometimes as "a
well-known database source" and other times as just an "ENUM database".
Could you elaborate on what is being envisioned?  
Is it a separate database dedicated to Name  storage and queries (sort
of like the name databases in the PSTN), or are you proposing this as an
addition to the ENUM routing databases (Tier 1B or Tier 2)??

4) In section 10, there is mention of this "not qualitatively different
from publication in a telephone directory.."  I am not sure if you are
implying that Carrier ENUM will implement something similar to pub and
non-pub markings.  But even if that happens, it is important to
understand that being non-pub does not mean a "private" status or vice
versa.  Two completely unrelated indicators that serve different
purposes.  
 
Maybe if you help me understand the ultimate goal/vision, I could
appreciate the I-D a bit more.  What I mean is I view ENUM as being
there for routing purposes.  So, how does cnam play a role in ENUM
routing?  In general, it seems insufficient to consider
distribution/access/privacy outside the scope of the document when those
ARE the essential elements of Caller ID/CNAM delivery.  

Thanks in advance
Hala   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Friday, January 13, 2006 9:01 PM
To: Paul Kyzivat
Cc: [email-masked]; [email-masked]; McCandless, Kevin;
[email-masked]
Subject: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt

Paul Kyzivat wrote:
> [Igot bounced from the enum list on the original posting. Will see if
> this works.]

It did.

>>
>> If you could elaborate on why the use of the tel URI's would be a bad
>> idea that would be helpful ..we envisioned using SIP URI's as equally

>> bad.
> 
> That isn't what I meant. What I meant was that using tel URIs
> *containing a cnam parameter* is a bad idea. For instance, consider
the 
> following:
> 
>     INVITE ...
>     From: "George W. Bush" <tel:+12125551234;cnam=jdoe>
> 
> and further assume that the enum lookup, according to your proposal, 
> of
> +12125551234 comes back with tel:+12125551234;cnam=janedoe
> 
> Then what is the proper calling name to use???

IMHO that which service provider policy determines to be the most 
authoritative which means IMHO the ENUM CNAM query aka janedoe in your
case.

That obviously does not mean that a proxy can then rewrite the From 
field data only that it is not authoritative for CNAM display purposes.

Out thinking in the next version of this draft is that only RFC 3325 
P-Asserted Identity can be authoritative for Display Name transport 
within SIP headers.

> 
> In sip the display name already provides a, uri scheme independent, 
> way
> to convey the name. Having a way to convey the name *in* certain kinds

> of URIs just makes things complicated.

Yes but there is a substantial back channel argument that you need to 
convey display name policy in a response in some manner.

As some of my distinguished colleagues from Verisign Msr Kevin 
McCandless and Manjul Maharishi have pointed out to me....

The PSTN defines several values for CNAM data in the event that there 
are restrictions or that the data is unavaiable. These are defined as 
"Reason for Absence of Name" [R3-50] in GR-1188

Consequently the following responses to a query from a well known 
database may need to be reserved.

Cnam=p  for "Private" defined as the Calling Party does not wish to have

their Display Name displayed.

Cnam=o for "not available/unaviable" defined as the well known database 
has no data available for that particular E.164 number

> 
>>> I am guessing this is just a matter that the enum translations need
>>> to be URIs, so you needed some URI that could contain the name. And 
>>> tel was one choice close at hand.
>>
>> It was a practical choice yes.
>>
>>> It all seems pretty circular, with the entry for the number
>>> containing a tel uri for the same number, plus the cnam parameter.
It 
>>> also introduces an unnecessary bit of overhead because of this 
>>> redundancy.
>>>
>>> Seems like there should be some other URx scheme that would be
>>> suitable to just contain the name.
>>
>> Ideas?
> 
> Taking a quick scan of the IANA scheme registry, I came up with data: 
> as
> in:
> 
>     data:,George%20W%20Bush
> 
> That seems to do the job.
> 

Yuck ..

Well Ok you could say E2U+cnam:data

data:,George%20W%20Bush

or

data:,p

for privacy values .. right ?

I'm not dismissing the idea out of hand.

Lets make it clear your belief is that the fundamental concept of using 
a 3761 Query to find CNAM data is sound. Your only issue is with what is

the appropriate URI returned. Correct?

If the issue is what is the URI vehicle then .... ..again why would tel:

be so bad?

Inquiring minds.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

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

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Jan 2006 18:29:27 -0500

> ENUM does not need any negative exposure.

Sure ... your concerns are well placed and I know well intentioned. This 
is a 00 draft and we certainly want to clarify the underlying privacy 
issues in later versions.

> How do you know from call to call?

Well the general discussion of privacy in SIP is a ongoing topic in SIPPING

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-00.txt

The issue in this draftis not to define how SIP deals with privacy only 
how a proxy could retrieve Caller Display Name information if it was 
clear that such information were allowed.

To answer your first question there is an assumption that the well known 
database has information and a response needs to be given on a per query 
basis. A. what is the CNAM data if available. B. in the case of cnam=o 
that no data exists or C. there is a overriding privacy flag on that data.

On a call by call basis if the SIP call is "anonymous" in the From: 
field then there is a presumption that the Called party's proxy SHOULD 
NOT attempt a query to discover the CNAM data.

> just have to dial a specific code that toggles the status to private for

Right if such a code is toggled by the Calling party's CUA it is assumed 
that Calling Party proxy would insert "anonymous" in the From: field of 
the INVITE and the Called Party's proxy would respect that not attempt a 
query.

> the signaled info in ISUP and the called party's serving switch has to

Understood .. as above demonstrates there are mechanisms in SIP that can 
implement this requirement.

> Could you elaborate on what is being envisioned?

Good point. In future versions we will use only one term .."well-known 
database". What this database is, who operates it and the discovery 
mechanism for learning the domain of the "well-known database" is out of 
scope for this document.

> addition to the ENUM routing databases (Tier 1B or Tier 2)??

Completely out side the scope of the ENUM routing databases. What we are 
doing here is simply proposing the use 3761 technology for query 
response of another class of PSTN data. We do not specify a domain for 
the rewrite rule.

> versa.  Two completely unrelated indicators that serve different

This is unclear. We'll strive to make this clearer in the next version.

> appreciate the I-D a bit more. 

Eliminate or reduce the need for another class of TCAP query. Access to 
this data on the SS7 network is cumbersome and expensive. There is a 
strong desire on the part of some service providers to migrate to a all 
IP query response system.

What I mean is I view ENUM as being there for routing purposes.

Yes ENUM as it is currently deployed is principally for routing 
information however the underlying technology can be used for 
essentially number translations to find databases of information 
associated with that number. We view CNAM is just another form of data 
associated with a TN.

So, how does cnam play a role in ENUM routing?

It doesnt.

  In general, it seems insufficient to consider
> ARE the essential elements of Caller ID/CNAM delivery.

Your points are well taken. We can certainly attempt to clarify the 
distribution/access/privacy issues but the actual usage of of the data 
is principally a SIP issue. We do make it clear that these "well known 
databases" are assumed to be private in nature.

In addition SIP is now dealing with the opposite privacy case case by 
which the Called Party may elect to reject any form of "anonymous" 
communication and signal the Calling Party that it rejects such calls.

I suspect this feature will meet with wide spread adoption.

--