Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Mon, 8 Nov 2004 17:11:19 +0100

Hi mary, all
 
When reading draft-ietf-sip-history-info-04.txt, I have trouble in understanding some of the statements which relate to the forwarding rules for history-entries subject to privacy. It is an important requirement that History-entrie(s) with a Privacy=history, session, or header are indeed forwarded to entities which belong to the same trust domain. The removal of specific history-entries should only occur if the peer does not belong to the trust domain.
 
In the current text (section 4.3.3.1.1) :
If a request is  being forwarded to a Request URI associated with a domain for which the proxy is not responsible and there is a Privacy header in the request with a priv-value of "session", "header" or "history", the proxy MUST remove any hi-entry(s) prior to forwarding. 
 
The current wording is misleading since it gives the impression (maybe intentionnal) that it is not possible to forward history-entries with Privacy statements to domains under the responsability of e.g. another operator belonging to the same trust domain. 
 
The concept of "trust domain" should be used when discussing the forwarding rules pertaining to information subject to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should be stated more clearly in the draft.
 
Thank you for clarifying this point.
 
Best regards,
sébastien

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Mary Barnes
Envoyé : mercredi 3 novembre 2004 17:29
À : 'Takuya Sawada'
Cc : [email-masked]'
Objet : RE: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt

Hi Takuya, 

I apologize if I missed this specific point in your previous postings. You are correct, that index of 2 should have been 1.1 and this  actually affects the whole series and also affects the examples in  4.5.1 and 4.5.2.  All the other entries are correct relative to the index of 2, it's just the 2 should have been a 1.1, unless of course that proxy had a good reason for starting at 2, which I don't explain so shouldn't use in the example.  

It looks like I introduced that error in the -01 version when I was updating the example to include the index for all entries (as the index was originally optional). I traced the change back to changes I made during the middle of the day, so I can't even blame late nite editting.   I will definitely make a note of that and update that in the -05 version, which will hopefully be the one to go to the IESG.

I'm also copying the SIP list, so that folks are aware of this as they review the document. 

Thanks for your careful review, 
Mary 

-----Original Message----- 
From: Takuya Sawada [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2004 4:29 AM 
To: Barnes, Mary [NGC:B601:EXCH] 
Subject: Re: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt 

Hi Mary, 

Each example flow in section 4.5 begins with the following messages, 

   UA1        Proxy1  Proxy2     UA2      UA3      UA4      UA5 
                
   |            |         |        |        |        |        | 
   |--INVITE -->|         |        |        |        |        | 
   |            |-INVITE->|        |        |        |        | 
                 Supported: Histinfo 
                 History-Info: <sip:[email-masked]>;index=1, 
                               <sip:[email-masked]>;index=2 

I think this should be 

   UA1        Proxy1  Proxy2     UA2      UA3      UA4      UA5 
                
   |            |         |        |        |        |        | 
   |--INVITE -->|         |        |        |        |        | 
   |            |-INVITE->|        |        |        |        | 
                 Supported: Histinfo 
                 History-Info: <sip:[email-masked]>;index=1, 
                               <sip:[email-masked]>;index=1.1 

Note that the index of the second hi-entry is 1.1. 
I made the same comment to the list before, but no response to it. 

In Appendix C, it shows, 

   UA1          Proxy        ACDGRP1 Svr   ACDGRP2 Svr UA2-ACDGRP2              
                
   |              |              |             |          | 
   |--INVITE F1-->|              |             |          | 
    Supported:Histinfo 
   |              |              |             |          | 
   |              |--INVITE F2-->|             |          | 
                    Supported:Histinfo 
                    History-Info: <sip:[email-masked]>; index=1  
                    History-Info: <sip:[email-masked]>; index=1.1 

I can not find what is the difference between the two. 
Are you saying that the former is "Retargeting within a  Proxy" and the 
latter is "Basic Forwarding"? 
Am I missing something? 

Thanks. 

Regards, 
Takuya 

> 
> 
> Hi all, 
> 
> Since this version should be ready for WGLC, a very detailed list of the 
> changes is provided in the document, annotated as to the source, so I won't 
> repeat those details here.   The majority of the changes were the issues 
> discussed at IETF-60, along with the agreements there to change the text to 
> non-normative in section 4 (Protocol structure) and to add some detail per 
> Rohan's comment on the necessary processing should TLS not be available.  In 
> addition, I received some proposed changes on a marked up hardcopy at 
> IETF-61 from Eric Burger.  
> 
> The only items not discussed at IETF-60 were 2 items that came up on the 
> list (one posted by John Elwell on August 18th on handling of privacy in 
> responses) the other on Oct. 15th around the appropriate character format 
> for the escaped headers in the URI. And, as always, there are various minor 
> editorial changes here and there while I was "in the area".  So, there 
> should be no surprises with any of the changes, although, it is possible 
> that there are still errors and nits that can be identified during WGLC.   
> 
> Thanks, 
> Mary 
> 
> 
> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> [email-masked] 
> Sent: Monday, October 25, 2004 3:07 PM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. 
> This draft is a work item of the Session Initiation Protocol Working Group 
> of the IETF. 
> 
>       Title           : An Extension to the Session Initiation Protocol 
> for Request History Information 
>       Author(s)       : M. Barnes 
>       Filename        : draft-ietf-sip-history-info-04.txt 
>       Pages           : 47 
>       Date            : 2004-10-25 
>       
> This draft defines a standard mechanism for capturing the history 
>    information associated with a SIP request.  This capability enables 
>    many enhanced services by providing the information as to how and why 
>    a call arrives at a specific application or user.  This draft defines 
>    a new optional SIP header, History-Info, for capturing the history 
>    information in requests. A new option tag, Histinfo, to be included 
>    in the Supported header, is defined to allow UAs to indicate whether 
>    the History-Info should be returned in responses to a request which 
>    has captured the history information. A new priv-value, history, is 
>    added to the Privacy header to allow for privacy handling of the 
>    History-Info header. 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-04.txt 
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the 
> message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings. 
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username 
> "anonymous" and a password of your e-mail address. After logging in, 
> type "cd internet-drafts" and then 
>       "get draft-ietf-sip-history-info-04.txt". 
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
> 
> 
> Internet-Drafts can also be obtained by e-mail. 
> 
> Send a message to: 
>       [email-masked]. 
> In the body type: 
>       "FILE /internet-drafts/draft-ietf-sip-history-info-04.txt". 
>       
> NOTE: The mail server at ietf.org can return the document in 
>       MIME-encoded form by using the "mpack" utility.  To use this 
>       feature, insert the command "ENCODING mime" before the "FILE" 
>       command.  To decode the response(s), you will need "munpack" or 
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers 
>       exhibit different behavior, especially when dealing with 
>       "multipart" MIME messages (i.e. documents which have been split 
>       up into multiple messages), so check your local documentation on 
>       how to manipulate these messages. 
>               
>               
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft. 
> 
> 
> 
> 
> 
> _______________________________________________ 
> 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 
> 

-------- 
Takuya Sawada 
KDDI Corporation (KDDI) 
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan 
Tel: +81-3-6678-2997 
Fax: +81-3-6678-0286 
[email-masked] 

_______________________________________________
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: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 10 Nov 2004 19:27:34 +0100

Mary and roland,

Actually, the statement regarding the forwarding of hi-entries beyond the domain for which the proxy is responsible should rather be a matter of local policy and thus a MAY should be used instead of SHOULD. We are potentially dealing with network boundaries where agreements for forwarding such kind information can be reached. 

Section 4.3.3.1.1
This section should be re-reworded in accordance with the statement above (I can provide some text is we can agree).

Section 4.3.3.1 is ok (apologies for not being explicit)

Best regards,
sébastien

De : Mary Barnes [mailto:[email-masked]] 
Envoyé : mercredi 10 novembre 2004 16:21
À : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; [email-masked]
Cc : [email-masked]
Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)

Roland and Sebastien,
 
I too agree with the proposal to change the strength of the referenced statement from section 4.3.3.1.1  from MUST to SHOULD. This change is consistent with the other normative statements in section 4.3.3.1.1, which are SHOULDs rather than MUSTs.   I'll make that change in the next rev unless someone raises concerns over that change. 
 
On the second concern, I'm not clear what the proposed change is for the following:
[SG] Another issue is the decision to add hi-entries in a privacy context. A proxy changing the target (i.e. the proxy is responsible of the resource reflected in the received Request-URI) of a request which contained a "privacy=history" header MAY add a history-entries provided that it knows it can rely on other entities within the trust domain to apply the requested privacy. This affect item 4 in the list on conditions of section 4.3.3 and 4.3.3.1. 
 
Item 4 in section 4.3.3 describes the general situation, thus the strength (MAY) describes the general fact that the use of privacy is optional.  The normative text provided in 4.3.3.1, provides the general model for adding hi-entries, with the privacy specific considerations for adding the entries described in 4.3.3.1.1.  I think what you're suggesting is changing the strength of the following statement in section 4.3.3.1:
" The hi-entry MUST be added following any hi-entry received in the request being forwarded."
I can see that in the context of privacy considerations, this might seem misleading.  That MUST was originally a SHOULD but was changed (as discussed on the list and at IETF-60) to MUST based on issue JRE- 4, so a simple change of MUST to MAY would not at all work.  I thought it was clear from the statement at the beginning of 4.3.3.1, that this section is describing the scenario under which the general privacy considerations had been evaluated and the intention was to add an hi-entry, thus the statements should be read in the context that the general screening indicates that an hi-entry SHOULD be added and if one is added it MUST be added following any entry that's already in the request to preserve the ordering.   If you have explicit changes to the text that you think would further clarify the functionality, we can discuss. 
 
Roland, if you have specific text on how I could incorporate a reference to RFC3323, we can consider that; fundamentally any discussion of privacy depends on RFC 3323, so it's not clear to me how you were suggesting we incorporate such a reference.  The text in this document (history-info) should accurately describe the processing impact of the new "history" priv-value. 
 
Thanks for your input,
Mary 

		-----Original Message-----
	From: Jesske, R [mailto:[email-masked]] 
	Sent: Wednesday, November 10, 2004 7:59 AM
	To: [email-masked]; Barnes, Mary [NGC:B601:EXCH]; [email-masked]
	Cc: [email-masked]
	Subject: AW: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)

	Dear Mary and Sebastien,
	here are my Comments to Sebastien's statements:
	 
	Your first proposal I can accept from my point of view.
	On you second issue my impression is that this issue must be seen with regard to RFC3323 where privacy and the trust concept is described. Perhaps a reference to this document should be included.
	On your last point, I think we can also refer to RFC 3323.
	 
	What are you thinking?
	 
	Best Regards
	 
	Roland

		 ---- Mary snipped forwarding info to keep message smaller-----------  
		
								-----Original Message-----
				From: GARCIN Sebastien RD-CORE-ISS [mailto:[email-masked]] 
				Sent: Monday, November 08, 2004 10:11 AM
				To: Barnes, Mary [NGC:B601:EXCH]; [email-masked]
				Subject: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)

				Hi mary, all

				 
				 
				[MB]: Current wording is consistent with terminology in RFC 3261 in terms of describing who is able to change the Request URI in a specific request (based on section 16.5): 
				   " A proxy MUST NOT add additional targets to the target set if the
				   Request-URI of the original request does not indicate a resource this
				   proxy is responsible for.
				
				      A proxy can only change the Request-URI of a request during
				      forwarding if it is responsible for that URI. "
				Since History-Info (and associated privacy) are only added to the request, when an entity that is allowed to change the Request-URI retargets the request, it seemed sensible to use consistent wording to explain that.   
				[/MB] 
				 [SG] I have no problem with the statements above. My concern is that if there is a hi-entry already embedded in the request with a Privacy statement, then, it should be up to local policy to decide whether or not a proxy shall pass on those hi-entries to a trusted domain. The sentence in section 4.3.3.1.1 precludes this. I would propose to lighten the strenght of the sentence as follows:
				 
				If a request is  being forwarded to a Request URI associated with a domain for which the proxy is not responsible and there is a Privacy header in the request with a priv-value of "session", "header" or "history", the proxy MAY remove any hi-entry(s) prior to forwarding. 
				 
				[SG] Another issue is the decision to add hi-entries in a privacy context. A proxy changing the target (i.e. the proxy is responsible of the resource reflected in the received Request-URI) of a request which contained a "privacy=history" header MAY add a history-entries provided that it knows it can rely on other entities within the trust domain to apply the requested privacy. This affect item 4 in the list on conditions of section 4.3.3 and 4.3.3.1. 
				 
				The concept of "trust domain" should be used when discussing the forwarding rules pertaining to information subject to privacy. Furthermore, the requirement for forwarding history-entries to trusted entities should be stated more clearly in the draft. 
								[MB]: The whole concept of what defines privacy in terms of the proxy's use of the privacy header is outside the scope of History-Info functionality and really a matter of local policy.   I think the functionality that you want is a matter of local implementation and policy in terms of operators establishing this "trust domain" model to which you refer.  History-Info defines the mechanism to ensure the privacy of the requests, but it doesn't explicitly define how the proxy knows whether it is responsible for that resource.    I don't think this is a matter of standardization.  I thought the use of the term "domain" rather than "resouce" would be helpful, but perhaps changing it to the more general "resource" would resolve this concern and/or a statement clarifying what I've just described should be added in the draft. 
				[/MB]
				[SG]   Changing the term "domain" to "resource" does not solve the problem I mentionned above. In order to reflect current operator requirements, the draft should not PRECLUDE the fowarding of existing history information towards trusted domains.

				Best regards,
				sébastien

---

From: "PROUVOST Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 11 Nov 2004 15:44:12 +0100

Mary, Sebastien, Roland, 
 
I agree that we should let the possibility for a proxy not to remove the hi-entry even if privacy is requested and even if the request is forwarded to a Request-URI associated with a domain for which the proxy is not responsible (if there is an agreement between the domains that ensures the proxy that privacy will be applied to the request). 
I suggest a text that would look like (in case privacy is requested): "the hi-entry SHOULD be removed by the proxy unless it knows that it can rely on a downstream privacy service to apply the requested privacy ".
 
Sebastien.

De : [email-masked] [mailto:[email-masked]] De la part de Mary Barnes
Envoyé : mercredi 10 novembre 2004 19:54
À : GARCIN Sebastien RD-CORE-ISS; Jesske, R; [email-masked]
Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)

I still contend that the SHOULD is sufficient.  SHOULD means that in general processing, if the hi-entry has a privacy header, then the usual processing would be that it would be removed (i.e it was added for a specific reason and in general should be used to remove the entries based on well defined criteria).  If there are reasons, such as local policy, that would allow the forwarding in specific cases, then it's okay that it is forwarded.  I think the use of MAY results in less precision and I think the value and critera for associating and removing the privacy header with the hi-entry becomes much less clear.  

I'd like to hear more opinions on this topic, prior to agreeing to making the change (from the MUST to MAY rather than MUST to SHOULD). 

Regards, 
Mary 

-----Original Message----- 
From: GARCIN Sebastien RD-CORE-ISS [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2004 12:28 PM 
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; [email-masked] 
Cc: [email-masked] 
Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) 

Mary and roland, 

Section 4.3.3.1.1 

Best regards, 
sébastien 

Roland and Sebastien, 

Thanks for your input, 
Mary 

                -----Original Message----- 
        From: Jesske, R [mailto:[email-masked]] 
        Sent: Wednesday, November 10, 2004 7:59 AM 
        To: [email-masked]; Barnes, Mary [NGC:B601:EXCH]; [email-masked] 
        Cc: [email-masked] 
        Subject: AW: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt) 

        Dear Mary and Sebastien, 

         
        What are you thinking? 
         
        Best Regards 
         
        Roland 

                 ---- Mary snipped forwarding info to keep message smaller-----------  
                
                                                                -----Original Message----- 

                                Hi mary, all 

                                

                                [/MB] 

                                [/MB] 

                                Best regards, 
                                sébastien