Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
Paul Kyzivat <pkyzivat@cisco.com> Thu, 26 August 2010 00:45 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 CD8443A6B5E for <sipcore@core3.amsl.com>; Wed, 25 Aug 2010 17:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.502
X-Spam-Level:
X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 nJvSdbh8GOlS for <sipcore@core3.amsl.com>; Wed, 25 Aug 2010 17:45:51 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 237063A6B5C for <sipcore@ietf.org>; Wed, 25 Aug 2010 17:45:51 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACdWdUxAZnwN/2dsb2JhbACgQXGhLJtthTcEigI
X-IronPort-AV: E=Sophos;i="4.56,271,1280707200"; d="scan'208";a="151955158"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Aug 2010 00:46:23 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7Q0kNwQ003067; Thu, 26 Aug 2010 00:46:23 GMT
Message-ID: <4C75B95F.3020803@cisco.com>
Date: Wed, 25 Aug 2010 20:46:23 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <4C754893.4080202@cisco.com> <AANLkTimBgKC_eZo1FGQWk-vYOTPRzgVZ7opGTj1h_0Zo@mail.gmail.com> <AANLkTik4_bNqiTLtJYxKcqbuiD=MuXY3opuuNahgqmjL@mail.gmail.com> <4C755A96.1090400@cisco.com> <AANLkTim=1U_ahk17eMCqfe4gqu-Nd8MM4VucSkJ6mxc9@mail.gmail.com>
In-Reply-To: <AANLkTim=1U_ahk17eMCqfe4gqu-Nd8MM4VucSkJ6mxc9@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
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: Thu, 26 Aug 2010 00:45:52 -0000
Mary, I don't think that does it either. Let me try to explain another way: The privacy feature you describe extends the behavior of priv-values "session" and "header" that are specified in 3323. (And also adds a new value "history".) In 3323 there is a lot of text describing the privacy service, and what it does based on priv-values when it is processing a request or response. There is also a bunch of text discussing what the UA should do to ensure that the request or response reaches a suitable privacy service that will act according to its wishes. RFC 3325 extends this, with the introduction of trust domains. And importantly, it says (not in so many words, but effectively) that proxies on the edge of a trust domain are to act as privacy services with respect to the priv-val of "id". (It doesn't say they act as a privacy service for anything else.) 4244bis section 6.3.2 says: 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. It does *not* say what is responsible for doing that. Since this is a modification to 3323, I would presume that it is a privacy service as specified in 3323 that would be carrying this out. If so, it can only do so for the values that are present when it gets the request, and then only if its passing the request on to a node that is not in its domain. If users were to follow the guidelines of 3323, the privacy service would be the first server the request reaches after leaving the UAC, and thus would have little value. The is what led me to think you meant trust domains. Because I think the behavior you are looking for is more like what 3325 does for "id" privacy. But of course that only works in an environment that has trust domains and entities charged with carrying out some privacy service functions at the edge of the domain. But as it stands those aren't charged with implementing "session" or "header" privacy. So, I don't understand what entitiy you expect to carry out this particular new privacy service act. One way or another I think this document will have to find a way to say that. Thanks, Paul Mary Barnes wrote: > Paul, > > In the context of 4244/-bis, the term domain is a DNS domain (per RFC > 3261) and not a SPEC-T Trust Domain per RFC 3325. However, the specific > terminology we are referring to is also in RFC 3261 in that a SIP entity > can be responsible for multiple domains, which is not a Trust domain, > but is something that can be configured. That's the context meant in > RFC 4244/-bis. It is outside the scope of RFC 3261 (and thus RFC > 4244/-bis) as to how those relationships are configured. It could > certainly be done using the Trust domain model, but again, that's out of > scope. > > If it helps, I can add in the terminology section that domain (and the > terminology around the domains for which an entity is responsible, etc. > ) is used in the same context as RFC 3261, but I personally don't think > that should be necessary. > > Mary. > On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat <pkyzivat@cisco.com > <mailto:pkyzivat@cisco.com>> wrote: > > > > Mary Barnes wrote: > > Actually, I did respond to that message, per the following: > http://www.ietf.org/mail-archive/web/sipcore/current/msg03088.html > > (threading in the email archives is no better than my archiving > method for emails). > > > Hmm. I cannot find that one anywhere in my own archives, and I don't > recall seeing it. Don't know why. :-( > > That sentence is written within the context of core RFC 3261. > We really didn't get into the RFC 3325 trust domain concept in > RFC 4244 - in particular because RFC 3325 is informational. > However, there is an UNLESS later in that section: > > "...,unless the processing entity knows a priori that it can > rely on a downstream processing entity within its domain to > apply the requested privacy or local policy allows the forwarding." > > So, I will include that same clause in the sentence you are > concerned about. > > > That doesn't do it for me. I think one way or another you need to > address whether "domain" means "DNS domain" or "trust domain". And > if it means "trust domain" then of course we need a ref to 3325. > > You seem to mean DNS domain, but the kinds of actions you are > discussing seem more related to 3323 and 3325. ISTM that if you mean > DNS domain then you mean it based on an assumption that "DNS domain" > = "trust domain". > > Thanks, > Paul > > Thanks, > Mary. > On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes > <mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com> > <mailto:mary.ietf.barnes@gmail.com > <mailto:mary.ietf.barnes@gmail.com>>> wrote: > > Sorry, I should have replied to that thread, but I didn't think > there was a change necessary. I'll reply now. > > Mary. > > On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat > <pkyzivat@cisco.com <mailto:pkyzivat@cisco.com> > <mailto:pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>>> wrote: > > [as individual] > > There was some discussion on the -00 version back in July > that > was not, AFAICT, addressed in the -01 version. There is a > thread > emanating from mary's announcement of the -00 version. The > following is a hook into that thread: > > > http://www.ietf.org/mail-archive/web/sipcore/current/msg03056.html > > It has to do with when privacy should be applied. > > Thanks, > Paul > > > Adam Roach wrote: > > > [as chair] > > As a reminder, we're just over halfway through this WGLC, > and have not yet seen any comments. Please take some > time to > review this draft. > > /a > > On 8/16/10 4:29 PM, Adam Roach - SIPCORE Chair wrote: > > > [as chair] > > A major author of draft-ietf-sipcore-rfc4244bis-01 > believes that the document has no remaining open > issues, > and is ready for evaluation. Today, we are starting a > two-week working group last call period. This > last call > period ends on Tuesday, August 31st. > > The latest version of the document can be > retrieved here: > > > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis > > Any comments on the document should be sent to the > SIPCORE mailing list. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org <mailto:sipcore@ietf.org> > <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>> > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org <mailto:sipcore@ietf.org> > <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>> > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org <mailto:sipcore@ietf.org> > <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>> > > https://www.ietf.org/mailman/listinfo/sipcore > > > >
- [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Adam Roach - SIPCORE Chair
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-… Adam Roach
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Elwell, John
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Elwell, John
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Mary Barnes
- Re: [sipcore] H-I in 100 response (was REMINDER: … Elwell, John
- Re: [sipcore] H-I in 100 response (was REMINDER: … Paul Kyzivat
- Re: [sipcore] H-I in 100 response (was REMINDER: … DRAGE, Keith (Keith)
- Re: [sipcore] H-I in 100 response (was REMINDER: … Hadriel Kaplan
- Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipc… Paul Kyzivat
- Re: [sipcore] H-I in 100 response (was REMINDER: … Victor Pascual Avila
- [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Christer Holmberg
- [sipcore] 4244bis-05: editorial comments Hadriel Kaplan
- Re: [sipcore] 4244bis-05: editorial comments Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Christer Holmberg
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Andrew Allen
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Cullen Jennings
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Andrew Allen
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert
- Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Shida Schubert