Re: [sipcore] Updated 4244bis and new call flow document

Paul Kyzivat <pkyzivat@cisco.com> Fri, 23 July 2010 13:11 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC7A3A66B4 for <sipcore@core3.amsl.com>; Fri, 23 Jul 2010 06:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.553
X-Spam-Level:
X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x34jqSFBkrzz for <sipcore@core3.amsl.com>; Fri, 23 Jul 2010 06:11:39 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 616E23A657C for <sipcore@ietf.org>; Fri, 23 Jul 2010 06:11:39 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AokGAEgySUxAZnwN/2dsb2JhbACTJYxEcaYemwyFNgSIYA
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 13:11:57 +0000
Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NDBvhI004488; Fri, 23 Jul 2010 13:11:57 GMT
Message-ID: <4C49951C.8050202@cisco.com>
Date: Fri, 23 Jul 2010 09:11:56 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: R.Jesske@telekom.de
References: <AANLkTim-f7vZ1IFS3WhVS9G8Mg1dhueN8tevLb_xDRR1@mail.gmail.com> <AANLkTilRRmWt30XOp3VKn2Xtzv71-EDUfyyUSOb0J3Bk@mail.gmail.com> <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Updated 4244bis and new call flow document
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2010 13:11:40 -0000

R.Jesske@telekom.de wrote:
> Hi Mary,
> With regard to your question for comments/review, I went thought the draft.
> 
> For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt 
> 
> I have the following comments: 
> 
> 
> 6.3.2.  Privacy in the History-Info Header
> 
> ...
> If the requestor has indicated a priv-
>    value of "session" or "header" in the request, all History-Info
>    entries MUST be anonymized when the request leaves a domain for which
>    the intermediary is responsible.
> ...
> 
> In this section it is mentioned that the entries must be anonymized when leaving the domain. I thought that if a trust relationship between domains are existing and the following domain secures the "privacy" then the information could be forwarded and will then deleted by the succeeding domain before reaching the terminating user. 
> Some regulators are requesting to pass identities until the last domain where it is possible to execute the privacy regarding RFC3323. So I think this is a MAY based on domain policy. And it is a MUST when the succeeding network cannot guarantee the privacy.
> 
> Or do I misunderstand the meaning of "domain for which the intermediary is responsible"

I'm not an expert on this, but ISTM that in the case you describe the 
request is not leaving the *trust* domain.

But that does point out ambiguity in the text you quote. That kind of 
wording "domain for which the intermediary is responsible" is usually 
talking about *DNS* domains, not *trust* domains. So maybe that should say:

  ...
  If the requestor has indicated a priv-value of "session" or "header"
  in the request, all History-Info entries MUST be anonymized when the
  request leaves a *trust* domain for which the intermediary is
  responsible.
  ...

	Thanks,
	Paul