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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Thu, 16 August 2018 12:31 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 DC212130E8B; Thu, 16 Aug 2018 05:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 SARak4d3LolR; Thu, 16 Aug 2018 05:31:30 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.2]) (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 F0A5A130E6C; Thu, 16 Aug 2018 05:31:29 -0700 (PDT)
Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id 51/CE-10350-F9E657B5; Thu, 16 Aug 2018 12:31:27 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURT1zUzbkTD6LBiuVVyaKGqcQtFINXE h/mCiuCV+ANEOOtLRtmCnxLrEgAlxwRXaRqqAS/kAaoioURHiFjXiguKCQY0CBRU1iltcQJ3p VNT3de459553cnNpUntfraN5l5N32DmrXh1Bxc+1lrLl9tz0hII3o031fUc0pvznXo3pfPNBZ Cp1p5r29+4jTe3tXwlT+bMuYrYmxf3juCrF7/9GpPjOBqmFZJpKsGdmu8wqy85zd9Q5gTLkOl H6mspD/oNoB4qgtfg0gkf+XxqluIzgdtUBql/x7KkIt91FcGP7a7VSeAjoPfZApRQdCB6XvJU UmlbjWbC/PkPmo3EBgs63h0i5IHEngr6eF9IvA+kobIHDgXwk42gswN6S9jBOBHdlg1rGFB4L L54+JGTMYDN03TsTwlo8H8qCRSoZD8SpUBxoDfEIx8Kn/GpSxiSOgdZgeYgHjMFf30QqeCi86 vgZSs3gdgpaG2+SynAaFPe0hAdGwYdrTWoFx0JzeWFoAYAvaKD4aFClCCy893jCrvOhouc8oT RdR1B864pGESbBzmp32DUbvjR1hAfS4VNlX5gfCVW72qi9KNH3T3KftEoST4CauniFHgPuwja NL7SMIXC9JEgdQlQVSsp0CFkWp40TrKwxIYE1GhNZ47Qp7NQkA7eB5Qx8LruOF52s0cCtEw3i etsK60qDnXfWIum2BkjvDLr6ZcUlNIwm9EOZ+I1iunZQZvbK9RZOtCx35Fp58RIaQdN6YJB0g 9ohDj6Ld60SrNKB/pGBjtRHM+NkmRFzOJsoZClSI5pM977zFJH0k0JvEaml7Nl2XhfDEHIrll stufZ+oz/H3oxidVEMkqJpI3N4h01w/q93oxga6aOYrTbJJVKwO/v/65aiEFIULw5FcXJ/JV0 eGu6Nq900Le7bkbwWc1vGZ1/fM/fiwQlJn+v2fR+/4Ocac2OvGGGbnXTlV8OM3WsDBY2rb23p 6kzb1rkkg6rUUY83t1BnUdzLZebkmrrkhQM6Gi5W5o+qcp2ck/J0add718aZgbW1JRbPKUPZ6 Hne0kWJ0Jys7b77yGmYwX4Uptd0j9RTooUzTiQdIvcbV0WlzecDAAA=
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-22.tower-267.messagelabs.com!1534422685!6627676!7
X-Originating-IP: [47.73.108.157]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9137 invoked from network); 16 Aug 2018 12:31:27 -0000
Received: from vgdpm15vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.157) by server-22.tower-267.messagelabs.com with AES256-SHA256 encrypted SMTP; 16 Aug 2018 12:31:27 -0000
Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 14:31:25 +0200
Received: from voxe06hw.internal.vodafone.com (195.232.244.51) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 14:31:24 +0200
Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 14:31:24 +0200
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (172.17.213.41) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Aug 2018 14:31:23 +0200
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com (10.169.150.10) by AM5PR0501MB2418.eurprd05.prod.outlook.com (10.169.149.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.18; Thu, 16 Aug 2018 12:31:22 +0000
Received: from AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::a17b:3f43:e94f:42ee]) by AM5PR0501MB2465.eurprd05.prod.outlook.com ([fe80::a17b:3f43:e94f:42ee%9]) with mapi id 15.20.1038.025; Thu, 16 Aug 2018 12:31:22 +0000
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: Adam Roach <adam@nostrum.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>
Thread-Topic: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)
Thread-Index: AQHUNPbM8RYnSHk+00CLTKSPtgoZ2qTCSrqg
Date: Thu, 16 Aug 2018 12:31:22 +0000
Message-ID: <AM5PR0501MB24659A3566177F30C6B48623973E0@AM5PR0501MB2465.eurprd05.prod.outlook.com>
References: <153437875319.3073.15951759162383331116.idtracker@ietfa.amsl.com>
In-Reply-To: <153437875319.3073.15951759162383331116.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Enabled=True; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Owner=peter.dawes@vodafone.com; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_SetDate=2018-08-16T12:11:59.6901715Z; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Name=Unclassified; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Application=Microsoft Azure Information Protection; MSIP_Label_17da11e7-ad83-4459-98c6-12a88e2eac78_Extended_MSFT_Method=Manual; Sensitivity=Unclassified
x-originating-ip: [51.6.33.173]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0501MB2418; 6:9S8CSgro/IP+ZKkeW3SMiYa4j02i2d26/mqQsDvu+rcWR3fvCV7lrQRTNqFax090HxXOtow2RdeOZlGtYme74+/A6c9/wrFwV7cSn1vPdVwMCYO3eCMbUJXu6cuSqwSf7bYB1GyrbH3eg/0+o3T2WVJV3EjWt1095inUk2v1iG+NCeMRnc2J8FbERCz642zgq7hNKBAX37bupCq9N9+AvRVGNNIb89+UpMe6cYO2ILZF5W5QW4ncYqOpBvv49bjGzy83cUFyOIzzCWttc9JhdnwIDog5dnFlHoXS/RuwDk4mYWNOgdk+PcWkS6IxA57GpUWZeJAn1eOhEALynKVs6fS4BgZIllXHhhKXb7AUn38EnZAt2ZxcQQZqrkINmMH5sDL14TCL2qLf6CbgiAM0vSol8OjNY+gcTM5wTnzMI7OPBvc3TlyG6Vn6avE6I/2iRW1YKhvPaCh4yiF7rbBFJA==; 5:L/w7qmGgmGZ3ex69f3ZMiO0lB9h2Sct7G47GQumqAAvDQU83LRjdyKctZ1BnXlNyMJdmli1klD3PpUecZX8oVG7ub61UdYOTFKrdDsfYud8xH/b6gns+PATe2AB2EYtpuRSlT67wcbAO1HbLuP3uuRwUWzR5ED9zG9cZAfcvqCo=; 7:1nseQ7feopXbfJolqulIw+ho998W3tGz18uUNQHpZvyun0JbZhoQE1DriiH3nbcow6GWaIzM78GTWR9FZWyaOaZBXnr6xnQIHrz4wALgwhglkXEOhbNl2SzfOrqCl6ocEHL/sVQvhaM0YbmWK8+5x0wT1GOXSdq9EH8X+8zFgDBBS7mPAv2YlJ85rHxnJucjUVQJeistloCv6+/iTuLt42ZfFM2R9iIWpRsysaii1JWDtklsYTyKzyxK3HuUFWHH
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4798d831-fcc9-408b-157c-08d603742ced
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0501MB2418;
x-ms-traffictypediagnostic: AM5PR0501MB2418:
x-microsoft-antispam-prvs: <AM5PR0501MB24184CED9EA16D5F1C58EEFE973E0@AM5PR0501MB2418.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959)(120809045254105)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699016); SRVR:AM5PR0501MB2418; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0501MB2418;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(136003)(39860400002)(396003)(199004)(13464003)(189003)(54164003)(68736007)(5250100002)(186003)(316002)(53546011)(6506007)(26005)(102836004)(476003)(97736004)(76176011)(7696005)(486006)(11346002)(446003)(256004)(14444005)(478600001)(81156014)(99286004)(229853002)(8676002)(81166006)(54906003)(110136005)(72206003)(14454004)(86362001)(966005)(8936002)(2906002)(33656002)(2900100001)(66066001)(6116002)(3846002)(7736002)(6306002)(5660300001)(55016002)(53936002)(305945005)(6246003)(9686003)(74316002)(25786009)(6436002)(105586002)(106356001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0501MB2418; 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: M5T9ea5doarsKtgei4ePqupHixI4f1SuV6ULojhFMYUMleYAdUFzByvL9Qvdwjosizo8vzEea8Dr8GsQU2SixemhiMFgSdU8XIXYQwl1d0bEMk6MGAxJKinp8XAE6OVh6FaLajSMhWgdLfkJiCkCLsZ60+7RMWB1Z2mOUa9RiOndwBSN790w1BqxDHPN7kKV8O45JYLnynm//azfcejZgb9DDtQZ4wyiH5c0YCe+sF9n21+Vnc5tMnZHKPVij+g/ana0m7h3DS5HMANDLZkaubPEWLp/pe6Ra7u1W+gUuqPombPuBh/hBfQBaOULuyr+rGVCfiDl8s6rIKa7kVZ3TG8IT6cUNVtJ/mWE2QF6xGgAwkxCwsfmKWGxIhKglGTVm1QTLtmN40h/bMKlwN0VeQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
x-ms-exchange-crosstenant-network-message-id: 4798d831-fcc9-408b-157c-08d603742ced
x-ms-exchange-crosstenant-originalarrivaltime: 16 Aug 2018 12:31:22.2937 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893
x-ms-exchange-transport-crosstenantheadersstamped: AM5PR0501MB2418
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: vodafone.com
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/evAkZnqjhI5A-SotXfDoxq3XSpY>
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 12:31:35 -0000

Hello Adam,
Thanks very much for the review, and for providing the application/vnd.tcpdump.pcap reference earlier which we will put in the next version.

We will discuss all of the review points and propose some resolutions, but a couple of  early comments:

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.


Regarding the example of call transfer in 3.7 you are quite right that configuration and behaviour need to be clarified. The signalling example was revised during development of the draft and it seems that the text wasn't fully updated regarding how "log me" marking is configured and started. As you say, marking can only begin with the dialog creating request.

Regards,
Peter (on behalf of the authors)

> -----Original Message-----
> From: insipid <insipid-bounces@ietf.org>; On Behalf Of Adam Roach
> Sent: 16 August 2018 01:19
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-insipid-logme-marking@ietf.org; insipid@ietf.org;
> gsalguei@cisco.com; insipid-chairs@ietf.org
> Subject: [Insipid] Adam Roach's No Objection on draft-ietf-insipid-logme-
> marking-12: (with COMMENT)
>
> Adam Roach 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:
> ----------------------------------------------------------------------
>
> Thanks to everyone who has contributed work towards this document. I
> have several comments of varying importance, and believe that this
> document requires significant changes before publication.
>
> ---------------------------------------------------------------------------
>
> General:
>
> All of the examples in this document use IPv4 addresses. Please use either a
> mix of IPv4 and IPv6, or IPv6 only. See https://www.iab.org/2016/11/07/iab-
> statement-on-ipv6/ for additional guidance.
>
> ---------------------------------------------------------------------------
>
> Abstract:
>
> >  SIP networks use signaling monitoring tools to diagnose user reported
>
> Nit: "...user-reported..."
>
> ---------------------------------------------------------------------------
>
> §3.2:
>
> >  "User-Agent" header value, or for a specific set of called party
>
> Nit: "...header field value..."
>
> ---------------------------------------------------------------------------
>
> §3.6:
>
> >  The entire SIP message (SIP headers and message body) SHOULD be
>
> Nit: Choose either "SIP header fields and message body" or "SIP header and
> message body". See the definitions of "Header" and "Header Field" in RFC
> 3261 at the bottom of page 21 for assistance.
>
> More substantive comment: it is probably useful to also log the request line
> (method, request-URI, and SIP version) or response line (SIP version,
> response code, and reason phrase), as applicable, in addition to the header
> and body.
>
> ---------------------------------------------------------------------------
>
> §3.7:
>
> This scenario is hard to follow. These points seem contradictory:
>
>   - "[Alice's] terminal is configured to log signaling for calls from the
>     network administrator Bob"
>
>   - Bob's terminal is presumably *not* configured to add "log me" marking,
> since
>     the document doesn't mention this, and implies that the configuration at
>     Alice's terminal is sufficient
>
>   - "Logging by Alice's terminal begins when it receives and echoes the
>     "logme" marker in INVITE F1"
>
> Why does INVITE F1 have a "logme" marker in it?
>
>   - "Logging by Bob's terminal begins when it sends INVITE F1, which
>     includes the "logme" marker"
>
> Again: why does this happen? The scenario doesn't include any special
> configuration at Bob's terminal.
>
> >  F1 - Bob's UA inserts the "logme" parameter in the Session-ID header
> > of the INVITE request that creates dialog1.
>
> Same question.
>
> Nit: "...header field..."
>
> >  F3 - Alice's UA inserts the "logme" parameter in the Session-ID
> > header of the REFER request that creates dialog2 which is related to
> > dialog1.
>
> Nit: "...header field..."
>
> ---------------------------------------------------------------------------
>
> §3.7:
>
> >                   |  REFER F3 (Target-Dialog:1)             |
> >           dialog2 |------------------->|                    |
> >                   |  202 Accepted      |                    |
> >           dialog2 |<-------------------|                    |
>
> The use of 202 in this context is deprecated. See RFC 7647 §5.
>
> ---------------------------------------------------------------------------
>
> §3.8:
>
> >  A SIP intermediary MUST copy the "log me" marker into forked requests
> > (see sections 4, 16.6 in [RFC3261]).
>
> It's generally bad form to reiterate normative protocol requirements in
> different language. Please rephrase to something along the lines of:
>
>    A SIP intermediary is required to copy the "log me" marker into forked
>    requests by the rules defined in sections 4 and 16.6 of [RFC3261].
>
> ---------------------------------------------------------------------------
>
> §4.1
>
> >  o  The mechanisms in this section limit initiation of "log me"
> >     marking only in dialog creation requests (e.g.  SIP INVITE) sent
> >     by an originating endpoint or an intermediary that marks on behalf
> >     of the originating endpoint.  The final terminating endpoint or an
> >     intermediary that marks on behalf of the terminating endpoint
> >     detects an incoming "log me" marker and takes action as defined in
> >     Section 4.2 and Section 4.3.
>
> To be clear, this implies that a terminating endpoint has no means of
> activating logging; only an originating endpoint (or an intermediary acting on
> its
> behalf) is capable of doing so. If that is the intention, it needs to be stated
> explicitly -- because that constraint is unclear enough that even this
> document appears to have gotten it wrong (see my comments on §3.7,
> above).
>
> ---------------------------------------------------------------------------
>
> §4.3:
>
> The text in here implies, but does not state, that intermediaries acting on
> behalf of endpoints generally need to understand RFC 4538 ("Target-
> Dialog"), RFC 3911 ("Join"), and RFC 3819 ("Replaces").  This needs to be
> explicitly noted, as intermediaries typically do not act on these header fields
> in any way.
>
> ---------------------------------------------------------------------------
>
> §4.5.2.5:
>
> >  In Figure 6 below Proxy 2 removes "log me" marking from all SIP
> > requests and responses entering network B and Proxy 2 does not
> > support "log me" marking.
>
> I'm on the fence about whether this is a DISCUSS. Per RFC 3261 processing
> rules, proxies simply pass through header fields, unchanged, that they do not
> understand -- so Proxy 2, if it does not support "log me" marking, will *NOT*
> remove the header field, and will *NOT* remove the "log me" marking. One
> of the only reasons that this mechanism (and the Session-ID mechanism
> itself) can even be deployed is precisely because of this proxy behavior.
>
> I'm pretty sure that this section needs to be revised to say that Proxy 2
> doesn't remove the "log me" marking because it doesn't understand it, and
> that Bob's UA doesn't reflect it because it doesn't understand it. The resulting
> call flow would look like the following (note the changes in F4, F14, and F20):
>
>        [ NETWORK A           ]          [ NETWORK B          ]
>        Alice           Proxy 1          Proxy 2            Bob
>          |                |                |                |
>          |   INVITE F1    |                |                |
>          |   (log me)     |                |                |
>          |--------------->|                |                |
>          |                |    INVITE F2   |                |
>          |                |   (log me)     |                |
>          |                |--------------->|                |
>          |                |                |                |
>          |                |                |                |
>          |     100  F3    |                |                |
>          |   (log me)     |                |                |
>          |<---------------|                |                |
>          |                |                |   INVITE F4    |
>          |                |                |    (log me)    |
>          |                |     100  F5    |--------------->|
>          |                |   (no log me)  |                |
>          |                |<---------------|                |
>          |                |                |     180 F6     |
>          |                |                |   (no log me)  |
>          |                |                |<---------------|
>          |                |    180 F7      |                |
>          |                |   (no log me)  |                |
>          |                |<---------------|                |
>          |                |                |                |
>          |                |                |                |
>          |     180 F8     |                |                |
>          |   (log me)     |                |                |
>          |<---------------|                |     200 F9     |
>          |                |                |   (no log me)  |
>          |                |    200 F10     |<---------------|
>          |                |   (no log me)  |                |
>          |     200 F11    |<---------------|                |
>          |   (log me)     |                |                |
>          |<---------------|                |                |
>          |     ACK F12    |                |                |
>          |   (log me)     |                |                |
>          |--------------->|                |                |
>          |                |    ACK F13     |                |
>          |                |   (log me)     |                |
>          |                |--------------->|     ACK F14    |
>          |                |                |    (log me)    |
>          |                |                |--------------->|
>          |                Both Way RTP Media                |
>          |<================================================>|
>          |                |                |     BYE F15    |
>          |                |                |   (no log me)  |
>          |                |    BYE F16     |<---------------|
>          |                |   (no log me)  |                |
>          |     BYE F17    |<---------------|                |
>          |   (log me)     |                |                |
>          |<---------------|                |                |
>          |     200 F18    |                |                |
>          |   (log me)     |                |                |
>          |--------------->|                |                |
>          |                |     200 F19    |                |
>          |                |   (log me)     |                |
>          |                |--------------->|     200 F20    |
>          |                |                |    (log me)    |
>          |                |                |--------------->|
>          |                |                |                |
>
> The prose description for "F2" also needs to be updated to instead talk about
> F6, F9, and F15.
>
> ---------------------------------------------------------------------------
>
> §4.6:
>
> >  Two error types are defined in Section 5, a missing marker error and
>
> Nit: "...Section 5: a missing..."
>                   ^
>
> ---------------------------------------------------------------------------
>
> §5.2:
>
> This section needs to address what is supposed to happen when "Join" (RFC
> 3911) is used to combine two dialogs, where one was started with "log me"
> marking, and the other one was not.
>
> ---------------------------------------------------------------------------
>
> §7:
>
> >  "logme"parameter for the Session-ID header field defined in Section 5
>
> Nit: insert space before "parameter"
>
> ---------------------------------------------------------------------------
>
> §8.4:
>
> This section needs to also include information about using GRUUs not based
> on AORs (see RFC 5627 §3.1.2).
>
> This section should further mention that fields beyond those cited here might
> contain information that can be traced to the user or a small set of users;
> e.g., the "user" field in the "o=" parameter of an SDP body, and the Request
> URI itself. Basically, it's going to be very difficult to ensure that the identity of
> the calling and/or called users is completely removed in all circumstances,
> and operators must not assume that messages are anonymized even when
> the techniques in this section are applied.
>
> ---------------------------------------------------------------------------
>
> §8.4.6:
>
> I share some of Benjamin's concerns, and am somewhat surprised that this
> section does not include guidance to ensure that the user is informed of
> sessions on which "log me" marking has been activated. Although we don't
> deal with UI in the IETF, it's completely fair game to require that UAs that are
> capable of indicating that logging is taking place MUST do so.
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid