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

"Mary Barnes" <mary.barnes@nortelnetworks.com> Wed, 17 November 2004 17:59 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 MAA25126 for <sip-web-archive@ietf.org>; Wed, 17 Nov 2004 12:59:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUU7v-0007mn-Fa for sip-web-archive@ietf.org; Wed, 17 Nov 2004 13:01:57 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTyp-0004f0-BA; Wed, 17 Nov 2004 12:52:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTxQ-0004NA-Nj for sip@megatron.ietf.org; Wed, 17 Nov 2004 12:51:04 -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 MAA24416 for <sip@ietf.org>; Wed, 17 Nov 2004 12:51:01 -0500 (EST)
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTzq-0007a0-LS for sip@ietf.org; Wed, 17 Nov 2004 12:53:37 -0500
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAHHoQ029295; Wed, 17 Nov 2004 12:50:26 -0500 (EST)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <WVC4HVDS>; Wed, 17 Nov 2004 12:50:27 -0500
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB053124BB@zrc2hxm1.corp.nortel.com>
From: Mary Barnes <mary.barnes@nortelnetworks.com>
To: 'PROUVOST Sebastien RD-CORE-ISS' <sebastien.prouvost@francetelecom.com>, 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-i nfo-04.txt)
Date: Wed, 17 Nov 2004 12:50:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc
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="===============0857168419=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6

Hi all,
 
I've again snipped the thread, but did want to propose the change that I
think will satisfy the concerns raised.
 
The change proposed is to change the last statement in the first paragraph
in section 4.3.3.1.1 from:
"...the proxy MUST remove any hi-entry(s) prior to forwarding."
to:
"...the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending
upon local policy and whether the proxy might know apriori that it can rely
on a downstream privacy service to apply the requested privacy." 
 
So, unless further concerns are raised on this proposed change, I'll plan on
incorporating that with any other last call comments in the -05 version.
 
Mary 


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
PROUVOST Sebastien RD-CORE-ISS
Sent: Thursday, November 11, 2004 8:44 AM
To: Barnes, Mary [NGC:B601:EXCH]; GARCIN Sebastien RD-CORE-ISS; Jesske, R;
sip@ietf.org
Subject: RE: [Sip] Privacy statements and
History(draft-ietf-sip-history-info-04.txt)


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 : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de Mary
Barnes
Envoyé : mercredi 10 novembre 2004 19:54
À : GARCIN Sebastien RD-CORE-ISS; Jesske, R; sip@ietf.org
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:sebastien.garcin@francetelecom.com
<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 

                                 

                                ------Remainder of 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