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."