Subject: RE: FW: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 13:00:38 -0600

Some further notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 10:20 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'
> Subject: Re: FW: [Sip] Comment, SIP Privacy draft
> 
[snip]
> >
> > I think it takes a relatively hostile reading of Call-Info to suggest
that
> > this is an appropriate usage.
> >
> 
> No more hostile than to suggest that Remote-Party-Id is for user-asserted
> identity, when both the title, applicability statement and the text
throughout
> specifically says that the draft does not deal with user authentication.
The
> fact that Remote-Party-Id *can* be used for this is another story, just
like
> Call-Info *can* be used for this.
> 

One huge difference is that the backers of the Call-Info header did not
openly intend to use it for user-asserted identity (let alone any form of
identity). In the case of RPID this is exemplified in sip-privacy-04 by the
presence of the 'screen=' parameter. In the past, you've made the case that
carrying around unverified, user-asserted identities is useful for RPID.
This goes very much against the spirit of the AS.

I fear that we're losing sight of the points that motivated this whole
discussion (or more selfishly, my own involvement). I don't want to destroy
sip-privacy-04. I want to see things like 'screen' removed so that the
mechanism comes into parity with the applicability. If you honestly
supported the sentiment you tout above, I believe you would have no problem
removing 'screen'. To me this is all about bringing the mechanism into
conformity with the applicability. I only entered into this fray because of
the ways that RPID was proposed to be used, because a concrete case was
raised in which a major customer of SIP wanted to abuse RPID and create
serious interoperability concerns. 

I don't think this is a double standard - the squeaky wheel gets the grease,
and RPID happened to be squeaking. While you and Bill have made a reasonable
case that Call-Info as its syntax is described could theoretically be
misinterpreted, to date I must point out that it hasn't been (outside of
this little thought-experiment). If someone did put out an I-D proposing the
use of Call-Info for things along these lines (for example, proposing a
'screen=' and 'privacy=' parameter for Call-Info, and then appropriate proxy
handling for Call-Info in a 'trusted federation of networks'), I doubt it
would pass WGLC. Why these Call-Info arguments should encourage us to
proceed with sip-privacy-04 as it stands is mysterious to me.

> -- Flemming

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Fri, 29 Mar 2002 14:16:37 -0500

> This goes very much against the spirit of the AS.

No I have not. I have said (and still do), that if I receive a Remote-Party-Id
from an untrusted source, then I should still be able to pass that along with
the proper security settings (i.e. verified or not). Another source can be
another network (for example a call originates from an Iraki service provider
and enters a US network) which is my motivation. Now it just so happens that I
can't (and won't) want to make a distiction between an untrusted user and an
untrusted something else, because it doesn't make any sense to me.

> discussion (or more selfishly, my own involvement).

I agree.

> I don't want to destroy
> sip-privacy-04.

Well, I think it is an a coma, and is probably best left there for now. We are
clearly getting nowhere on this issue, and there are other issues you have
raised that we haven't even started addressing. One of the problems we are faced
with is, that we do not have a common understanding of the problem we are trying
to solve and the requirements that must be satisfied. At this point, I seriously
doubt we are going to get to any kind of consensus without those, so I would
suggest that our chairs identify someone to start driving problem statement and
requirements for this (and it probably should not be any of us that have been
involved too heavily in this discussion). Once we get those nailed down, we can
then decide if the privacy-04 draft can be salvaged or if we need something
completely new.

Comments ?

-- Flemming