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

"Mary Barnes" <mary.barnes@nortelnetworks.com> Wed, 10 November 2004 19:11 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14688 for <sip-web-archive@ietf.org>; Wed, 10 Nov 2004 14:11:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxtE-0002Hb-BC for sip-web-archive@ietf.org; Wed, 10 Nov 2004 14:12:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxp8-0001nS-WD; Wed, 10 Nov 2004 14:08:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxcP-0007Uc-Bh for sip@megatron.ietf.org; Wed, 10 Nov 2004 13:54:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12686 for <sip@ietf.org>; Wed, 10 Nov 2004 13:54:55 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxdP-0001lK-0W for sip@ietf.org; Wed, 10 Nov 2004 13:56:00 -0500
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAIsGh05155; Wed, 10 Nov 2004 13:54:16 -0500 (EST)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <WP4QX1YQ>; Wed, 10 Nov 2004 13:54:17 -0500
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB05312471@zrc2hxm1.corp.nortel.com>
From: Mary Barnes <mary.barnes@nortelnetworks.com>
To: 'GARCIN Sebastien RD-CORE-ISS' <sebastien.garcin@francetelecom.com>, "Jesske, R" <R.Jesske@t-com.net>, sip@ietf.org
Subject: RE: [Sip] Privacy statements and History (draft-ietf-sip-history- info-04.txt)
Date: Wed, 10 Nov 2004 13:53:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: a569a4168062bb63d79812a50c918a82
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1545549844=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 1069eb5b3f212f2b9b575eaf2aff5119

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:sebastien.garcin@francetelecom.com] 
Sent: Wednesday, November 10, 2004 12:28 PM
To: Barnes, Mary [NGC:B601:EXCH]; Jesske, R; sip@ietf.org
Cc: VL-T-Com-T-TE332@vli.telekom.de
Subject: RE: [Sip] Privacy statements and History
(draft-ietf-sip-history-info-04.txt)


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:mary.barnes@nortelnetworks.com] 
Envoyé : mercredi 10 novembre 2004 16:21
À : 'Jesske, R'; GARCIN Sebastien RD-CORE-ISS; sip@ietf.org
Cc : VL-T-Com-T-TE332@vli.telekom.de
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:R.Jesske@t-com.net] 
	Sent: Wednesday, November 10, 2004 7:59 AM
	To: sebastien.garcin@francetelecom.com; Barnes, Mary
[NGC:B601:EXCH]; sip@ietf.org
	Cc: VL-T-Com-T-TE332@vli.telekom.de
	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: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] 
				 [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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip