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'; sip@ietf.org
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:sebastien.garcin@francetelecom.com] 
Sent: Monday, November 08, 2004 10:11 AM
To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org
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]

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]

Thank you for clarifying this point.

Best regards,
sébastien

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