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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 2 Apr 2002 10:16:02 -0600

This is an excellent summary, one with which I agree on almost all
particulars.
 
One or two small points below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 6:05 AM
To: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, Jon; 'William
Marshall'
Subject: Summary of RE: [Sip] Comment, SIP Privacy draft

<snip> 

3) 'Untrustworthy RPID' 

Flemming, Bill et al argued that RPID information is still useful when it is
'untrustworthy'. This can occur legitimately within the draft when an RPID
which is not 'private' (and so not encrypted) crosses a trust boundary. This
would represent an identity asserted by Network A and passed to Network B,
when B has no explicit trust relationship with A.

The contention was that since this information still has some value, it
should be passed to the UAS for display, and might also have some
application for call trace, although obviously not as useful as a
'trustworthy' identity.

Jon argued that the From field provides well enough for display, and the
value of untrustworthy information for call trace is debatable (and has been
debated at length).
[Peterson, Jon] Of greater concern to me is whether or not the existing
'screen' mechanism provides a way to use untrustworthy information for call
trace. If it does so (I still don't see how it does), then at the very least
I don't believe that usage is substantiated by the draft today.

There is agreement that some form of 'signed RPID' would be better.
Previously we have agreed on the need for a general mechanism to sign
information in SIP headers. Flemming has pointed out that if you agree to
have 'Signed RPID' then as a subset you have 'Untrustworthy RPID' (when you
don't recognise the signature). So removing 'Untrustworthy RPID' now would
be inconsistent, since there is already agreement to re-introduce it later.
That is unless you feel that the time interval during which Untrusted RPID
is not standardised is important.
[Peterson, Jon] I've argued (in a separate mail) that disallowing
'untrustworthy RPIDs' is not at all inconsistent with signing messages
later. Signing messages merely makes the concept of intrinsically trusted or
untrusted RPIDs go away - the concept of an intrinsically untrusted RPID is
not reintroduced by the ability to sign messages. Signing RPIDs just ushers
in an era of relativism, in which every entity is empowered to make its own
decision about trusting an RPID or not.

Many other points were made, but the above seemed to me to be the key
issues. 

And, now, my opinions: 

1) Call-Info: I think the point has been made here - we're into judgement
calls on how bad an abuse X is compared to Y - I would rather there was no
need for people to abuse the protocol at all.
[Peterson, Jon] Concisely put and undoubtedly accurate. 

2) From/To: RPID is not the problem here, is it a solution to an underlying
problem with From/To. Blocking RPID will not solve the underlying problem,
and people will just route around to find another, probably worse, solution.
Better to address the real problem which has led people to propose
obfuscating From/To in the first place. If this problem is solved, then
there is no reason for people to want untrusted UAs to insert RPID. See
separate mail on this.
[Peterson, Jon] Agreed. 

3) Untrustworthy RPID: I think Flemming and Bill have demonstrated the
utility of 'untrustworthy identity', and indeed this is what the From field
already provides. But From just provides the users assertion. If a network
has asserted additional identity information, why should the user should be
denied this ?
[Peterson, Jon] This is a line of reasoning we seem to come back to
repeatedly that really confuses me. RPID exists to provide call trace, not
Caller-ID, right? It allows the network to carry an identity when the user
wishes to remain anonymous, when they don't want to display their identity
to the other party in the dialog. If the network asserts identity
information, I don't think that information is intended to be displayed to
the user - so the user should actually be denied this information, right?

Having said that, the propogation of 'untrustworthy' RPID is strictly out of
scope according to the (retro-fitted) Applicability Statement. But then we
have agreement to add it 'in future' by virtue of the generic signing
mechanism - I guess this inconsistency is one for the ADs.

Regards, 

Mark

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 10:14:30 +0100

Dean wrote:
> 
> Just to be a "devils advocate",  I suggest other alternatives:
> 
> 4) Require that the UA anonymize the To and From headers IF requesting
> CLIR on a call, and allow them to populate those headers as 
> desired when
> NOT requesting CLIR.
>

Of course we should do this anyway, but it does not solve the problem. The
proposition (*) was about personal data of people *other than the caller*
e.g. the subscriber. The UA does not necessarily have the information about
these people's privacy requirements unless we invent a way of getting it
there, and then enforcing its use.

> And the "modest suggestion" alternative:
> 
> 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:
> 
> 1) Because Internet protocols and approaches offer a substantially
> richer, more flexible alternative which provides compelling advantages
> in terms of service delivery options relative to traditional PSTN
> approaches.
> 
> 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.
> 
> I don't know about you, but I believe in #1, and would argue 
> that if we
> accept (*) as a requirement, that we're leading down the 
> slippery slope
> towards #2, leading to what will be a large push from certain segments
> (witness Path discussion) to adopt alternative #5. Alternative #4 is a
> reasonable compromise which keeps the responsibility were the Internet
> says the responsibility should be, in the hands of the user.

It's not about 'telco like' vs 'Internet like'. It's not about the
technology at all. We have to look at the *service* as it is supplied to the
user. If you have a Service Provider model at all, then the Service Provider
has responsibilities about what they do with people's Personal Data, whether
the service it implemented using IPv20 between nano-machines or over a wet
piece of string.

> Perhaps instead of To: and From: we should have called these headers
> "What-I-will-Call-You:" and "What-I-Want-You-To-Call-Me:". 
> These headers
> have ABSOLUTELY NO SEMANTIC VALUE at the signaling and routing level.
> They are HUMAN SUPPLIED values intended for HUMAN 
> CONSUMPTION. There are
> many other human-supplied values possible in the signaling, 
> and the risk
> of privacy violation is equally present on ALL of them.
> 

As I've argued before, a privacy service which pupports to protect the
subscriber's privacy, but which does not amend the
'What-I-Want-You-To-Call-Me:' field, will not be very impressive to the
subscriber. Especially if there are 'guidelines' indicating that the user
should put their identity in this field so that *in practice*, Personal Data
of the subscriber appears in this field 99% of the time.

Now I'm just putting this as a proposition. I don't know what view Data
Protection regulators would take on this. But I think from a common-sense
analysis there is a good chance that privacy services might reasonably be
expected to modify such a field, since otherwise the service is only 1%
effective in practice.

It is actually more important 'what works' than philosphical arguments about
whose responsibility it is.

The SP does have some responsibility if they have required that the UA
follow a certain spec, which recommends certain behaviour.

By contrast, there is no implication whatsoever that there should be
presonal data in the subject field. I think that a privacy service which did
not modify the subject field is less likely to cause problems, although of
course there may well be people who want that blotted out too - the
user/subscriber can choose this at the price of loss of service
transparency.

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

We don't know for certain what Data Protection will/won't require, but I
believe we have to be prepared for all reasonable eventualities. My
contention is just that it is sufficiently likely that privacy services will
be required to modify these fields that we ought to consider it. Mayby it
will never be required, in which case good, but I would like us to agree
that if it *is* required, then there is an agreed way to do it.

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

I agree with this, with the caveat that from a Service perspective there are
grey areas about who is responsible for a particular piece of information. A
Service Provider may have some responsibility for apparently user-supplied
information if it is implicit or required in the service that the user shall
supply a certain piece of information in that field. Whether the network
equipment checks/processes etc. that field seems irrelevant to me in this
respect.

...Mark
 
> --
> Dean

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 10:50:57 +0100

> > I was looking for a consensus that (3) is a possible and 
> valid thing to
> > do for these Service Providers. If the IETF SIP group agree 
> that (3) and
> > not (1) is _a_ valid solution to this problem, then there 
> is more chance
> > of other fora adopting (3) instead of (1).
> 
> Honestly, I am flattered that you are hoping for the IETF blessing for
> building a service. However, building such an anonyzmizer in 
> (3) is well
> within the scope of the SIP protocol, and requires no standardization
> activity or consensus from IETF. I personally believe that you need a
> full b2bua, since privacy, from a user perspecitve, WILL involve
> stripping everything which might reveal identity, no matter 
> whether the
> header formally has identity information or not. 

I'm glad to hear you say this. Of course an individual could not expect free
consultancy from the IETF as to whether a given service worked, was valuable
etc. But here we are talking about cooperation between standards fora, and I
think it is valid to ask the IETF SIP community for their opinion on how a
particular problem in another forum could or ought to be solved. If there
was consensus of opinion that would be a good thing too.

Others have said, variously:
i) Privacy services SHOULD NOT require modification of these fields, because
they are end-to-end and none of the business of the network
ii) A better solution to the b2bua one is to feed back the privacy
requirements to the UA and then reject requests which do not meet the
privacy requirements

I think we can certainly say that (i) is a matter of opinion. I for one do
not feel confident that it would be safe for a Service Provider to bet on
this with respect to Data Protection.

(ii) requires standardisation and IMO doesn't quite work anyway.

> Thus, I am not sure
> what there is to do, but to emphasize to our friends in 3gpp to NOT
> always put anonymous values in the To/From as this clearly will break
> all reasonable interop with the outside world. (1) is BAD. Does anyone
> dispute that?
> 

I haven't seen anyone dispute that here. My point is that to credibly assert
that (1) is bad, we have to describe an alternative. Does anyone dispute
that (3) is a valid alternative solution to this problem ?

...Mark

---

From: William Marshall <[email-masked]>
Date: Fri, 12 Apr 2002 07:17:00 -0400 (EDT)

Jonathan wrote, in part:
> building such an anonyzmizer in (3) is well
> activity or consensus from IETF.. full B2BUA.. <part snipped>  I am not sure

It has been stated in this group often that B2BUAs are BAD, and that B2BUAs
break services.  There has never yet been an example of a service that
is broken because of a B2BUA, but this belief seems generally accepted.

This is the first claim I've seen that putting anonymous strings in the
From and To headers also will break services.  I must admit I have more
trouble accepting this belief than the "B2BUA breaks services" belief.
An example of a service that this breaks would be even more useful.

But if both are true, then the question is: which is less bad?
I think this is a judgement call based on perceived gleanings
from crystal balls, and mine is cloudy.  Does someone else have 
a clearer crystal ball on the subject?

Bill Marshall
[email-masked]

-----original message-----
Date: Thu, 11 Apr 2002 22:01:10 -0400
From: Jonathan Rosenberg <[email-masked]>
To: Mark Watson <[email-masked]>
Cc: [email-masked], Ben Campbell <[email-masked]>,
        Flemming Andreasen <[email-masked]>,
        "Peterson, Jon" <[email-masked]>,
        "'William Marshall'" <[email-masked]>
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

inline.

Mark Watson wrote:
> 
> Just on this one issue of obfuscation of the From/To field....
> 
> Let's be really clear about why this has come about:
> 
> Some Service Providers *believe* in the following proposition:
> 
> (*) IF the UA is allowed to put identity information into From/To, THEN
> the Service Provider will be forced (by Data Protection) to provide
> services which modify these fields, in order to protect the privacy of
> people other than the actual calling user - subscriber, forwarding etc.
> 
> First, set aside the question of whether to agree with (*) or not.
> 
> There are three options for people with this belief:
> 1) *Require* permanantly that the UA does not put identity information
> into From/To
> 2) Reject requests where the UA puts identity information in From/To if
> privacy is required
> 3) Build network services which provide the necessary modification
> (+whatever else is needed)
> 
> I do not think there are any other options.
> 
> We all agree that (1) is bad. (2) looks attractive but is not backwards
> compatible, requires a double request (not good for wireless) & has
> issues as to whether you trust the UA (in redirection scenarios).
> 
> I was looking for a consensus that (3) is a possible and valid thing to
> do for these Service Providers. If the IETF SIP group agree that (3) and
> not (1) is _a_ valid solution to this problem, then there is more chance

Honestly, I am flattered that you are hoping for the IETF blessing for
building a service. However, building such an anonyzmizer in (3) is well
within the scope of the SIP protocol, and requires no standardization
activity or consensus from IETF. I personally believe that you need a
full b2bua, since privacy, from a user perspecitve, WILL involve
stripping everything which might reveal identity, no matter whether the
header formally has identity information or not. Thus, I am not sure
what there is to do, but to emphasize to our friends in 3gpp to NOT
always put anonymous values in the To/From as this clearly will break
all reasonable interop with the outside world. (1) is BAD. Does anyone
dispute that?

-Jonathan R.

_______________________________________________
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

---

From: William Marshall <[email-masked]>
Date: Fri, 12 Apr 2002 09:02:58 -0400 (EDT)

Brian Rosen wrote:
> I think B2BUAs are great for some things.
> 
> I suspect that an anoymizer B2BUA is a very good thing.
> 
> To me, the service that breaks with anonymous From/To is
> the ability to call me.  If my phone rings, and the "From"
> which is displayed says "anonymous", I'm not going to answer it.
> I'll probably instruct my voicemail service to do the same.
> The Police Tip line might very well accept such calls however.

Agree on all points.

But if the best example of a "broken service" is equivalent to
the claim that "my deleting of unopened email is a
failure of the email delivery system"  ???  This is somehow a
different category than call transfers (for instance) failing.

Bill Marshall
[email-masked]

-----original message-----
From: "Rosen, Brian" <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked],
        [email-masked]
Cc: [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 12 Apr 2002 08:44:32 -0400

I think B2BUAs are great for some things.

I suspect that an anoymizer B2BUA is a very good thing.

To me, the service that breaks with anonymous From/To is
the ability to call me.  If my phone rings, and the "From"
which is displayed says "anonymous", I'm not going to answer it.
I'll probably instruct my voicemail service to do the same.
The Police Tip line might very well accept such calls however.

I'm reminded of the practices of some Hollywood types that
block Caller-Id, but won't accept calls that don't provide
Caller-Id!

Brian

> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 7:17 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

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

Brian

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 13:44:05 +0100

Brian wrote:

> But (3) is achievable now with a B2BUA, and there is no 
> standardization 
> work necessary.  Jonathan correctly pointed out that it is non-trivial
> to achieve what appears to be desired, and a B2BUA that thoroughly
> scrubbed all fields, including relaying of media, will be needed.
> No additional headers can help you.
> 

I agree completely. Others claimed that the problem did not exist.

Also, there can be a range of privacy services, requiring more, or less,
field modification etc. You will at least need to modify From/To & probably
Call-Info, Reply-To etc.

> I think we should stop worrying about this case, and try to focus on
> something we can't reasonably do now, which is to provide a network
> asserted identity when the UA itself provides anonymity.  That is a
> case worth working on, and it represents the way I think it 
> SHOULD work.

Absolutely. I hope that this thread has demonstrated, though, that it is not
*because* of RPID that people have done Bad Things with From/To, more the
other way round.

> The UA is by far in the best position to determine the level of
> anonymity it wishes, and if it can't get enough (because, for example,
> it wants it's IP addresses obscured), it will have to employ a
> B2BUA as above.  
> 

Agreed. But the UA is not in a good position to determine the subscribers
anonymity requirements, or other parties not represented by a UA. In a
Service Provider model, these people have some rights. So, the network may
have to employ a B2BUA or whatever on behalf of these people. There is no
problem with this and so no case for obfuscating the From/To fields - agreed
?

...Mark

> Sent: Thursday, April 11, 2002 11:29 AM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, 
> Jon; 'William
> Marshall'
> (*) IF the UA is allowed to put identity information into 
> From/To, THEN the
> Service Provider will be forced (by Data Protection) to 
> provide services
> which modify these fields, in order to protect the privacy of 
> people other
> than the actual calling user - subscriber, forwarding etc.
> 1) *Require* permanantly that the UA does not put identity 
> information into
> From/To 
> compatible, requires a double request (not good for wireless) 
> & has issues
> as to whether you trust the UA (in redirection scenarios).
> valid thing to do
> for these Service Providers. If the IETF SIP group agree that 
> (3) and not
> (1) is _a_ valid solution to this problem, then there is more 
> chance of
> other fora adopting (3) instead of (1).
> So far, people have been arguing against the belief (*). The 
> question is not
> whether (*) is demonstrably true but whether there is 
> sufficient *chance* of
> it being true to justify serious consideration. A significant group of
> Service Providers obviously think it is - they are worried 
> they will be in
> this situation and want a solution defined - that should be 
> enough for us to
> discuss solutions.
> So, can we agree to recommend at least that people with 
> belief (*) adopt
> solution (3) and not solution (1) ? 
> ...Mark 
> 
> 
> 
> > From: Jonathan Rosenberg [mailto:[email-masked]] 
> > Sent: 11 April 2002 08:28 
> > To: Watson, Mark [MDN05:EP10:EXCH] 
> > Cc: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, Jon; 
> > 'William Marshall' 
> > > All, 
> > > I feel profoundly lucky that yesterday and Friday were 
> > public holidays 
> > > in the UK :-) 
> > > 
> > > Perhaps I can take advantage of this vantage point to offer 
> > a summary of 
> > > the thread. Protagonists please speak up if I have 
> > mis-represented you 
> > > below, but please don't re-open old fronts. 
> > 
> > Thanks for the summary. It is well needed. I suspect much of 
> > the lack of 
> > comment derives from the difficulty in following this long thread. 
> > 
> > I would kindly request all participants to please keep the 
> discussions 
> > technical. A lot of the emails in this thread were personal 
> attacks. 
> > Many more were threats along the general line of "do X or 
> > standards body 
> > Y will do Z". I really hate the latter ones. Let us hear no more of 
> > either type of nonsense. It is not the IETF way. 
> > 
> > > 
> > > 1) Call-Info 
> > > 
> > > Long arguments about the alledged 
> similarities/differences between 
> > > Call-Info and RPID. Suffice to say that the point has 
> been made that 
> > > Call-Info (and perhaps other things) could be abused to do 
> > the things 
> > > that RPID does, and in particular to do the 'Bad Things' 
> > that some are 
> > > worried about with RPID. The point of disagreement was 
> > whether in the 
> > > case of Call-Info, this would be 'major abuse', with RPID 
> > was set up to 
> > > make these 'Bad Things' easy, or whether there was some 
> equivalence. 
> > > 
> > > The key point is that this kind of abuse of Call-Info may 
> > happen if we 
> > > do not provide an alternative. 
> > 
> > It was never our intent for Call-Info to provide any form 
> of network 
> > asserted identity that could be used in any useful way. 
> Generally, the 
> > idea was that insertion of Call-Info was either done by the 
> UA, or in 
> > the case of proxy-inserted values, was for "opt-in" 
> services were the 
> > user had signed up for content to be added. That said, there are 
> > certainly cases where the caller may opt in for this service 
> > but require 
> > privacy for a particular call, and we need a mechanism to 
> > support that. 
> > 
> > However, in no way would I support or advocate the use of 
> Call-Info as 
> > an alternative for R-P-ID. 
> > 
> > > 
> > > 2) Abuse of From/To headers 
> > > 
> > > Jon is concerned that 'untrusted RPID' provides a standardised 
> > > alternative to From/To, allowing Bad Things, like never 
> > putting the real 
> > > From/To information in the From/To fields. 
> > 
> > I think that the proper way to handle this, as pursued in 
> > other threads, 
> > is to provide a sane alternative to 3gpp so that they don't 
> do this. I 
> > believe we all agreed it would be bad. 
> > 
> > > 
> > > Others have pointed out that the draft explicitly states 
> > that untrusted 
> > > UAs MUST NOT add RPID. However the draft explicitly 
> described proxy 
> > > handling of RPID headers from untrusted sources (proxies OR 
> > UAs), and 
> > > allows these to be propogated, marked as untrusted. 
> > > 
> > > Therefore, a UA which DID add RPID, although non-compliant 
> > to the draft, 
> > > would have its RPID propogated through the network. 
> > > 
> > > 3) 'Untrustworthy RPID' 
> > > 
> > > Flemming, Bill et al argued that RPID information is still 
> > useful when 
> > > it is 'untrustworthy'. This can occur legitimately within 
> > the draft when 
> > > an RPID which is not 'private' (and so not encrypted) 
> > crosses a trust 
> > > boundary. This would represent an identity asserted by 
> Network A and 
> > > passed to Network B, when B has no explicit trust 
> > relationship with A. 
> > > 
> > > value of untrustworthy information for call trace is 
> > debatable (and has 
> > > been debated at length). 
> > 
> > IMHO, 'untrusted RPID' is identical to the From, except that it is 
> > purportedly inserted by a network element, whereas From is 
> purportedly 
> > inserted by the end user. Neither provides any guarantees. 
> The essence 
> > of the debate, I think, is whether you believe there is value 
> > to the end 
> > user in a field which is the identity purportedly inserted by some 
> > network element.  Since there is apparently value to the identity 
> > purportedly inserted by the end user, I see no reason why we should 
> > discriminate. 
> > 
> > -Jonathan R. 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue 
> > Chief Scientist                         First Floor 
> > dynamicsoft                             East Hanover, NJ 07936 
> > [email-masked]                 FAX: (973) 952-5050 
> > http://www.jdrosen.net                  PH:  (973) 952-5000 
> > http://www.dynamicsoft.com 
> > 
>

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 14:16:40 +0100

There are many privacy services between the extremes of 'entirely up to the
UAs' and 'full B2BUA with IP address anonymiser etc.'.

All of them require 'More Than Just A Proxy' because you need to modify the
From/To fields (unless you don't care about RFC2543 compatibility, in which
case you can modify these fields at something very like a proxy).

Other fields may or may not need to be modified/removed - certainly
Call-Info & Reply-To would have to go. I think you *can* run the end-to-end
data argument with things like Subject and the message body.

There is the possibility that new headers exist which carry identity
information or other Personal Data. One solution would be to remove all
unrecognised headers at the Privacy server. This will break all the new
things.

There is another way. This would be to define now a generic capability for
carrying Personal Data, along with an indication of its privacy status. All
new services introduced later which required to send Personal Data would use
this capability. So, privacy servers could be built now which would just
remove private data from this new place, leaving unrecognised headers alone.

The privacy server would still break new services based on Personal Data -
but this is the intention of the caller. The privacy server would not break
other new things.

...Mark

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 12 April 2002 14:01
> To: Rosen, Brian
> Cc: Watson, Mark [MDN05:EP10:EXCH]; 'Jonathan Rosenberg'; 
> [email-masked];
> Ben Campbell; Flemming Andreasen; Peterson, Jon; 'William Marshall'
> I agree that, in general, the UA should be treated like a mature adult
> and get to make decisions as to what information it wants to 
> include in
> its call setup requests or not. I don't agree that anonymity 
> requires a
> B2BUA in all cases. For example, one could imagine that a large ISP
> could hand out random IP addresses from a large pool, making it
> essentially similar to an anonymizer service. There is no principal
> difference between knowing that "user came from anonymizer service
> anon.com" and "user came from ISP large-isp.com". (Well, 
> almost: it may
> be easier to switch anonymity providers than ISPs.) With VPN services
> and L2 tunneling, you can probably create IP-level anonymous ISPs that
> don't require B2B UAs and cover a very large geographical area.
> 
> A privacy B2BUA would break services, since it would have to strip all
> headers, thus disabling any service that it doesn't happen to know
> about.
> 
> B2BUAs are also, it seems, much more loop-prone than proxies. For
> examples, see mailing list hosts, which are essentially SMTP B2BUAs.
> (They also illustrate the service transparency issues, with endless
> debates as to what fields should have which values and whether header
> fields should or should not be copied.)
>

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 09:50:17 -0400

I have a feeling this thread should be moved to SIPPING: we're going round
and round with requirements.  Anyway, I've seen two sensible points today
that call for action:

Brian identified a need for a mechanism by which the network provides a
network-asserted identity.  Is RPID this mechanism, or do we look for
another, or do we explore the requirements further?

Mark has just come up with a very interesting idea for quarantining
privacy-related material.  I can see immediately that this requires a good
deal of careful work at the protocol level.  Do we need some more
exploration of the requirements here?

-----Original Message-----
From: Watson, Mark [MDN05:EP10:EXCH] 
Sent: Friday, April 12, 2002 9:17 AM
To: 'Henning Schulzrinne'; Rosen, Brian
Cc: 'Jonathan Rosenberg'; [email-masked]; Ben Campbell; Flemming Andreasen;
Peterson, Jon; 'William Marshall'
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

---

From: [email-masked]
Date: Fri, 12 Apr 2002 10:31:58 EDT

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

> human-supplied/human-consumed values. I would argue that this completely

This discussion seems to have gotton off of the real requirement, which is to 
correctly handle calling user identities that are needed as part of the 
service offering. That is, the information needed to process a call setup but 
not necessarily needed by the called user (except out of curiousity). There 
have been a number of suggestions that the "privacy" service must 
remove/mask/encrypt any other information which the calling user entered, 
such as "Subject" that might give away their identity. This is absurd. No 
network or B2BUA of trusted proxy or whatever you want to call it could know 
when to do this. There can never be any "service" which changes or looks at 
the "Subject" header.

If I block my calling line ID today (telephone number) from being delivered 
to the other end and then, when someone answers, say "This is Mike Pierce", 
there is no requirement that the network remove that identity. Nor should 
there be any belief that the "network" should block the call if I voluntarily 
enter some identifying information.

As Mark Watson noted "A Service Provider may have some responsibility for 
apparently user-supplied information if it is implicit or required in the 
service that the user shall supply a certain piece of information in that 
field."

This discussion should only deal with the specific information that the 
identity/privacy service deals with. I guess that's the To and From headers 
and any new headers that might be created to get around limitations of these 
headers.

Mike

---

From: [email-masked]
Date: Fri, 12 Apr 2002 10:32:00 EDT

> all reasonable interop with the outside world. (1) is BAD. Does anyone

I think the message from some on this list is that there is no way that the 
identity/privacy "service" is going to work correctly unless there is a full 
"standard" defining the required interoperation between end user UAs and 
"network" devices supplied by "Service Providers", whether you call them 
B2BUAs, proxies, or anonymizers. By "correctly", I mean in accordance with 
the law in effect at the location where the calling and called party is. 
Unless we admit to this model as the basis for requirements, no progress can 
be made. Of course, I am referring to the model # 1 I listed in my April 4 
e-mail which were:

1. With a trusted third party (Read: service provider) which provides 
services, one of those services being to guarantee privacy/protection/etc.
2. Without a trusted third party (Read: Wild-wild west) meaning that there 
are no services being provided. End users do anything they want and no one is 
guaranteed of anything (e.g., privacy, protection, or that anything they try 
to do will neccesarily function as they expect).

As Mark Watson wrote in his e-mail of April 12: "It's not about 'telco like' 
vs 'Internet like'. It's not about the technology at all. We have to look at 
the *service* as it is supplied to the user. If you have a Service Provider 
model at all, then the Service Provider has responsibilities about what they 
do with people's Personal Data, whether the service it implemented using 
IPv20 between nano-machines or over a wet piece of string."

Once again, it seems that this discussion needs to be split into addressing 
these two completely different environments with potentially completely 
different solutions. I know that sounds bad, and contradicts some views of 
what the Internet should be, but I see no other approach.

My 2 cents worth!

Mike

---

From: [email-masked]
Date: Fri, 12 Apr 2002 11:19:05 EDT

In a message dated 4/12/02 9:30:26 AM Eastern Daylight Time, 
[email-masked] writes:

> new services introduced later which required to send Personal Data would 
> use this capability. So, privacy servers could be built now which would 
> just remove private data from this new place, leaving unrecognised headers 
> alone.

I continue to be confused by this emphasis on the "privacy" half of the 
draft. It seems to be expanding to consider "Privacy" of everything including 
what color socks the user is wearing! I know that the overwhelming thoughts 
in the IETF are to protect privacy, and I don't dispute that, but the primary 
purpose of this draft (and the "service" it defines) is to provide an 
"Identity" service, that is, providing one user's identity to the other user. 
"Privacy" is the second half. We need to agree on what that identity is and 
how it is provided. Then the second part of the issue is how that identity is 
protected when the user doesn't want it delivered to the other user (assuming 
the "network" needs it or knows it). I know this sounds elementary and maybe 
some think it is obvious, but when the discussion of "privacy" begins to 
define ways to treat future headers carrying other personal data, I think it 
is going beyond its purpose.

As Mark noted, a Service Provider may have responsibiity for user-supplied 
information if it is implicit or required in the service that the user supply 
it (to set up the call). Any extra stuff that is defined just to be passed 
end-to-end (like Subject) or for a completely different service is not a 
concern. If the user voluntarily includes it, it is not private.

For example, Dean started a discussion of a 'What-I-Want-You-To-Call-Me:' 
field instead of "From". To me, the fundamental difference is that the "From" 
field is part of the call setup specification and the "network" should 
require it, but the "What-I-Want-You-To-Call-Me" field could be see as only 
being of end-to-end significance and not looked at by the "network". The 
basic question for this and any field is: "Is it part of 'Identity' or is it 
supplemental information?"

Mike

---

From: [email-masked]
Date: Fri, 12 Apr 2002 11:19:01 EDT

> exploration of the requirements here?

I agree that this needs to be moved to SIPPING and focus on the requirements. 
We need to get away from the discussion of protocol mechanisms for awhile and 
agree on what the requirements are.

The issues from the 2nd and 3rd paragraphs above, levaing out the protocol 
stuff, are:

What are the requirements for the network to verify a user provided identity?
What are the requirements for the network to add a network-asserted identity?
Are there requirements to "Quaratine" or hide any other user provided 
identity related material?

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 16:42:27 +0100

Mike,
 
My suggestion of a generic mechanism to carry Personal Data was targetting
at future work, not the present privacy draft.
 
Two points:
1) It's not just about privacy for the calling user - that's relatively
easy, you just need a mechanism to 'privately' pass information to trusted
network entities and apart from that it's up to the UA what it does/doesn't
reveal. The big problem is when other people are involved who do not have an
'agent' representing them. A subscriber to a public service is an example.
These people have rights which only the Service Provider knows about. The
Service Provider cannot be responsible for sending Personal Data of the
subscriber to the called party. Unfortunately the identity of the calling
user can often include personal data of the subscriber.
 
2) You said 'If the user voluntarily includes it, it's not private'. Sure,
it's not private *as far as the user is concerned*. But it might be private
with respect to other people. So the question is who was *responsible* for
sending it. If it's entirely the user then no problem - same as if it's the
first thing the user says after Answer. The problem is that To/From are a
grey area, since the SIP spec clearly intends that they contain the
calling/called identities (as would a spec for
'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service
which did not modify the From field would be pretty rubbish, whereas one
which did not modify the Subject would probably be fine.
 
...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 April 2002 16:19
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

I continue to be confused by this emphasis on the "privacy" half of the
draft. It seems to be expanding to consider "Privacy" of everything
including what color socks the user is wearing! I know that the overwhelming
thoughts in the IETF are to protect privacy, and I don't dispute that, but
the primary purpose of this draft (and the "service" it defines) is to
provide an "Identity" service, that is, providing one user's identity to the
other user. "Privacy" is the second half. We need to agree on what that
identity is and how it is provided. Then the second part of the issue is how
that identity is protected when the user doesn't want it delivered to the
other user (assuming the "network" needs it or knows it). I know this sounds
elementary and maybe some think it is obvious, but when the discussion of
"privacy" begins to define ways to treat future headers carrying other
personal data, I think it is going beyond its purpose. 

As Mark noted, a Service Provider may have responsibiity for user-supplied
information if it is implicit or required in the service that the user
supply it (to set up the call). Any extra stuff that is defined just to be
passed end-to-end (like Subject) or for a completely different service is
not a concern. If the user voluntarily includes it, it is not private. 

For example, Dean started a discussion of a 'What-I-Want-You-To-Call-Me:'
field instead of "From". To me, the fundamental difference is that the
"From" field is part of the call setup specification and the "network"
should require it, but the "What-I-Want-You-To-Call-Me" field could be see
as only being of end-to-end significance and not looked at by the "network".
The basic question for this and any field is: "Is it part of 'Identity' or
is it supplemental information?" 

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 12 Apr 2002 18:51:46 +0100

At the risk of repeating myself  -  well, it's never bothered me before :-)
- please see below. All comments assume a Public Service Provider model...

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 12 April 2002 16:52
To: [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Mike wrote:
------------- 
 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.  
-------------- 
 
I don't completely disagree. In fact, I'm arguing the requirements.
 
The point I'm trying to make is that To and From are USER supplied
information. The Service Provider doesn't insert them, inspect them, or have
any responsibility for them. Insisting that the service provider change them
is just like insisting that the service provider change any other
user-supplied information, such as the words I'm typing now. Anything I put
in my To or from field is deliberately and explicitly intended to be
delivered to the terminating side of the dialog, and if as a service
provider you FAIL to do that, then you have DAMAGED my data, and my lawyers
will be in touch! 

For this discussion to make ANY sense we have to stop talking about user
device & network devices and which does what etc. etc. The only important
point is what is the *service* that the service provider is offering. If it
is a mandatory part of the service that a certain piece of personal data is
passed to the service provider, then the service provider has a
responsibility not to reveal that if the user *or subscriber* does not want
it.
 
It does not matter one iota whether the piece of data was inserted by the
user equipment of something else.
 
Basically, the functional distribution of the system is irrelevant, what is
important is what it does.
 
Now if the service involves carrying an opaque piece of data to the called
party, then obviously the only person with responsibility for that is the
person generating the data.
 
If I understand correctly, Dean, you are arguing that the To and From fields
work like this.
 
I have been arguing that this MAY not be a reasonable position for a Service
Provider when arguing their case with respect to Data Protection. This is on
the basis that the SIP spec pretty clearly implies that these fields will
contain certain information and a Service Provider could reasonably be
expected to know this.
 
Plus "a 'subscriber privacy' service which did not modify these fields would
not impress the subscriber much, as 99% of calls would go through with
personal data of the subscriber presented to the called party" - (I'm going
to put that one on a function key :-)

The calling-party-identity presentation infromation (CLIP or RPID) is NOT
inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of
the user. As such, the operator is responsible for the protection of that
information in a manner consistent with regulation and the expressed wishes
of the user. 

Absolutely. 

The calling-line-identity-restriction information (CLIR or Privacy) is a
means by which the user expresses wishes with respect to the handling of
NETWORK provided information.
 
This divides data into three classes:
 
1) Data inserted by a user's system, under the control of a user, and
intended to be delivered to the termination of the dialog
2) Data inserted by a user's system, under the control of a user, intended
to be delivered to an intermediate system and not beyond
3) Data inserted by the network, without the awareness of a user, intended
to be delievred to an intermediary or terminal point.
 
Service providers are by regulation in reasonable nations required to
prevent class 2 information from being leaked, and to respect the user's
preferences for delivery of class 3 data.  

Or rather:
1) Opaque data on which the service places no requirement or expectation
2) Data required or expected to be supplied by the user to the service
provider as part of the operation of the service
3) Data used within the service provider for the provision of the service

The problem is, the "normal" telephone network doesn't obviously HAVE
user-provided information in the signaling path which is intended to be
delivered to the other end, so telco people start by assuming that all
signaling is the responsibility of the service provider. But there really is
something analogous. Consider Q.SIG, user signaling at the ISDN level
generally used for PBX-to-PBX work. What Mark has been arguing is
essentially like arguing that a service provider must PREVENT the delivery
of Q.SIG data because it MIGHT compromise Data Privacy. Of course it does!
It's SUPPOSED to! The operator's responsibility is to limit the delivery of
the data to the intended party (as opposed to deliverying it to somebody
else), not to keep the user from communicating with the intended party.

Great choice of example ... I know just a little bit about this ...
 
Applying my argument to the Q.SIG data would imply that the subscriber has a
right to request that this data not be delivered. Well, that's exactly how
the service works, certainly according to the ITU-T standards, because the
Q.SIG data is only delivered within a closed user group. i.e. the subscriber
expresses their preference as to exactly whom the data can be delivered to
in the specification of the closed user group.
 
Indeed, the subscriber would have the right to request that the information
is never delivered, but that would rather defeat the object. As has been
pointed out a few times there is a natural trade-off between services and
privacy.
 
...Mark

That's right, kids -- SIP by definition is an enhanced service channel. It
does MORE than plain-old-telephone-service. If you use it carefully, you can
emulate POTS.
 
So, what are these "anoymizer" services we keep talking about? Are they
consistent with my data class division? Notice that class #1 says "to the
termination of the dialog". In using such a service, I'm requesting that my
dialog terminate at an intermediate point which implements the service of
generating a second related but anonymized dialog. In other words, the
behavior is explicitly requested by the user, and is therefore "ok with me".
 
--
Dean

---

From: [email-masked]
Date: Fri, 12 Apr 2002 14:27:02 EDT

> at future work, not the present privacy draft.

Yes, I suspected that, but then I noticed that Tom picked up on it as an 
"very interesting idea " and seemed to be suggesting that we run with it.

> reveal. The big problem is when other people are involved who do not have 
> an 'agent' representing them. A subscriber to a public service is an 
> example. These people have rights which only the Service Provider knows 
> about. The Service Provider cannot be responsible for sending Personal Data 
> of the subscriber to the called party. Unfortunately the identity of the 
> calling user can often include personal data of the subscriber.
>  

I'm confused by what you are getting at by "subscribers" and "other people" 
(who don't have an "agent"), and "calling user". There is a SIP phone 
(containing a "User Agent") and it might be used by multiple people to place 
calls. If people don't have their own identity, then every call must use the 
identity of the physical device. If there is a capability for each person to 
provide a separate identity, then that is what is used by the "network" as 
the basis for a "subscription" to service and to apply privacy.

If you are referring to the complicated cases of how to apply "privacy" to 
identities involved in 3-way services such as call transfer and call 
forwarding, then I understand the difficulties, having been through 
excrutiating discussions in standards development for ISDN. It isn't easy or 
pretty. But these issues will only be worked out in a specific discusion of 
the interworking of the identity/privacy service with the call transfer/call 
forwarding services, something that the IETF is intent on not doing.

I still say if the user voluntarily includes something beyond the specific 
identity fields, then the network has no obligation to apply privacy to it. I 
don't see a case in which the network has to do anything else to provide 
privacy for "other people". Again, maybe there is a difference in what "user" 
refers to in your point 2) above. If the "standard" service operation (in the 
User Agent or network) puts in some identity, or passes along one it got 
during Call Transfer, then of course privacy rules must apply to it. That's 
not the user (person) voluntarily putting in the information.

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 11:18:40 +0100

Dean wrote:
 
> 
> Excellent summary, Mike. That's exactly what I'm saying.
> 
> In short:
> 
> To:/From: are equivalent to ISDN user-to-user data, as is most of
> current SIP.

But not in the case raised by Juha, where the Service Provider checks the
contents of the From field. Then these fields are more like the
user-provided Calling Party Number field which is checked by the local
exchange.

Even if the Service Provider does not do this checking, I would still argue
that there is an implicit expectation that these fields contain indentity
information, and indeed this is what most clients will put in there. I don't
think this is insignificant. It is completely different from User-to-user in
ISDN, or, say, Subject: in SIP where there is no expectation at all.

In ISDN, if you have a so-called 'Special Arrangement' then you can supply
an identity which is passed transparently through the network - no checking,
nothing. Obviously, the user only supplies an identity if they do not want
anonymity. But even if they do supply an identity, if the *subscriber* has
requested anonymity, then it is removed by the network.

Sounds pretty analogous to From: to me.

> 
> RPID: is analogous to CPN, and its "Screened" parameter analogous to
> what happens in ISDN today.
> 

Analogous to Calling Party Number within the network, and when delivered to
the Called party.

> Privacy: is analogous to the calling line identification restriction
> flag.
>  
> I think an understanding of this relationship should clear up 
> 99% of the
> debate over the "privacy" draft

Well, it would if we agreed :-)

...Mark

> , which is really much more of a SIP-T
> "telephony interworking" document than it is a general 
> privacy document.
>

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 11:32:19 +0100

Brain wrote:

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.

If you include in ' Network asserted identity' information which the Service
Provider *forces* the user to place in the messaging, then I agree. It is
about whether the service requires the information to be there, not which
device physically inserts it.  

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. 

There is Data Protection. We are not arguing about what regulations
will/won't apply, but how existing Data Protection will be interpreted in
the context of SIP services. We do have legislative guidance for services
which are 'Publically Available Telecommunications Services'. Perhaps there
is a case to argue that SIP services are so different from all other
Publically Available Telecommunications Services that Data Protection should
not apply in the same way - I doubt it though. The service as seen by the
user is not so different, but with multimedia & more flexibility. The
technology we use to provide the service is irrelevant to Data Protection.
 
My point is that it is at the *very least* 'likely' that Data Protection
will apply in the way I've described. A 'head in the sand' approach to this
is what is not helpful. We need to understand what the solutions are, or
would be, so that we can be confident we are not going to be floored by this
when it comes to deploying large-scale commercial services.
 
I'm quite happy with Jonathan's answer that you can do this with a B2BUA and
no standardisation is required. Others are arguing that the network should
NEVER modify the From/To fields, in which case I say that standardisation
*is* required for a client-based solution.
 
If we can agree that we don't need to do anything here - or that a client
based solution will be part of the more general privacy work - then we could
move on.
 
...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 11:37:14 +0100

Mike,
 
When I said 'future work', the future could be very soon. I said it on
Friday, so it could even be today :-) We have a charter item for a more
general privacy mechanism and this could be included within that.
 
Regarding 'subscriber' this is a key point about the Service Provider model.
Whenever you have a Service Provider, then there is a 'subscriber' who is
the person (legal or natural) who has contracted with the Service Provider
for the provision of the service. (I am leaving out the case where the
Service Provider offers service to just anyone for free, so there is no
contract as such).
 
At least in Europe, if the service is a 'Publically available
telecommunications service' (note that's 'telecommunications' not
'telephony'), then the subscriber has a right under Data Protection for all
calls made via their subscription to be anonymous if they so choose.
 
The most common example is where the subscriber is a company and the users
are its employees.
 
Another example of a person who is not represented by a 'User Agent' in SIP
terms during a session invokation is someone who has set their Home Proxy to
forward calls (using CPL or whatever). When a call is made, the
forwarding-party is represented only by their Proxy - their UA may not even
be connected to the network. Again, this person has a right for their
Personal Data to not be revealed by the Service Provider, so if the Service
Provider is responsible for the insertion of any such data in the messaging,
they need to capability to remove it again.
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 April 2002 19:27
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked];
[email-masked]

Mike, 

Two points: 

I still say if the user voluntarily includes something beyond the specific
identity fields, then the network has no obligation to apply privacy to it.
I don't see a case in which the network has to do anything else to provide
privacy for "other people". Again, maybe there is a difference in what
"user" refers to in your point 2) above. If the "standard" service operation
(in the User Agent or network) puts in some identity, or passes along one it
got during Call Transfer, then of course privacy rules must apply to it.
That's not the user (person) voluntarily putting in the information. 

Mike

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 15 Apr 2002 15:16:33 +0200

Hi all,
regarding the discussion what SIP Header fits to what ISUP Parameter we should know what rules apply to the interworking from SIP to ISUP. From my understanding (of the last ITU discussion in Geneva) the following rules shall apply  to the mapping of the From and Remote Party ID to ISUP parameters:
....
Note: From: is mandatory and always checked for presence.
Case-a: If RPID is absent, then do the following:
1) Additional CgPN is derived from From: (Note Jesske:because it is user provided but not verified by the service provider)
2) CgPN is assigned with Network Generated Number. (Note Jesske: with a screening indication: network provided)
 
Case-b: If RPID is present and RPI-Screen="Yes", then do the following:
1) Additional CgPN is derived from From: (Note Jesske:because it is user provided but not verified by the service provider)
2) CgPN is derived from RPID: (Note Jesske: with a screening indication: user provided verified and passed )
 
Case-c: If RPID is present and RPI-Screen="No", then do the following:
1) Additional CgPN is derived from RPID: (Note Jesske:because it is user provided but not verified by the service provider)
2) CgPN is assigned with Network Generated Number. (Note Jesske: with a screening indication: network provided)
....
The interest of big Service Provider/Carriers is to have an proper inteworking of SIP and ISUP, because the will have in future hybrid networks with SIP and ISUP (BICC) signalling. And the above mentioned rules are the first step forward for a proper interworking (my opinion) between SIP and ISUP including the CLIP/CLIR Service.

I hope this information fits in your discussion. 

Best Regards 

Roland

-----Ursprüngliche Nachricht-----
Von: Mark Watson [mailto:[email-masked]]
Gesendet am: Montag, 15. April 2002 12:19
An: 'Dean Willis'; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

> To:/From: are equivalent to ISDN user-to-user data, as is most of 

But not in the case raised by Juha, where the Service Provider checks the contents of the From field. Then these fields are more like the user-provided Calling Party Number field which is checked by the local exchange.

Even if the Service Provider does not do this checking, I would still argue that there is an implicit expectation that these fields contain indentity information, and indeed this is what most clients will put in there. I don't think this is insignificant. It is completely different from User-to-user in ISDN, or, say, Subject: in SIP where there is no expectation at all.

In ISDN, if you have a so-called 'Special Arrangement' then you can supply an identity which is passed transparently through the network - no checking, nothing. Obviously, the user only supplies an identity if they do not want anonymity. But even if they do supply an identity, if the *subscriber* has requested anonymity, then it is removed by the network.

> what happens in ISDN today. 

Analogous to Calling Party Number within the network, and when delivered to the Called party. 

...Mark

---

From: "Chiou, Mark" <[email-masked]>
Date: Mon, 15 Apr 2002 10:02:30 -0500

Sounds like you prefer separate the User provided information from Network provided information. I agree with you as long as we address a privacy header which is inserted by the originating Service Provider and extracted by the terminating Service provider. (The Privacy information should not be delivered to the UAS.)
The same Privacy header information is also used to interwork with PSTN world for APRI purpose. 
 
Mark Chiou

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Monday, April 15, 2002 9:44 AM
To: Chiou, Mark; Dean Willis; [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case.
 
I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. 
 
Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,?
 
 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chiou, Mark
Sent: Monday, April 15, 2002 9:28 AM
To: Dean Willis; [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote:
#####################################

The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch!
 
The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user.
<snip>
 ##########################################################
No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE.
 
Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication.
 
This is my penny thought,
 
Mark Chiou

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 17:24:17 +0100

Juha,

I am not arguing that standardisation is required. I believe the necessary
capabilities can be provided with a B2BUA as described by Jonathan and
yourself (or something between a proxy and a full B2BUA).

I am arguing against the belief that there is NEVER a requirement for the
network to modify fields like From/To. It is this belief that has led other
people to distust these fields and specify that no information should be
included.

The worry is that if you allow potentially private information into those
fields, then this will cause trouble because there is an assumption/belief
at large in the SIP community that these fields should never be modified.

If we could agree that it is at least _likely_ that privacy services which
modify From/To will be required by Public Service providers, there would be
no more reason to distruct the fields and we could all use them for their
intended purpose.

...Mark

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: 15 April 2002 16:06
> Cc: Dean Willis; [email-masked]; [email-masked]
> Mark Watson writes:
>  > I think many service providers will wish to do the same, 
> and indeed this
>  > checking is required in 3GPP. The situation is much 
> clearer in this case,
>  > because in order to access the service at all, the user 
> MUST insert their
>  > true identity (or 'anonymous') into the From: field.
> 
> if the call goes to pstn, the user gets calling number anonymity by
> using Anonymous as the display string.  if the call goes to 
> another sip
> user, the same thing happens, but i must implement b2ua and 
> rewrite the
> from header.  no standardization is needed in order to 
> accomplish this.
> 
> -- juha
>

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 17:33:08 +0100

Christian,

If you want to provide complete unassailable anonymity, I agree completely.
I have been arguing about providing a similar level of anonymity as the
PSTN, where the called party is not informed who the call is from by the
service itself. It's more about Data Protection than strict anonymity.

In the PSTN there is no problem for certain authorised organisations
(including the courts) to obtain the details of the call from the Service
Providers if they have good reason. Data Protection does not protect you
against these organisations.

...Mark

> From: Christian Huitema [mailto:[email-masked]]
> Sent: 15 April 2002 17:10
> To: [email-masked]
> I have heard many contributors assert that to get real anonymity, one
> will have to use a relay, e.g. an "anonymizing B2BUA". I would like to
> point out a failure in this line of reasoning: anonymizing relays have
> been tried before, for e-mail, and the experience was absolutely not
> conclusive. In fact, two different kind of anonymizers have 
> been tried:
> free ones, that kept absolutely no record, and subscriber-based, which
> kept some records. Both have failed, for different reason.
> 
> The failure mode of a completely free relay is basically spam, and
> similar sort of abuse. There is documentation available on 
> the fate for
> example of the cypherpunk experiment: this set of relays was set up to
> provide true anonymity on the Internet, using a sophisticated mix of
> random redirection and cryptography. In theory, the design was
> excellent. In practice, the system was quickly overwhelmed by porn
> traffic, and the relays dropped one by one out of the system because
> they could not bear the resulting congestion.
> 
> Subscriber based relays are relays that keep some state: they actually
> identify the sender, before washing out the identity in the outgoing
> message. They are more robust to congestion, since they can get some
> funding in the process, but they have a different failure 
> mode: lawsuit.
> Since they keep some records, the records can be subpoenaed, and the
> provider can be forced to disclose the identity of the 
> sending party. In
> fact, in many codes, if the providers refuse to do so, they may be
> deemed an accomplice of whatever action was carried out in 
> the anonymous
> exchange. Many providers have chosen to close their doors rather than
> have to defend more lawsuit -- often after a brush with the Church of
> Scientology.
> 
> If we really want practical anonymity, it has to be based on 
> the UA, and
> it should not rely on the help of a third party. We should use a
> combination of encryption, pre-paid subscriptions, and anonymous IP
> addresses (e.g. IPv6 privacy addresses.)
> 
> -- Christian Huitema
>

---

From: [email-masked]
Date: Mon, 15 Apr 2002 12:49:43 EDT

In a message dated 4/15/02 10:45:08 AM Eastern Daylight Time, 
[email-masked] writes:

> You pretty much have to assume that the receiving user sees _anything_ you 
> send his UA, except in the rare case where the user has no control over the 
> UA behavior. Asking a UAS to hide information from its owner is not useful 
> in the generic case.

I don't believe anyone has suggested (I hope) that the receiving user's UA 
should be responsible for hiding the information. It is always the last 
"trusted" entity which must do this, i.e., the "service provider" in Mark 
Chiou's comments. The exception, of course, might be when the terminating UA 
is also "trusted" by the service provider, but I'm not sure of a good example 
of this. The terminating UA would then be like an extension of the "Service 
Provider".

> I agree with Dean on this in general, although it really doesn't matter if 
> any _network_ inserted identification is there with the consent of the 
> originating user or not. A privacy request need _only_ apply to 
> network-inserted identification data. The UAC has every opportunity _not_ 
> 

I believe that every identification inserted must be "with consent" of the 
originating user, either explicitly by user action, or implicitly by the fact 
that they made a phone call. And no, a privacy request does not only apply to 
network-inserted identifcation data. (Compare to the ISDN case in which the 
originating user inserts their phone number and also indicates that it is to 
be kept private, i.e., not delivered to the other user. The network verifies 
it and passes it through their trusted network or to another trusted network. 
The requirement in SIP is not different.)

Just to confuse the issue a little more, maybe I should remind everyone at 
this point, that, at least in the US, when the originator says their identity 
should be kept private, it is still delivered at the other end for an "800" 
call. Also, some years ago, Florida created special office codes to override 
the originator's privacy desire when calls terminated to those special office 
codes. I don't know if that stupid capability still exists in Florida.

And no, the UAC does not have the opportunity to not insert an identification 
if the "Service Provider" requires it as a prerequisite for service.
 
> Expecting the network to screen out ID that _I_ provide is a slippery slope. 
> What if I put "call from Ben" in a Subject header? Do you screen that out 
> as well? What if I _tell_ the destination user who I am in an IM associated 
> with the call? What about the media session,?
>  
> 
Providing an ID in a field defined for that prupose (for the benefit of the 
network and required trace) and have the network "screen" it is not a 
slippary slope. It is exactly what must be done and is straight forward.

I hope we have agreed across the board that the network would never screen 
the contents of other fields such as the Subject header.

Mike

---

From: [email-masked]
Date: Mon, 15 Apr 2002 12:49:40 EDT

In a message dated 4/12/02 4:07:34 PM Eastern Daylight Time, 
[email-masked] writes:

> 
> I don't think anticipating regulation is particularly helpful here.
> Anybody can say anything about what some legislature somewhere may
> legislate at some point in the future.
> 

I wasn't speaking of "anticipating regulation" but rather current legislation 
that will eventually applied to SIP-based telephony whenever someone wants to 
sell a regular telephony service using SIP in place of what is currently 
provided over circuit switched technology. It will take a very simple action 
by a state utility commission to declare that its rules for circuit switched 
also must apply to packet-based telephony. It would be foolish to ignore this 
eventuality.

> I wouldn't be too surprised if, instead of PSTN legislation, some of the
> email spam legislation finds its way into SIP behavior, e.g., having to
> declare a truthful return address, an indication of the call intent
> (like some of the laws and bills calling for adding ADV to the subject
> line) or including an opt-out link (header?). If we could make progress
> there, I think we'd do more for "privacy" than hiding a user name.
> 
> 

Just like the law today for FAX (in the US) - every call must be identified 
with the source. Yes, I suspect that this will become required for SIP, not 
necessarily by law, but by any responsible service provider as a prerequisite 
for setting up a session.

Mike

---

From: "Chiou, Mark" <[email-masked]>
Date: Mon, 15 Apr 2002 14:10:21 -0500

Mark Watson wrote:
######################
3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed.
####################  
Can we insert the privacy information into the Contact header when 3xx response is generated for forwarding (redirecting) calls?  Just a thought.  
 
Mark Chiou

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 10:17:16 +0100

Why would you trust the UA to obey this ? How could you police this if the
calling UA is getting service through a difefrent service provider from the
forwarding party ?
 
...Mark

-----Original Message-----
From: Chiou, Mark [mailto:[email-masked]]
Sent: 15 April 2002 20:10
To: Watson, Mark [MDN05:EP10:EXCH]; Ben Campbell; Dean Willis;
[email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Mark Watson wrote:
######################
3) What about a user who has asked their home proxy to forward calls, and
who wishes to remain anonymous - is the inclusion of this persons identity
in the To field just a policy violation ? How many UAs have an option to set
the To field blank ? This would be more of a 'call rejection' service than a
'call forwarding' service. I think that if in trying to get a Data Protected
version of a service, the user finds that they can't have the service at
all, they would be entitled to be a bit miffed.
####################  
Can we insert the privacy information into the Contact header when 3xx
response is generated for forwarding (redirecting) calls?  Just a thought.  
 
Mark Chiou

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 14:43:49 +0100

A 'no anonymous calls' policy would be in breach of the users right to make
anonymous calls. It is not the network that is deciding that the user does
not mind if the call is anonymous, it is the subscriber, and they have a
legal right to do this. The subscribe must be able to control what
information the network reveals about them. The user does not have the right
to ask the network to reveal information that the subscriber does not want
revealed - although the use can of course reveal the information themselves.

I was referring to a no anonymous calls policy on the part of the
subscriber.  

I know you were. I no anonymous calls policy on the part of the _subscriber_
would breach the _users_ right to make anonymous calls. 

Frequent reject-due-to- policy-violation-oops-retry cycles are just
unaceptable for wireless environments. There must be a 'works first time'
solution. If you think the user needs to be informed that their call has
become anonymous, then fine, let's standardise this indication. 
 
A wireless network is one in which the network tends to excercise a lot more
control over the UA than might be typical for other environments. It this
case, the network is likely to be able to push configuration to the phone
itself (i.e. the config for "what default privacy option to use". (This of
course makes the b2bua changing From headers more feasible as well, as
wireless providers tend to have fewer qualms about asserting this level of
control.)  

Indeed. If I have to specify special client behaviour not defined in
RFC2543, then I might as well assume bis compliance, and then I can modify
From/To without needing to keep state and modify them back on responses -
easy.
 
However, my personal view is that we should minimise the requirements on SIP
clients in order for them to work on the wireless network. The more
wireless-specific requirements or worse, requirements specific to a
particular wireless system, then the less SIP clients will be developed for
that environment, which is a bad thing.
 
The problem with the 'config push' option is that it makes it hard to
develop more complex policies on behalf of the subscriber (e.g. based on
destination), because the whole policy is dictated by the flexibility of the
configuration that you can push to the user, which is limited by what is
standardised.
 
OK, so we could use 'config push' for the regulatory requirement for an
'always anonymous' service, and do more complex things with B2BUAs. But I
would like a single solution and anyway you are arguing that From/To
modification is NEVER required.
 
...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 14:58:01 +0100

> fine and i don't have any problem with any of that.  the 
> display string
> does protect the privacy of the user according to his/her 
> wish either on
> call by call basis or for all calls.
> 

You have to honour the wishes of the SUBSCRIBER as well. I've explained why,
but that does not seem to be not enough for you, so look up the law
(97/66/EC) on the EU website (http://www.europa.eu.int/)

For clarity, I am not saying that I know this law to be 100% applicable to
SIP services - I am not a law court, so I could not do this - I am arguing
that it is likely that this or very similar requirements will apply, so we
should know how to deal with them.

The proposed revision of this document contains considerations about the
unsatisfactory situation with respect to email and Data Protection and urges
the electronic communications industry to pay more attention to Data
Protection. There are fairly explicit 'threats' that if things remain (in
their view) unsatisfactory, then further legislative measures will be
considered.

Paying attention to this stuff at this stage of system development is one
way that we *avoid* the need for *more* regulations to be imposed.

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 17:17:54 +0100

Dave,

I agree entirely with what you have written below, with three
clarifications:

1) If the user is *required* by the Service Provider to insert certain
information, then, for this discussion, it is the same as the Service
Provider inserting it - i.e. it doesn't matter which piece of physical
equipment inserts it if the information *has to be there* for the service to
work. In Juha's service the From field is like this, because unless you put
in 'anonymous' you MUST put your correct identity.

2) We must consider the *subscriber's* privacy request as well as the
user's. The subscriber may be a *different person* from the user. Either we
have to automatically get the subscriber's privacy policy to the UA, or the
network has to modify the fields which were network inserted, or inserted by
the user 'on behalf of' the network as per (1)

3) Personally, I go further than (1) and argue that information *expected*
(but not strictly *required*) by the Service Provider has similar status.
The SHOULD in the SIP spec wrt the contents of From/To is enough to mean
that a credible subscriber anonymity service should consider these fields.

So, my argument is that EITHER modification of the From/To fields may be
required in the network OR standardisation is required to reliably get the
subscriber's policy to the UA & deal with other similar problems.

To date I've seen no credible proposals for the latter, so I'm arguing we
should assume the former.

**The effect for the IETF SIP group** is only that it becomes a
'non-assumption' that the From/To fields are immutable within the network.
Future capabilities should be designed with this non-assumption wherever
possible, so that they are not broken by devices which do this. This is all
I am arguing about.

There will, of course, be some services which *are* broken by such devices.

...Mark

> From: David R. Oran [mailto:[email-masked]]
> Sent: 16 April 2002 15:00
> To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
> Mark,
> I must admit that I am not following at all what you are 
> saying. As far
> as I know, the privacy laws and regulations are meant to protect
> personal information disclosed by the person *to his service 
> provider*,
> either via the act of subscribing, and/or by the act of invoking the
> service.
> 
> I think that the vast majority of the information the user puts in SIP
> messages (either header or body) are no more "information disclosed to
> the service provider" than the contents of files he FTPs, or dirty
> pictures in a jpeg MIME body. They are information disclosed TO THE
> RECIPIENT, which the service provider just happens to see going by, or
> acts on to provide services for the user. If it were required that the
> service provider not disclose this information, they'd all be getting
> sued for not encrypting all the traffic going by. The exception are
> things specifically for the consumption of the service 
> provider, such as
> proxy-authenticate tokens and the like.
> 
> I think the information that is of relevance to this 
> discussion is stuff
> that was *NOT* inserted by the user, but was instead inserted by the
> service provider based on things the user had previously disclosed to
> the service provider. These are the things which in fact do need some
> level of protection, which is why we have this complicated 
> applicability
> statement on the privacy draft and why (I at least) would 
> argue that the
> only reasonable design is one in which any identifying information
> inserted by the service provider be encrypted or otherwise protected
> from disclosure to other parties (including the callee) unless the
> customer explicitly requests it not to be.
> 
> This last, is of course, just a matter of the default setting of the
> privacy: header, which can be handled by default UA configuration and
> need not be the subject of protocol standardization.
> 
> Dave.
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
> Watson
> Sent: Tuesday, April 16, 2002 9:31 AM
> To: [email-masked]'
> Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
> [email-masked]
> Juha wrote: 
> > i don't see how "who pays for the service for a set of 
> users" has any 
> > relevance to the privacy discussion. 
> > 
> Then you should take this up with the European Commission, and other
> legislative organisations in the rest of the world.
> The identity of the user is considered by them to (potentially) reveal
> Personal Data of the subscriber. Personal Data is protected by 'Data
> Protection' laws which you are free to disobey if you don't mind the
> fines.
> [It's not 'who pays', is it who has legally contracted for 
> provision of
> the service (usually the same person who pays).]
> > i do insist individual usernames and passwords.  if you do not have 
> > that, then there is no way to figure out who made the calls, 
> > which is a 
> > VERY big problem both for the company and for system in general. 
> The requirement is not about usernames, passwords, UAs, SIP, packets,
> IP, clients, proxies, networks etc. etc. This requirement is about
> services, service providers, Personal Data, subscribers, users and the
> protection of their data according to the law.
> ...Mark 
> 
>

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 19:04:19 +0100

Dean wrote
> From bis:
> 
> -----
> 8.1.1.3 From The From header field ...
> It is used by SIP elements to determine which processing rules 
> to apply to a request (for example, automatic call rejection)....
> -----
> 
> Note that the strongest requirements statement about usage here is a
> "SHOULD" class statement on anonymity, and guidelines include 
> "possibly
> the user's address-of-record" on content in general. The SIP spec does
> NOT mandate that the From field: contain any specific 
> information. This
> is in some measure intended to prevent the regulatoryistic (I 
> just made
> that up) abuse of the field. 

It doesn't mandate, sure, but the *implication* is important. The fact that
it might be used for services, processing rules, etc., gives (some) people a
strong feeling that it ought to be accurate.

Of course, on the Internet, no one can hear you scream 'you lied about your
identity!'

In a Service Provider environment people have different expectations, which
is why even SHOULD level requirements like that above lead to a feeling that
the Service Provider must check the value of the field.

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 10:12:49 +0100

Rohan wrote:

> I do not buy the argument that we need the network to provide this
> service, but that it is somehow a burden for the network to 
> implement this
> service using a B2BUA.
> 

This is not what I have been arguing. I agree that this type of anonymity
service will require more than a plain proxy (which by some definitions
means it's a B2BUA).

I know this will break (some) services.

I want to minimise the (future) services that break, by avoiding the
assumption that such devices do not exist.

Regards...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 12:18:40 +0100

Henning wrote:

> No reasonable provider should put that requirement on From, for the
> reasons Dean mentioned. This leaves the proxy-authentication data.
> Interesting question is whether the proxy-authentication data needs to
> be stripped after it has been "used", as it may well apply to several
> down-stream proxies.
> 

I believe the view amongst providers in 3GPP is that they would expect such
a requirement to be placed on the From field, if any information is to go in
there at all. They are _mostly_ reasonable in 3GPP :-)

If the proxy-authentication data could include the plain-text (user)name of
the user, and if the user or the subscriber has requested privacy, then the
information certainly could not be passed on.

I suppose you could pass it on to a 'trusted' entity, assuming that this
entity could reliably determine the intersection of the subscribers and
users privacy requirements so it knew what to do next.

Regards,

Mark

---

From: [email-masked]
Date: Thu, 18 Apr 2002 15:39:48 EDT

In a message dated 4/15/02 12:15:28 PM Eastern Daylight Time, 
[email-masked] writes:

> conclusive. In fact, two different kind of anonymizers have been tried:

What you said in the rest of the e-mail about the failure of anonymizing 
B2BUAs sounded pretty "conclusive" to me. (rather than "not conclusive" as 
you said above). Can we agree that anonymizing B2BUA is not an acceptable 
answer to any privacy requirements?

Mike

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Apr 2002 17:26:46 -0500

I wanted to speak to some of these points.

I agree that privacy starts with the user agent - populating headers with
appropriately private values and so forth. I also agree that getting
dynamic, 'anonymous' IP addresses is a way to achieve the privacy that one
might otherwise request from an intermediary. I don't agree, however, that
this means we should abandon any line of reasoning that uses intermediaries.
Although the heyday of penet.fi is long-gone, there are still third-party
anonymizer services for SMTP and HTTP in operation today. There are sorts of
anonymity that are valuable and which rely on intermediaries. Sometimes, it
might not be obvious to users how 'private' their IP addresses are
(something you wouldn't want to be wrong about, eh?). Sometimes, users may
not have control over how the headers of their messages are populated.

Even getting privacy from the same service provider from whom you get SIP
registration services makes sense in some cases. If I buy my service from a
very large service provider (MSN, say), then simply revealing my service
provider is unlikely to reveal my identity - if MSN provided anonymization,
I'd feel relatively anonymous using their service. For many sorts of
interactions this may be an adequate amount of privacy - sort of like seeing
the postmark, with its zip code, on a letter without a return address.
Agreed that if the xenuphiles sued MSN for my anonymous wrongdoings, MSN
would undoubtedly pony up my name. But if you are doing things with
third-party-provided anonymity that will bring legal sanctions against you,
then you had better be sure you have a crusading anonymity provider that is
willing to become a political prisoner in your stead - even that is,
however, not entirely unheard of.

So in short, I see no harm in recognizing both anonymous IPs and
intermediaries as means to achieve privacy. As it happens, both are
mentioned in my new privacy draft.

Jon Peterson

NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 12:40 PM
To: [email-masked]; [email-masked]
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

Mike