IETF Logo Mail Archive

Re: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 16 August 2018 15:35 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8D130EAA for <insipid@ietfa.amsl.com>; Thu, 16 Aug 2018 08:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIMD1VJ5-e6n for <insipid@ietfa.amsl.com>; Thu, 16 Aug 2018 08:35:07 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84174130E9A for <insipid@ietf.org>; Thu, 16 Aug 2018 08:35:07 -0700 (PDT)
Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7GFYqUV024199 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Aug 2018 10:35:05 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, The IESG <iesg@ietf.org>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>
Cc: "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, "gsalguei@cisco.com" <gsalguei@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>
References: <153437875319.3073.15951759162383331116.idtracker@ietfa.amsl.com> <AM5PR0501MB24659A3566177F30C6B48623973E0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <a9436eb5-8f8e-2795-0c8d-83ab3dd84b0b@nostrum.com>
Date: Thu, 16 Aug 2018 10:34:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <AM5PR0501MB24659A3566177F30C6B48623973E0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/625uN7iuGVATV75-V9M3-yF20wI>
Subject: Re: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 15:35:09 -0000

On 8/16/18 07:31, Dawes, Peter, Vodafone Group wrote:
> Regarding non-supporting networks and the example in 4.5.2.5, 3.4.3 (below) states that "log me" marking can either be dropped or passed by a non-supporting intermediary using similar language to Section 7 of RFC 7989 (End-to-End Session Identification in IP-Based Multimedia Communication Networks). Maybe we need to include both the case that it is dropped and the case that it is passed, which would operate as you describe in your review.
>
> 3.4.3.  Across a Non-Supporting SIP Intermediary
>     "Log me" marking is most effective if passed end-to-end.  However,
>     intermediaries that do not comply with this specification might pass
>     the "log me" marker unchanged or drop it entirely.

The problem here is definitional. Section 3.4.3 talks about 
intermediaries removing this marker, but that's only true if the 
intermediary in question is a B2BUA. Section 4.5.2.5 talks about 
proxies, whose behavior is governed by RFC 3261 §16.6:

>          The proxy starts with a copy of the received request.  The copy
>          MUST initially contain all of the header fields from the
>          received request.  Fields not detailed in the processing
>          described below MUST NOT be removed.

/a

v2.23.0 | Report a Bug | By Email