Subject: [Sip] Comment, SIP Privacy draft

From: "Dean Willis" <[email-masked]>
Date: Tue, 26 Mar 2002 15:00:28 -0600

This is from a private thread that probably needs to be taken to the
list:

Dean Willis wrote:

> I would argue that the draft goes outside its applicability statement 
> anytime it discusses providing privacy. As written, it DOESN'T provide

> privacy. It provides a means whereby a user can REQUEST that network 
> elements NOT PUBLISH additional information that, if published, would 
> compromise privacy. I believe that "publish", in the context of this 
> document, means "distribute outside a group of proxies with a shared 
> administrative policy of mutual trust."
>
> And I think it is the lack of mutual understanding agreement at this 
> level that is the holdup.

--
Dean

_______________________________________________
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: Tue, 26 Mar 2002 17:51:27 -0500

Dean Willis wrote:

> > anytime it discusses providing privacy.

This seems rather backwards to me. Are you saying that the applicability
statement is an exhaustive listing of scope and requirements and anything
that is not listed in there can by definiton not be mentioned in the
document ?

> As written, it DOESN'T provide
>
> > compromise privacy.

Well, it notes that there are different degrees of privacy and provides
procedures for not only hiding this additional information, but also
discussion about other headers that need to hidden. It also discusses IP
address privacy, which will give you full privacy, however, at your request,
the Anonymity header that used to solve this was removed, but the issue is
still discussed.

> I believe that "publish", in the context of this

Proxies or User Agents. Also, do not forget the call trace requirement,
which was an integral part of the motivation behind this draft (of course
per your argument, we now can't support call trace either since that's not
part of the applicability statement).

> > level that is the holdup.

I have no idea what the continued holdup is since there's rarely anything
concrete on the table on the mailing list. It would be helpful if we got
something from the people that have concerns.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 26 Mar 2002 20:57:37 -0600

> > > I would argue that the draft goes outside its applicability 
> > > statement anytime it discusses providing privacy.
> 
> This seems rather backwards to me. Are you saying that the 
> applicability statement is an exhaustive listing of scope and 
> requirements and anything that is not listed in there can by 
> definiton not be mentioned in the document ?

Well, I'm suggesting that the draft SHOULD NOT include functionality
that is clearly OUTSIDE the scope specified by the applicability
statement. That's why we're getting the push back saying the document is
inconsistent with the AS. Why should a draft present mechanisms to solve
problems for which the draft declares itself "not applicable"? That
means either adjust the scope of the draft, or adjust the scope of the
AS, as needed and allowed by our "spirit guides" in the IESG . . .

> > > elements NOT PUBLISH additional information that, if published, 
> > > would compromise privacy.
> 
> Well, it notes that there are different degrees of privacy 
> and provides procedures for not only hiding this additional 
> information, but also discussion about other headers that 
> need to hidden. It also discusses IP address privacy, which 
> will give you full privacy, however, at your request, the 
> Anonymity header that used to solve this was removed, but the 
> issue is still discussed.

Could I propose we abstract that discussion of privacy concepts into the
baseline of a general privacy requirements and definition doc? That
would be cool! We need such a doc, and it would help manage the "Scope
vs AS" issues on this doc.

> Proxies or User Agents. Also, do not forget the call trace 
> requirement, which was an integral part of the motivation 
> behind this draft (of course per your argument, we now can't 
> support call trace either since that's not part of the 
> applicability statement).

Well, that gives us good reason to push back on the AS. OTOH, I bet the
security droids would chew on us less if the "sensitive" information
were always cryptoprotected, as you propose to do to meet the
call-traceback-from-outside-the-trust-domain requirement.
 
> I have no idea what the continued holdup is since there's 
> rarely anything concrete on the table on the mailing list. It 
> would be helpful if we got something from the people that 
> have concerns.

Color me "concerned". 

--
Dean

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 26 Mar 2002 22:34:41 -0800

Furthermore, per the AS this really has nothing to do with Privacy. If this 
draft is simply to meet the needs of supporting Caller-ID in SIP to PSTN 
scenarios, you should remove the word "privacy" from the entire draft and 
replace it with "screening". Then perhaps you can create a separate draft 
which deals with more pure Internet scenarios for privacy.

I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball 
rolling on that one so we can get it out of the way and work on more 
interesting stuff.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Mar 2002 08:48:56 -0500

> AS, as needed and allowed by our "spirit guides" in the IESG . . .

If the AS is trying to be a complete listing of requirements then it is
clearly deficient. Moreover, if this is indeed the intention with an
applicability statement, then it is very concerning, that we have this
applicability statement being forced into the document by our "spirit
guides" at the last minute without any discussion about the actual
requirements. As I mentioned before, call trace completely fell through the
cracks here essentially rendering the draft useless for what it was supposed
to do. As this discussion shows, there is disagreement on other points as
well.

> vs AS" issues on this doc.

I agree we need a requirements document for the general privacy problem (and
perhaps also for this document), but I'm not sure I see how that helps with
the document at hand.

> call-traceback-from-outside-the-trust-domain requirement.

That is already an option described in the document today. However, as
noted, it has some unsolved problems. Also, this doesn't address the issue
we started discussing, namely how to handle untrusted Remote-Party-Ids.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Mar 2002 08:56:57 -0500

Matt Holdrege wrote:

> scenarios,

But it is not - what gave you that idea ?

> you should remove the word "privacy" from the entire draft and

I can't believe I'm hearing this. When the DCS group came to the IETF ~3 years
ago with this and other extensions, people complained that everything was too
PSTN specific and that the idea with SIP was not to replicate the ISUP
parameters one by one. I thought it was good feedback then, and I still think
it is. However, we are now going full circle, and you want to start replicating
the ISUP parameters and only think about SIP-PSTN interworking. I still have
higher hopes than that.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 27 Mar 2002 09:31:07 -0800

>But it is not - what gave you that idea ?

The AS. And the way the draft is being applied in other groups.

>the ISUP parameters and only think about SIP-PSTN interworking. I still have

Re-read the above where I say let's get caller-id out of the way to work on 
the more interesting stuff. The fact is that we need SIP to PSTN 
interworking. If you are not interested in that, fine. You can work on the 
more general case and I fully support that. But some of us still care about 
interworking with the PSTN and we need to get that bit specified ASAP 
before the world is polluted with proprietary SIP headers.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 27 Mar 2002 14:57:58 -0500

Matt Holdrege wrote:

> interworking. If you are not interested in that, fine.

That's hardly what I said.

> You can work on the

If that's all you want it's pretty easy:    Just add an ISUP body to all your SIP
messages and fill in the blanks. However some of us were hoping for something a
little more general and useful.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 27 Mar 2002 12:08:45 -0800

At 11:57 AM 3/27/2002, Flemming Andreasen wrote:

>M

No, we actually need the Remote Party ID and restricted flag. I also hope 
for a more general and useful way to deal with privacy. But it seems like 
that's going to be a difficult sell or at least a longer term project than 
originally expected. So it would be nice to get something less out the door 
now so that Service Providers can use it today, and the ITU-T and 3GPP 
won't go off and do something to the SIP headers that the IETF doesn't support.