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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Fri, 07 September 2018 11:37 UTC

Return-Path: <Peter.Dawes@vodafone.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 91596128B14; Fri, 7 Sep 2018 04:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 juIcQPlbC2vi; Fri, 7 Sep 2018 04:37:26 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404D9124D68; Fri, 7 Sep 2018 04:37:24 -0700 (PDT)
Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-central-1.aws.symcld.net id 18/D7-31802-2F2629B5; Fri, 07 Sep 2018 11:37:22 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGe2e6DA0106JyJGK06os4pdWgNdG obxjBJT4JJjqVsW0sA3ZaqL6IGkyoK7UIFhE0hBTUIJqoKIlajUZE3EWRsElE6i4YK4ux01tE Xybf+f//3nPuzR2K1AzKEyjO5eDsPGvTypXS5FW2Cua7yZOp7+5WGEtbxpCxwrvGWDZaTBp7e 0OEsbLrHbFCluodaZClDvUNEKnV1b+IdWSGzMqbclxbZJbG0hEid7gLuX48L5MVoI7byI2UlI a+jKC9464UFwEEDZf6J5w6/ycFLh4jKPzcSuDCS8CZq76wExMuuhH4Gua5EUXJ6eVQ1rRJlCe H8fiLkFzMk7QbQXPfNSQacTQLxe2v5ThkgpcP3ArMC2CssDeiS+k5cOTms4iuorfA2M96Ge6V BjX3xFljqBg6HQ5+8hMiIzoRhvacJUUm6XjYO1QbyQNNQ3XTIxLzFBh4+1uG8xlw7FsbgfVZM NjzW4E5EZ5WHogcH+ibCigqr48uZuBrSUmU0yHQfVGKQ/cR3AmdinabD/tH2gnxJoDOgQ8dGV heDUWV+6KRGVB3qEeKuZWEHwe5o0jv+2duzDw0tZ0nfZHzq+H+iT4p1vXwpbWSxJwENac/RDk ZGoYeon/1KqSoQ0tMdqvZ4shmrTbGoNczBsNCJoUxpCzSsbsYk45zMls53mFnw66OzRd0ws7s rbYsHc85LqLwo8vaITt5FV13mwNoGkVop6g6vxdnaiaZcrJ2WljBstnutHFCAE2nKC2oalhPp kZt58yca5vVFn654zZQsdrJqjeirRJy2WzBasZWM1pC3en0ekjqceQ7+qXEQ2qkfA7PJcSr8s QFtLjA4uT/bjf+LzxFiQlxKiSRSDSxuZw92+r43w+ieApp41R+cZdYK+/42zUYHogID/Sy8ag 4kIOdsBIK0FTCGNqdPuPUsqLDtzZOP2ne4L0Sv7J/A2G80HtDLSflSqcxRdgUzHqWFNeS4b9w iJAsfTDqzDvgkwzn+eeWMRxX+zHfNRiqLZy9/k3z+4Iq5Zx8pn5jJ/mq4i63P/3rgDJtdUmS+ rhruM1zL7j9ifZseXCxZmaXfm1jYPP1c31aqWBhDfNIu8D+ATmw92oGBAAA
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-24.tower-245.messagelabs.com!1536320240!59561!6
X-Originating-IP: [47.73.108.157]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3863 invoked from network); 7 Sep 2018 11:37:22 -0000
Received: from vgdpm15vr.vodafone.com (HELO voxe04hw.internal.vodafone.com) (47.73.108.157) by server-24.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Sep 2018 11:37:22 -0000
Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.49) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 7 Sep 2018 13:37:20 +0200
Received: from voxe05hw.internal.vodafone.com (195.232.244.50) by VOEXH11W.internal.vodafone.com (47.73.211.209) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 7 Sep 2018 13:37:15 +0200
Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 7 Sep 2018 13:37:15 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (172.17.213.42) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 7 Sep 2018 13:37:15 +0200
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com (10.169.150.10) by AM5PR0501MB2052.eurprd05.prod.outlook.com (10.167.214.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.18; Fri, 7 Sep 2018 11:27:16 +0000
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::cd89:7dc:63de:8cc3]) by AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::cd89:7dc:63de:8cc3%6]) with mapi id 15.20.1101.020; Fri, 7 Sep 2018 11:27:16 +0000
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
CC: "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "gsalguei@cisco.com" <gsalguei@cisco.com>, "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Thread-Index: AQHUNP5IidLYCK4o10GuDQ3t7ismOqTkz44L
Date: Fri, 7 Sep 2018 11:27:16 +0000
Message-ID: <AM5PR0501MB2465A9EF8BF39486383058F797000@AM5PR0501MB2465.eurprd05.prod.outlook.com>
References: <153438197669.3049.5457797120570602903.idtracker@ietfa.amsl.com>
In-Reply-To: <153438197669.3049.5457797120570602903.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [47.73.248.182]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0501MB2052; 6:UHZDZ1Vl5hHcOAhVvUc2S08ew6VcMY3xsK/Dll+hjVWmG9nv4XkQNQ+Ji5VTBwyDbmOoLm/zlXZjsRTgrTCE03MjIEYAN/4WEaU/kn9JQ1Yb2+aSpS3kcalZuReNAhpoUP2KBYxidwtlGaMaLWvqhpg6ES2x9gA4KUrWIp053RaIM8rEi0fTkvdjik0yUwBGg3TihW07jTZHtphs0Znw9s0gEAwyhgA9zkFMolLq9fljnkjJ/eSnTA8mzZ0AOJSmmb1tKCIaiFSA/wbDdM+7ExXuPlAbWWTszB1VwPFMScaN505jERw7svGi27zIkWRcJEtCTuGLDB1msRZ2ICb4dJuOPvQSg3cVOOpoLORVgosy89XBRAhYZLD/tJyTdAyT3n+1VVkoh/DGn396taoQ6UBA9Caod0PIn/JWfKl0qwltaUF5Yf9yHYDCqfoy1RLQAt0c8dYqZVbX0zmleWfNWA==; 5:NX6aLzjky2UbiH4xm05bxbSk55ny0B3Kyo92fL8F4gQvUagqFH+lZeofoB58jxISYRWoedfMW42zmkoXxUlrpd7tohSnczQw/AvSiNe3kyD/+Yxw9v/SagjW7iYitjfcWQbhn5Kb44ZtZj1UY8vnqGfDIcdFvY8pDAO2XrsQaNk=; 7:HmqOyJzzfDeBdBn2FPzHrEpQXHfXCdrAvjJdCL2LP+crHvfBHpOKKEHofCtUxja4SpGLkGEp5N46C31NRCEcpNwrqShq5dHghLKFNTswFw5+lXz3S/t+GqC9IbsTDkdc1eGGUJ9DodCaIV4IyNk94cVyA3Aj8TdK7Dgg6+hHnaRjiGK+y5inGYugI0cHu8MBcFI3DETAQHBPlRoX2/sRoQSaq8G6IajktIpJzhX2gweoRZIIlVzMhVWL1NxcyUe1
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5f173fa4-9de3-48ba-d77e-08d614b4ddc5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2052;
x-ms-traffictypediagnostic: AM5PR0501MB2052:
x-microsoft-antispam-prvs: <AM5PR0501MB20521FC256484B5A7846902997000@AM5PR0501MB2052.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:AM5PR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2052;
x-forefront-prvs: 07880C4932
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(376002)(346002)(39860400002)(199004)(189003)(6436002)(99286004)(478600001)(53936002)(7696005)(68736007)(9686003)(229853002)(186003)(53546011)(76176011)(97736004)(102836004)(6306002)(26005)(54896002)(55016002)(72206003)(74316002)(4326008)(6506007)(1015004)(236005)(25786009)(33656002)(606006)(966005)(7736002)(6246003)(14454004)(105586002)(316002)(110136005)(54906003)(21615005)(81156014)(81166006)(86362001)(3846002)(486006)(8936002)(8676002)(106356001)(2900100001)(256004)(6116002)(11346002)(5660300001)(19627405001)(5250100002)(66066001)(446003)(2906002)(14444005)(476003)(6606003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2052; H:AM5PR0501MB2465.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: y3fLGwTS1rVWikdE1Qwn3H6AixlFwmUQwoDO8PbcJ6bgx49Vs/Ksx99+dqww4o9qt/jW25xDZI7pW8bq5Ph5t97sFBo8V1kutvXcOWZNcqPoBtuGvdn0062ehbYorVSSjKDpIEX7ngcNTDttQGJJHrzpUXlI8qmyj7uUIFxo+6qwIL4RaSPWYx7rLpQ2oMc7DLn6WWRILmb26wqGyp+OVNTcQwzwG8M+QTV0OCiP8KL1oZUs8yOY7iNStqEsp1BePS7rzDgE3wPJVdpB944yfZEdGeEp7XxnSrJWeO8fwPDdJO/TZlnf5rSBSD8gtNRL/LKBghR/sWmAOhku3OEz8lc5M58jQ3PYAhSwu0bWqcGdi6qbQGQn658fSPNospQTa093SwX7oJdmKGehWZksSA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-network-message-id: 5f173fa4-9de3-48ba-d77e-08d614b4ddc5
x-ms-exchange-crosstenant-originalarrivaltime: 07 Sep 2018 11:27:16.6278 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893
x-ms-exchange-transport-crosstenantheadersstamped: AM5PR0501MB2052
Content-Type: multipart/alternative; boundary="_000_AM5PR0501MB2465A9EF8BF39486383058F797000AM5PR0501MB2465_"
MIME-Version: 1.0
X-OriginatorOrg: vodafone.com
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/3vEad1hG2OAl4tPVEeu4pqWKOOs>
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: Fri, 07 Sep 2018 11:37:30 -0000

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
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:
----------------------------------------------------------------------

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