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

["Jesske, R" <[e-mail]>]

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
 

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]]Im Auftrag von GARCIN Sebastien RD-CORE-ISS
Gesendet: Dienstag, 9. November 2004 10:53
An: Mary Barnes; [e-mail]
Betreff: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)


Mary,
 
Responses below marked [SG]
 
Best regards, 
sébastien 

  _____  

De : [e-mail] [mailto:[e-mail]] De la part de Mary Barnes
Envoyé : lundi 8 novembre 2004 21:57
À : Mary Barnes; GARCIN Sebastien RD-CORE-ISS; '[e-mail]'
Objet : RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)


My initial response is awaiting approval by moderator due to the size, so I've snipped and am resending.  

 
Mary 

-----Original Message-----
From: Barnes, Mary [NGC:B601:EXCH] 
Sent: Monday, November 08, 2004 1:43 PM
To: 'GARCIN Sebastien RD-CORE-ISS'; [e-mail]
Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history-info-04.txt)


Sébastien,
 
Thanks for reviewing the draft; my response to your comments is embedded below [MB].
 
Mary 


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


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.  
 
[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.
 
Thank you for clarifying this point.
 
Best regards,
sébastien
 
 

------Remainder of non-related part of this thread has been deleted by Mary------------------

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip