[Insipid] Review of draft-ietf-insipid-logme-marking-08

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 26 October 2017 14:03 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5853413F59D for <insipid@ietfa.amsl.com>; Thu, 26 Oct 2017 07:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ODsGHU415SE1 for <insipid@ietfa.amsl.com>; Thu, 26 Oct 2017 07:03:14 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net []) (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 A2DB61384F5 for <insipid@ietf.org>; Thu, 26 Oct 2017 07:03:13 -0700 (PDT)
X-AuditID: c1b4fb2d-bf5ff7000000268d-78-59f1eb1f641a
Received: from ESESSHC011.ericsson.se (Unknown_Domain []) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.88.09869.F1BE1F95; Thu, 26 Oct 2017 16:03:11 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([]) by ESESSHC011.ericsson.se ([]) with mapi id 14.03.0352.000; Thu, 26 Oct 2017 16:03:11 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "insipid@ietf.org" <insipid@ietf.org>
CC: "peter.dawes@vodafone.com" <peter.dawes@vodafone.com>, "carunach@cisco.com" <carunach@cisco.com>
Thread-Topic: Review of draft-ietf-insipid-logme-marking-08
Thread-Index: AQHTTmMoLUD8UkjJKE6Ou0BBAMTyUw==
Date: Thu, 26 Oct 2017 14:03:11 +0000
Message-ID: <D617B7CB.24D8A%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <43AB3166D806CE439CC5E689F6E6071E@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7sa7864+RBttnaFs0PpjGbjH//jMm i76XX5gcmD2m/N7I6rFkyU8mj74Z6xkDmKO4bFJSczLLUov07RK4Mk7OPstasEyi4ubcH8wN jHOEuxg5OSQETCRmP5zD0sXIxSEkcIRRorntFzuEs5hR4uqcrUxdjBwcbAIWEt3/tEEaRAQ0 JT7eOMcMYjMLpEm8eP2XEcQWFjCT+PhuMjtEjbXEqQ/HWSBsPYmDd9czgdgsAqoSzz5eArN5 gWruL78NVs8oICbx/dQaJoiZ4hK3nsxngjhOQGLJnvPMELaoxMvH/1hBbFGgmRtOQPRKCChK XJ2+HKpXT+LG1ClsELa1xLUL/xkhbG2JZQtfM0PsFZQ4OfMJywRG0VlI1s1C0j4LSfssJO2z kLQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYUwe3/Nbdwbj6teMhRgEORiUe3tqL HyOFWBPLiitzDzFKcDArifAGPwEK8aYkVlalFuXHF5XmpBYfYpTmYFES53XYdyFCSCA9sSQ1 OzW1ILUIJsvEwSnVwBjaf+d1zdktxZcfPAjQmHjhwIxHB9/8+sjhnssoEya2+4e/IKNmaEFW QE5D12yXbbdOXjKymbI21GDLqi2zPNe/DGvuWG4RWj7dc0PM1r073/u79x/VYu1eIZbftrWk buPycB5vE7YYGWbztQ/WlzZ/Y2rt81gntOPi9zft4lceRM3bejznfZYSS3FGoqEWc1FxIgDB OiJVpQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/ttrOBeflHqEdes7DCplmotIMtq4>
Subject: [Insipid] Review of draft-ietf-insipid-logme-marking-08
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Oct 2017 14:03:15 -0000


I have reviewed draft-ietf-insipid-logme-marking-08.txt.


In general, the draft looks good, and while my comments are mostly
editorial I think there are technical procedures that need to be clarified.

Section 3.2.:

The text is very unclear, especially regarding the scope (single request
vs dialog) of a marking.

In the beginning of the section, you should say something like:

- If the marker is included in a dialog-initiation request, the scope of
the logging applies to the lifetime of the dialog, and each request and
- If the marker is included in a mid-dialog request, or in a response to a
mid-dialog request, the scope of the logging only applies to the request
(or the response). 

In case of dialog wide logging, where the marker is included in the
initial INVITE, does one still have to include the marker in all
sub-sequent mid-dialog messages? The examples in section 4, and the text
in section 5.1 seem to imply so. If so, I think it should be explicitly

The title talks about ³stopping² logging, but there are no procedures for
doing that. When reading section 5.1., it seems like not including the
marker in a mid-dialog message, even if the marking has been negotiated
for the whole dialog, would stop the marking. However, when reading
section 5.1.1 it seems like not including the marker in a mid-dialog
message is an error. It needs to be explicitly clarified whether a
dialog-wide logging can be stopped or not, and how.

I suggest to place the 2nd paragraph at the end of the section. It is just
informative text.

Even though it may be obvious, I think it would be good to explicitly say
(e.g., in a Note) that, if the marker is included in a request or
response, it must be included in all re-transmissions of the
request/response. Similarly, if the marker is not included in a
request/response, it must not be included in re-transmissions of that

Section 3.6.:

Is it a normative requirement to log the whole SIP message (I see no MUST)?

Assuming it is a requirement to log the whole SIP message, do we really
want to mandate that? Couldn¹t it be a SHOULD, unless the operator has
configured that only specific parts are to be logged?

Section 3.7.:

The text says:

 ""Log me" marking is done per-dialog and typically begins at dialog
creation and ends when the dialog ends.²

This only applies to dialog scoped loggings. As indicated in section 3.2,
loggings can also be done per message.

Section 5.1.2.:

Section 5 is about error cases. Shouldn¹t this be in a separate section?

Section 5.2.:

See comment as 5.1.2.

In addition, I think this text belongs in section 3.2. I partly suggested
such text already, but I guess it could be more explicit.

Section 7:

In the table, in the Predefined Values column, I suggest to say "No (no
values are allowed)².