Re: [Insipid] Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Alissa Cooper <alissa@cooperw.in> Mon, 10 September 2018 15:13 UTC
Return-Path: <alissa@cooperw.in>
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 DCD551277BB; Mon, 10 Sep 2018 08:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=jYsqkfRP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UP4NbPtZ
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 CISstEj1j6xQ; Mon, 10 Sep 2018 08:13:50 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9981277C8; Mon, 10 Sep 2018 08:13:50 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 70AF021AEC; Mon, 10 Sep 2018 11:13:49 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 10 Sep 2018 11:13:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=JJkWlukrMs7EdTGM4q8WmxU7BIVAqbt+uOEl7X1SO2o=; b=jYsqkfRP psOMUL5RZc+Wmz4xZFivNUm7sskh1CigHXw/ze95QGT+V/XZGR1vFOLOE8FszQdZ 98YbTFE++zKXQwpQdywHyBqgnQwcUCTgRhEh2e3XcBOMN1Ptga1NPRqMUpdBG1ME 8SMvm5RlAIZmVok0rSIn4eYhIc7rALm+pHooy5vUHEkiKqOHlaqu769fUYq4+Jnl OYVtz/++VwivKd2THGibCYMg4kpAzsPFxP2EGtbC17AAd22yhVUOD66BRcISwH5y iyTjHr81k+/aghEVkJcgCiVDek92AqUo2PuzDIQjM1YZEjTVR/7zg59/xHqpw37g 14pxrooGo3PquQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=JJkWlukrMs7EdTGM4q8WmxU7BIVAq bt+uOEl7X1SO2o=; b=UP4NbPtZOMBZdVZmaCqGlVZ0wVpAt4mvsj9qsfHlRnBnb O9eSUrGdhLNbI5WXBG3fyibwBxWmF6BkaDW6lZjxOUSFcgdjZrMYmh8uSTCCtm9s W4E5duyNBIHzS+xFBMMu4EXSS9pOsp8UQjpZIK675uMmoJu4ycDTMB8nDC9/doJE 8seyGJYmQ8VlY9xXmTWXrMCD39cJuj8A5TzdVR5e72SHXbZ3i5gpv8uSH+pMTJok Xo/zed10UKt77o+iTaj1FCZSQvAZTWygJ1MlOqx2dAXTG5X7HEfKr/tMfWsrft38 Pd0W4z0XBc0UUMjtzc67aKnT/84ZrGe98/dj0jghQ==
X-ME-Proxy: <xmx:LIqWW3Srlrjd7JwUiXMcxvY19Q1A0kcqeDtyNOpihhsn_gYdW8d9UQ> <xmx:LIqWWwn0cbujTn9annnwDLaPL4DuakhPpj8ybEPNVJ21YAPLDaWnog> <xmx:LIqWW4OWVWEDtwl6VQvt1pfPg-agrQP3iv-hA0xQBGd3R5bVX37u6g> <xmx:LIqWWw0gM9xMILiC_ffz5rR9KYACdSwYh0M51edbRQhPEh0M4Fh-6w> <xmx:LIqWW0aF6nNiltAwVQlB4f2maN44uHW_hYEzlnPFxYzlQHO1-w64xQ> <xmx:LYqWWzYbHjUUqWTQJVlg3Ui_s1SeM0g5E-nuoy1IhkzYzS2BkQbI6A>
X-ME-Sender: <xms:LIqWW_1TZdqMlWryzL7EEujKMudWQppnz6zLt3c5JVYc8a1f50SoQw>
Received: from rtp-alcoop-nitro2.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 182F910298; Mon, 10 Sep 2018 11:13:48 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <4A31E2C5-51D2-4A5F-AD19-39B034D30CA2@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F82C9876-3544-4082-8A8A-1FDF64923B13"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 10 Sep 2018 11:13:46 -0400
In-Reply-To: <AM5PR0501MB2465A9EF8BF39486383058F797000@AM5PR0501MB2465.eurprd05.prod.outlook.com>
Cc: IESG <iesg@ietf.org>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "gsalguei@cisco.com" <gsalguei@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@VODAFONE.COM>
References: <153438197669.3049.5457797120570602903.idtracker@ietfa.amsl.com> <AM5PR0501MB2465A9EF8BF39486383058F797000@AM5PR0501MB2465.eurprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/9mrXu10k69oiJR58estJVm-mH-c>
Subject: Re: [Insipid] Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 10 Sep 2018 15:13:53 -0000
Thanks! Alissa > On Sep 7, 2018, at 7:27 AM, Dawes, Peter, Vodafone Group <Peter.Dawes@VODAFONE.COM> wrote: > > Hello Alissa, > Thanks for your review comments for the draft, in-line below are our proposed resolutions. Some of the section numbers are different from version -12 because the -13 we have prepared (not yet submitted) has some restructuring. > > Best regards, > Peter and Arun > > > >S 3.7: > > "As described > > in [RFC7989] section 6, related dialogs can occur when an endpoint > > receives a 3xx message, a REFER that directs the endpoint to a > > different peer, or an INVITE request with Replaces that also > > potentially results in communicating with a new peer." > > > >To avoid help discourage overbroad logging, this would be better if > >it normatively limited the set of what may be considered "related > >dialogs" to what is listed here, rather than saying "can occur." > > > > We have described related dialogs more fully as below and state that they are limited to call control features, but we don’t think it’s possible to normatively limit the definition to a specific list of cases as many call control features are possible. > > 3.7. Marking Related Dialogs > > "Log me" marking is done per-dialog and typically begins at dialog > creation and ends when the dialog ends. However, dialogs related to > a "log me" marked dialog MAY also be "log me" marked for call control > features such as call forward, transfer, park, and join. As > described in [RFC7989] section 6, related dialogs can occur when an > endpoint receives a 3xx message, a REFER that directs the endpoint to > a different peer, or an INVITE request with Replaces that also > potentially results in communicating with a new peer, or an INVITE > with a Join header field as described in [RFC3911]. An example is > call transfer described in section 6.1 of [RFC5589] and the logged > signaling for related dialogs can be correlated using Session-ID > values as described in section 10.9 of [RFC7989]. > > >S 4.3: > >If intermediaries are going to be authorized to insert "log me" on > >behalf of UAs, was any consideration given to providing support for > >UAs to be able to insert "do not log me"? I realize this is a > >different use case -- not where the UA isn't adding new functionality > >specified in this document, but rather where it is -- but it seems > >like it might be warranted if having intermediaries insert "log me" > >is going to be a sanctioned practice. > > > >Note that there could be multiple plausible semantics of "do not log > >me" worth supporting: telling intermediaries not to turn on "log me" > >or telling the terminating user agent not to log. > > > > Network administrator authorization is needed to enable “log me”, and the default is “do not log me” even if a UA supports “log me”. We have re-worded the second paragraph of 5.2.2. to make this clear as follows: > > Another use case is a network in which some but not all endpoints > support "log me" marking that wants to avoid treating endpoints > differently by always managing "log me" marking at a SIP > intermediary. In this case, the endpoint that supports "log me" is > not configured to mark a dialog, instead the SIP intermediary is > configured to perform "log me" marking on behalf of that endpoint. > This case still requires authorization as described in Section 7.1. > This SIP intermediary MAY optionally mark a request or response > towards the endpoint, such as the 100 response F3 in Figure 3. The > endpoint will receive a "log me" marker mid-dialog and this is not > considered an error. > > > >S 4.6: > >"Any previously logged messages SHOULD be > > retained and not deleted." > > > >I think this needs to say "in accordance with the limitations set out > >in Section 8.4.5." > > We modified the second paragraph in 5.3 as follows: > > If a missing marker error is detected by a UA, SIP intermediary, or > B2BUA, it SHOULD consider this as an error condition in the "log me" > functionality. It MUST NOT mark subsequent requests and responses > and MUST stop logging messages in the same dialog. Any previously > logged messages SHOULD be retained, for the time period defined in > Section 8.5, and not deleted. > > > > > From: Alissa Cooper <alissa@cooperw.in> > Sent: 16 August 2018 02:12 > To: The IESG > Cc: draft-ietf-insipid-logme-marking@ietf.org; insipid-chairs@ietf.org; gsalguei@cisco.com; insipid@ietf.org > Subject: Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT) > > Alissa Cooper 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 <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/ <https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/> > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > S 3.7: > "As described > in [RFC7989] section 6, related dialogs can occur when an endpoint > receives a 3xx message, a REFER that directs the endpoint to a > different peer, or an INVITE request with Replaces that also > potentially results in communicating with a new peer." > > To avoid help discourage overbroad logging, this would be better if it > normatively limited the set of what may be considered "related dialogs" to what > is listed here, rather than saying "can occur." > > S 4.3: > If intermediaries are going to be authorized to insert "log me" on behalf of > UAs, was any consideration given to providing support for UAs to be able to > insert "do not log me"? I realize this is a different use case -- not where the > UA isn't adding new functionality specified in this document, but rather where > it is -- but it seems like it might be warranted if having intermediaries > insert "log me" is going to be a sanctioned practice. > > Note that there could be multiple plausible semantics of "do not log me" worth > supporting: telling intermediaries not to turn on "log me" or telling the > terminating user agent not to log. > > S 4.6: > "Any previously logged messages SHOULD be > retained and not deleted." > > I think this needs to say "in accordance with the limitations set out in > Section 8.4.5."
- [Insipid] Alissa Cooper's No Objection on draft-i… Alissa Cooper
- Re: [Insipid] Alissa Cooper's No Objection on dra… Dawes, Peter, Vodafone Group
- Re: [Insipid] Alissa Cooper's No Objection on dra… Alissa Cooper