Re: [Insipid] Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
"Arun Arunachalam (carunach)" <carunach@cisco.com> Tue, 14 August 2018 14:52 UTC
Return-Path: <carunach@cisco.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 1972D130DD4; Tue, 14 Aug 2018 07:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 57Oo1yNCDDuO; Tue, 14 Aug 2018 07:51:58 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEC0127332; Tue, 14 Aug 2018 07:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24548; q=dns/txt; s=iport; t=1534258318; x=1535467918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pCn41C5HIWuSAUMuOdNpkRcDfBfHG2TncxuZNkYtfn4=; b=kqqAlLw2xyF+hP5Jb2fgwJso0YO9mMjsIohcW3ghZ/pD/H7ZMQakIAj/ feb+gjBdiZOXNSmlTGIQc0CzpwZToBSxYkHUgSbrcIpyWQVOUNYocSyuc +4s07fzUWWH6QJ+ngfIqEks2efdBR73i2SdwTVbl4EY6vanhOhKch2S3n o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BJAgAF7HJb/4cNJK1cGgEBAQEBAgEBAQEIAQEBAYMgBSpjfygKg2OURYFokQmFKRSBZgsjhEkCF4MAITUXAQIBAQIBAQJtHAyFOAYjVhACAQg/AwICAjAUBgsCBA4FG4MHAYEdZA+uMoEuilEFiRQXggCBEicME4JMgUGBWgIBAgGBKgELBwEHgxkxgiQCiASEbYVHiC8JAoYignGGQ4FOhCuIRIIGiH+HbQIRFIEkHgE2YVgRCHAVZQGCPoIgBQwLEWkBCIdWhT5vAYl4DxeBCIEbAQE
X-IronPort-AV: E=Sophos;i="5.53,238,1531785600"; d="scan'208,217";a="427586119"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 14:51:52 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w7EEpqWQ027218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2018 14:51:52 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Aug 2018 09:51:51 -0500
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Tue, 14 Aug 2018 09:51:51 -0500
From: "Arun Arunachalam (carunach)" <carunach@cisco.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>, "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "Arun Arunachalam (carunach)" <carunach@cisco.com>
Thread-Topic: Mirja Kühlewind's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Thread-Index: AQHUMyIQufWiNrYZ3kGUjyjiwD4AgKS/qiyA
Date: Tue, 14 Aug 2018 14:51:51 +0000
Message-ID: <47069B3D-25CE-409F-9099-E235D656C498@cisco.com>
References: <153417744610.24989.8583018232862453031.idtracker@ietfa.amsl.com>
In-Reply-To: <153417744610.24989.8583018232862453031.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.53.7]
Content-Type: multipart/alternative; boundary="_000_47069B3D25CE409F9099E235D656C498ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/JftHe-DSpnt149Yn1p0LEu6XoMM>
Subject: Re: [Insipid] Mirja Kühlewind'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: Tue, 14 Aug 2018 14:52:01 -0000
Hi Mirja, Thanks for taking the time to review and sharing feedback! Please see inline. On Aug 13, 2018, at 12:24 PM, Mirja Kühlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote: Mirja Kühlewind has entered the following ballot position for draft-ietf-insipid-logme-marking-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of quick comments/questions: 1) How do you know that both endpoints are "log me" enabled? I guess because of the requirement that all messages of a dialog must have the marker, you cannot just add it and see if the other end is able to apply it to its responses…? It is not possible for the originating endpoint to determine whether the terminating endpoint or intermediary supports “log me” prior to setting up a dialog. If the originating endpoint sent an INVITE with logme marker and received a provisional or final response with logme marker then it can infer that one or more of the intermediaries in the call signaling path (or) the terminating endpoint supports "log me". 2) Sec 3.2: "firstly because it is configured to do so, or secondly because it has detected that a dialog is being "log me" marked, causing it to maintain state to ensure that all requests and responses in the dialog are similarly "log me" marked." I was first quite confused by this sentence because I though the second case meant that intermediates needs to ensure that all messages are marked correctly. However, I guess the second case is when the other ends is configured to do marking, one needs to reply with the marking as well. I think I was mainly confused by the word "detects". Maybe it's worth to further clarify this sentence…? We can rephrase as: A user agent or intermediary adds a "log me" marker in an unmarked request or response in two cases: firstly because it is configured to add the marking to a dialog-creating request, or secondly because it has received a dialog-creating request that is being "log me" marked, causing it to maintain state to ensure that all requests and responses in the dialog are similarly "log me" marked. 3) Section 4.6 feels a little misplace but I not sure where it belong otherwise (maybe section 3 or 5?). Or maybe move section 4.5 in an own section later in the doc…? We added "4.6 Error Handling” under Section 4 since this section talks about endpoint and intermediary behavior. Error handling needs to be implemented in SIP entities, and we could reword the beginning of 4.6. to: "The two error types that SIP entities must handle are defined in Section 5, a missing marker error and an error of "log me" marking that begins mid-dialog." Or if needed, we could move it as first part of Section 5 and rename this section as "5. Error Handling” and make “5.1 Error cases” as a sub-section. Please let us know your preference. 4) Also Section 4.6: "It MUST NOT forward the "log me" marker" Does it mean an intermediate MUST remove the marker if an error is detected? Is that safe given the proxy scenarios? If at all I would recommend to use MAY here, I guess… If the proxy is logme aware then it is expected to remove logme marker in error scenarios. It is safe to remove. The objective is to stop the propagation of incorrect marking as soon as possible. 5) Sec 8.1.: "An end user or network administrator MUST give permission for a terminal to perform "log me" marking in the context of regression testing or troubleshooting a problem. " and "The configuration of a SIP intermediary to perform "log me" marking on behalf of a terminal MUST be authorized by the network administrator." I'm actually not sure what these normative sentences mean for an implementation. Is this maybe rather "An implementation MUST provide a configuration to active logging and logging MUST be disabled by default.”? We can rephrase as: “Log me” marking MUST be disabled by default both at the endpoints and intermediaries and MUST be enabled only by authorized users. For example, an end user or network administrator must give permission for a terminal that supports “log me” marking in order to initiate marking. Similarly, a network administrator must enable a configuration at the SIP intermediary to perform "log me" marking on behalf of a terminal that doesn’t support “log me” marking. The permission MUST be limited to only specific calls of interest that are originated in a given time duration. 6) Section 8.2: "If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking is removed." Should this be normative, maybe: "If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking SHOULD be removed at the network border." Or MUST? The last sentence in section 3.4.2 says “However, since a "log me" marker may cause a SIP entity to log the SIP header and body of a request or response, if no agreement exists between peer networks then the "log me" marker MUST be removed at a network boundary.” So we can add a few words in 8.2 to say: "If SIP requests and responses are exchanged with an external network with which there is no agreement to pass "log me" marking, then the "log me" marking is removed as mandated in section 3.4.2." 7) Also a related question: Should a network perform ingress filtering/removal of "log me" markers? Yes, this scenario is discussed in Section 4.5.2.5. 8) Nit: Sec 2: I guess the following sentence was coped and pasted from RFC8123 and should be removed for this doc: "Rather than describing interoperability requirements, they are used to describe requirements to be satisfied by the "log me" marking solution.” Yes, we will remove it. Thanks! Peter & Arun
- [Insipid] Mirja Kühlewind's No Objection on draft… Mirja Kühlewind
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kühlewind
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Ben Campbell
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kuehlewind (IETF)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Arun Arunachalam (carunach)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Mirja Kuehlewind (IETF)
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Benjamin Kaduk
- Re: [Insipid] Mirja Kühlewind's No Objection on d… Dawes, Peter, Vodafone Group