Subject: [Sip] Updated acr-code

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 22:15:55 -0400

I've submitted an update to the acr-code draft. You can pick it up at:
http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt

This draft addresses AD comments raised during AD evaluation. The 
primary change is that, previously, the specification indicated that a 
P-A-ID header field with an anonymous URI in it would count as an 
anonymous request. However, P-A-ID doesn't reflect what the user wants, 
which is strictly in the From. Consequently, PAID is really irrelevant 
here. So, this condition was removed.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Wed, 11 Jul 2007 13:25:07 +0200

Dear all,
I still have a problem that the "header" privacy value is not included.
Due to the lack of a correct description what header privacy means within RFC3323 my understanding is still that header also includes all headers that should be deleted or anonymised when the "user" privacy values is used.

And it is also not clear if header includes the "id" privacy or not.

With regard to this arguments the ACR Response has also to be sent when "header" is used.

What to do now?

Also there is a different understanding what is meant by anonymous within the world. That is a regulation dependent issue. So From my understanding the use of the 433 should not to restrictive. If somebody want to use the header within his domain then let him use it.
That is my understanding.

So one solution could be that a sentence like based on network policy or regulatory requirements ACR could also apply based on other indications sent like the 'header' private value.

An other issue is that there should be work started to clarify the use of RFC 3323, 3325, 4244 and others defining privacy values.

Best Regards

Roland

Deutsche Telekom AG
T-Com, Zentrum Technik Einführung
Roland Jesske
Gateways, Protokolle, Konvergenz, TE33-6
Deutsche-Telekom-Allee 1, 64295 Darmstadt, Raum 314(Besucheradresse)
Postfach, 64307 Darmstadt (Postanschrift)
06151 83-5940 (Tel.)
06151 83-4577 (Fax)
E-Mail: [email-masked]
http://www.t-com.de

Registerrechtliche Unternehmensangaben:
Deutsche Telekom AG
Aufsichtsrat: Dr. Klaus Zumwinkel (Vorsitzender)
Vorstand: René Obermann (Vorsitzender), 
Dr. Karl-Gerhard Eick (stellvertretender 
Vorsitzender), Hamid Akhavan, Timotheus Höttges, L
othar Pauly, Thomas Sattelberger 
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.: DE50478376
***************************************************************
Deutsche Telekom AG
Supervisory Board: Dr. Klaus Zumwinkel (Chairman)
Board of Management: René Obermann (Chairman), 
Dr. Karl-Gerhard Eick (Deputy Chairman),
Hamid Akhavan, Timotheus Höttges, 
Lothar Pauly,  Thomas Sattelberger
Commercial register: Amtsgericht Bonn HRB 6794,
corporate seat: Bonn
WEEEreg.no: DE50478376

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Freitag, 6. Juli 2007 04:16
> An: IETF SIP List
> Betreff: [Sip] Updated acr-code
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2007 09:31:32 -0400

Jesske, R wrote:
> Dear all, I still have a problem that the "header" privacy value is
> not included. Due to the lack of a correct description what header
> privacy means within RFC3323 my understanding is still that header
> also includes all headers that should be deleted or anonymised when
> the "user" privacy values is used.

My understanding is different.

> And it is also not clear if header includes the "id" privacy or not.

Well, some recent work has attempted to clarify all of this:

http://www.ietf.org/internet-drafts/draft-munakata-sip-privacy-guideline-00.txt

though I disagree with parts of it, since there is really unclear 
relationship between these values. Its still not obvious what they mean. 
Indeed, according to the draft, 'header' does include P-A-ID, but 'user' 
does not. SO based on that I should include header in the list in 
acr-code. But I think it needs to be reversed.

> With regard to this arguments the ACR Response has also to be sent

Well, one answer is to punt this entirely. Acr-code can define a more 
abstract normative rule, and then privacy-guideline, should it be 
adopted, can have text that is very explicit on how it relates to ACR-code.

> 
> Also there is a different understanding what is meant by anonymous
> within the world. That is a regulation dependent issue. So From my
> understanding the use of the 433 should not to restrictive. If
> somebody want to use the header within his domain then let him use
> it. That is my understanding.
> 
> So one solution could be that a sentence like based on network policy
> or regulatory requirements ACR could also apply based on other
> indications sent like the 'header' private value.

The danger here is that we could end up with non-interoperable systems. 
If the UAC things a privacy value is NOT implying user anonymity, but a 
proxy in the terminating domain does think it means that, and thus it 
sends a 433, the UAC has no remedy and it thinks an error has occurred.

-JOnathan R.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 11 Jul 2007 15:43:14 +0200

Please note that this document is formally in IESG last call. Therefore any comments that you want to "stick" should also be made to [email-masked] in accordance with the following instructions. That doesn't preclude discussion on this list - just means that they may not be taken into account.

Regards

Keith

The IESG has received a request from the Session Initiation Protocol WG
(sip) to consider the following document:

- 'Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-acr-code-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.  Please send substantive comments to the [email-masked] mailing lists by 2007-07-19. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14158&rfc_flag=0 

> -----Original Message-----
> From: Jesske, R [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 12:25 PM
> To: [email-masked]; [email-masked]
> Subject: AW: [Sip] Updated acr-code
> 
> Dear all,
> Due to the lack of a correct description what header privacy 
> means within RFC3323 my understanding is still that header 
> also includes all headers that should be deleted or 
> anonymised when the "user" privacy values is used.
> 
> Also there is a different understanding what is meant by 
> anonymous within the world. That is a regulation dependent 
> issue. So From my understanding the use of the 433 should not 
> to restrictive. If somebody want to use the header within his 
> domain then let him use it.
> So one solution could be that a sentence like based on 
> network policy or regulatory requirements ACR could also 
> apply based on other indications sent like the 'header' private value.
> 
> An other issue is that there should be work started to 
> clarify the use of RFC 3323, 3325, 4244 and others defining 
> privacy values.
> 
> Best Regards
> 
> Roland
> 
> Deutsche Telekom AG
> Deutsche-Telekom-Allee 1, 64295 Darmstadt, Raum 
> 314(Besucheradresse) Postfach, 64307 Darmstadt (Postanschrift)
> 06151 83-5940 (Tel.)
> 06151 83-4577 (Fax)
> Vorstand: René Obermann (Vorsitzender), Dr. Karl-Gerhard Eick 
> (stellvertretender Vorsitzender), Hamid Akhavan, Timotheus 
> Höttges, L othar Pauly, Thomas Sattelberger
> Handelsregister: Amtsgericht Bonn HRB 6794, Sitz der 
> Gesellschaft: Bonn
> Supervisory Board: Dr. Klaus Zumwinkel (Chairman) Board of 
> Management: René Obermann (Chairman), Dr. Karl-Gerhard Eick 
> (Deputy Chairman), Hamid Akhavan, Timotheus Höttges, Lothar 
> Pauly,  Thomas Sattelberger Commercial register: Amtsgericht 
> Bonn HRB 6794, corporate seat: Bonn
> WEEEreg.no: DE50478376
> 
> 
> > anonymous request. However, P-A-ID doesn't reflect what the user 
> > wants, which is strictly in the From. Consequently, PAID is really 
> > irrelevant here. So, this condition was removed.
> > 
> > -Jonathan R.
> > -- 
> > 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
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip