Re: [sipcore] privacy handling
"Worley, Dale R (Dale)" <dworley@avaya.com> Tue, 31 August 2010 17:05 UTC
Return-Path: <dworley@avaya.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 1B4B63A69DF for <sipcore@core3.amsl.com>; Tue, 31 Aug 2010 10:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.402
X-Spam-Level:
X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, 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 bvuQfu2lGs4D for <sipcore@core3.amsl.com>; Tue, 31 Aug 2010 10:05:19 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5A9A53A6830 for <sipcore@ietf.org>; Tue, 31 Aug 2010 10:05:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,299,1280721600"; d="scan'208";a="205337964"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Aug 2010 13:05:28 -0400
X-IronPort-AV: E=Sophos;i="4.56,299,1280721600"; d="scan'208";a="504674334"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Aug 2010 13:05:27 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 31 Aug 2010 13:05:27 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, Paul Kyzivat <pkyzivat@cisco.com>
Date: Tue, 31 Aug 2010 13:05:26 -0400
Thread-Topic: [sipcore] privacy handling
Thread-Index: AQHLSS61s0pr4D4/rEKOq6hc1l3GjA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C01@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [sipcore] privacy handling
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: Tue, 31 Aug 2010 17:05:43 -0000
X-List-Received-Date: Tue, 31 Aug 2010 17:05:43 -0000
Mary Barnes writes (in the middle of a long exchange quoted below): > 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." I think the problem can be fixed by deleting the phrase "within its domain" (and also "a priori", which doesn't add anything): "..., unless the processing entity knows that it can rely on a downstream processing entity to apply the requested privacy ..." The crucial fact is "entity A knows that entity B will do it", not whether or how the two entities are related to each other. And in practice, whether or not "entity A knows ..." is clearer than whether or not "entity A is in the same trust domain as entity B", and possibly clearer than "entity A is in the same SIP domain as entity B" -- the latter two questions are fraught with definitional problems, whereas the first question is purely functional. Dale ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Wednesday, August 25, 2010 2:18 PM To: Paul Kyzivat Cc: SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis 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
- Re: [sipcore] privacy handling Worley, Dale R (Dale)
- Re: [sipcore] privacy handling Paul Kyzivat
- Re: [sipcore] privacy handling Mary Barnes
- Re: [sipcore] privacy handling Paul Kyzivat
- Re: [sipcore] privacy handling Mary Barnes
- Re: [sipcore] privacy handling Paul Kyzivat
- Re: [sipcore] privacy handling Hadriel Kaplan
- Re: [sipcore] privacy handling Paul Kyzivat
- Re: [sipcore] privacy handling Hadriel Kaplan
- Re: [sipcore] privacy handling Elwell, John
- Re: [sipcore] privacy handling Paul Kyzivat