Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Apr 2002 11:32:15 -0400

The problem with this line of thinking is that in the PSTN, identity is
always asserted by
the network, and never by the UA.  In SIP, presently, identity is always
asserted by
the UA and never the network.  Privacy when you have network asserted
identity
means something different than when you have user asserted identity.
 
There are no regulations, and I don't see any reason to believe that
regulators
will slavishly follow the current practice.  Until you have evidence to the
contrary,
arguing that the same SOLUTIONS are required is not helpful. 
 
What you do need to cater for is services.  If there are UAs that have
anonymity services,
a customer might prefer that UA from another.  If a service provider
provides an
anonymity service, that may find some customers.  If both exist, then
regulators may
be content, or they may require that all service providers provide B2BUAs.  
 
Without a network asserted identity, either a UA can implement anonymity, or
a B2BUA can do that.  No standards required in the IETF for that.
 
The problem comes with network asserted identity.  There is a clear
requirement
to be able to do a call trace on an anonymous call.  Proponents of a network
asserted identity posit that NAI is how you do call trace.  Opponents
counter that
you can't actually achieve anonymity with network asserted identity. That, I
believe
is the crux of the problem we now face: how to trace a call while allowing
the
user to actually be anonymous.
 
If we could get consensus that trace-with-anonymity is the problem, then we
can
work on solutions.  Until we get to something as straightforward as that,
we are going to spin a lot of wheels.
 
Brian 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 12, 2002 10:32 AM
To: [email-masked]
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

In a message dated 4/11/02 2:30:03 PM Eastern Daylight Time,
[email-masked] writes: 

5) Use a non-Internet protocol which completely constrains the service 
functionality and user experience to a least common denominator and stop 
pretending that your requirements have anything to do with the Internet. 

Look, there are two reasons why we may want to use Internet protocols: 

<snip> 

2) Because we're jealous of the success the Internet has had and want to 
contaminate it with "telco like" requirements so that Internet people 
can be miserable too. 

<snip> 

If we earnestly believe that Data Protection is going to require that 
we, by policy, alter these human-supplied/human-consumed values, then 
we're logically going to have to do the same for every other 
human-supplied/human-consumed values. I would argue that this completely 
defeats the value of an Internet protocol in this context. 

I believe it is significantly more effective to provide guidelines on 
human-supplied/human consumed values, and implement hard requirements 
for data protection only on network-supplied values. 

The issue here is not what any of us want to do to "contaminate" the purity
of IP or to make it look like the PSTN with its "limited" capabilities, but
rather, what will be required by various regulatory agencies once they
realize that, if IP is going to be used to replace traditional telephone
service, it has to comply with all the same rules and regulations. The area
of calling line ID presentation and restriction is the most complicated,
with different rules in different states and countries. 

Voice over IP isn't going to escape this regulation for long. It will get
"telco-like" requirements sooner or later. It's pretty obvious to me that
there needs to be an agreement on the requirements before any more
discussion on the protocol details that might be needed to solve an
(undefined) problem. 

Mike

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 15 Apr 2002 12:38:52 -0400

Brian Rosen wrote:
>If we could get consensus that trace-with-anonymity is the problem,
then > we can
> we are going to spin a lot of wheels.

That's always been the prime motivator for me, plus the secondary use of
NAI for call return to an anonymous caller.

Dave

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip