[Insipid] draft-ietf-insipid-logme-marking-09

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Tue, 19 December 2017 12:24 UTC

Return-Path: <Peter.Dawes@vodafone.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 34E4612DA6B for <insipid@ietfa.amsl.com>; Tue, 19 Dec 2017 04:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TL5tYpyhnzrL for <insipid@ietfa.amsl.com>; Tue, 19 Dec 2017 04:24:47 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com []) (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 847A6126C2F for <insipid@ietf.org>; Tue, 19 Dec 2017 04:24:46 -0800 (PST)
Received: from [] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-5.messagelabs.com id 8A/6A-02285-C05093A5; Tue, 19 Dec 2017 12:24:44 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRWlGSWpSXmKPExsWi75nTo8vNahl lsO6QuUXjg2nsFnOn+FnMv/+MyYHZY8rvjaweS5b8ZApgimLNzEvKr0hgzbh7fTVTwYFJjBUT bgY1MM6p62Lk4hAS2M4o8ffwAkYI5zCjxM5Px1ghnM2MEt9/HgJyODjYBOwlZuyJ6WLk5BAR0 JT4eOMcM0gNs0A3o8SXSTvYQGqEBcwkdrXlQNRYS3zY+40FwtaTOHTwA5jNIqAqcXrtWTCbVy BUYv7rjewgNqOArMSXxtXMIDazgLjErSfzmUBsCQEBiSV7zjND2KISLx//Y4WoyZN4+n4xI8Q cQYmTM5+AzRQCmv9v5SKmCYxCs5CMmoWkZRaSFoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/A yL6KUaM4tagstUjX2EAvqSgzPaMkNzEzR9fQwFQvN7W4ODE9NScxqVgvOT93EyMwmuoZGBh3M E5Y5XeIUZKDSUmU9+wUiyghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKErxfmS2jhASLUtNTK9Iyc4 BxDZOW4OBREuH9DZLmLS5IzC3OTIdInWK05Nhw8+4fJo59YPLZzNcNzEIsefl5qVLivNNAGgR AGjJK8+DGwVLPJUZZKWFeRgYGBiGegtSi3MwSVPlXjOIcjErCvMtBpvBk5pXAbX0FdBAT0EFT I8xBDipJREhJNTAqmFtcNGRPeHh4gf/XEyn2cUx/ZCJaG08Gfb1zszXPd+49vWdKIittpmzP3 RWn4prL2ft55b/G8wfmiPw7M4tz5lfWrXLrV8dmsU7/XNAtGCpqOmO1qJbmD/W+xgjx9WKhoU XxJZ942W7PmLrXp1CwsFb6RPbnYwarrs2OSd3t+/qyo/69qG9KLMUZiYZazEXFiQCarxbCOAM AAA==
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-11.tower-188.messagelabs.com!1513686281!123117583!3
X-Originating-IP: []
X-StarScan-Version: 9.4.45; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7676 invoked from network); 19 Dec 2017 12:24:43 -0000
Received: from vgdpm14vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) ( by server-11.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 19 Dec 2017 12:24:43 -0000
Received: from VOEXH10W.internal.vodafone.com ( by edge1.vodafone.com ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 13:24:10 +0100
Received: from VOEXC02W.internal.vodafone.com ( by VOEXH10W.internal.vodafone.com ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 13:24:09 +0100
Received: from VOEXM31W.internal.vodafone.com ([]) by VOEXC02W.internal.vodafone.com ([]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 13:24:09 +0100
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "insipid@ietf.org" <insipid@ietf.org>
CC: "Gonzalo Salgueiro (gsalguei@cisco.com)" <gsalguei@cisco.com>, "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>
Thread-Topic: [Insipid] draft-ietf-insipid-logme-marking-09
Thread-Index: AdN4uYt51BcfuKRtTvKtzV7Q9CEydQ==
Date: Tue, 19 Dec 2017 12:24:08 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BD@VOEXM31W.internal.vodafone.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BDVOEXM31Winterna_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/OOU2PmYBPM6TUc9W_l5i3OoNj98>
Subject: [Insipid] draft-ietf-insipid-logme-marking-09
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: Tue, 19 Dec 2017 12:24:50 -0000

Hello All,
Thanks very much for the further reviews of logme-marking-08. Below is a summary of the resulting changes in revision -09 (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ ).

Two issues came up that have been commented before as part of the requirements discussion.

The issue of whether to log all or part of the SIP signalling was raised during the requirements discussion and it was concluded to log entire messages (see RFC 8123 REQ1 and https://mailarchive.ietf.org/arch/msg/insipid/2v2aaCg5azNTjQ0BMzOul7VsLcc/?qid=be7294686534ae5f3cf2269d125ca15d).

Also, it was commented that it might be useful to be able to start logging mid-dialog. This also came up during the requirements discussion and the current understanding is that logging is on a per-dialog granularity (RFC 8123 REQ11). We could look into ways to do this, such as temporarily logging a dialog from the beginning to anticipate mid-dialog start of logging as suggested by Paul Giralt, or allowing logging to start mid-dialog but continue to the end, or a way to configure an intermediary to initiate logging of an incoming request to a terminal that has reported a problem. However, if we follow the understanding that logging is pre-planned and under administrator control, it seems unnecessary to include these mid-dialog cases.

For review https://mailarchive.ietf.org/arch/msg/insipid/ttrOBeflHqEdes7DCplmotIMtq4 from Christer Holmberg:
1) In 3.2 Starting and Stopping Logging, revised with an initial paragraph that introduces the scope of logging, restructured the text to make the conditions that cause logging clearer. Also added text to specify how re-transmissions are handled as suggested in the review.

2) No change made because logging the entire SIP message is a requirement in RFC 8123 REQ1 following previous discussion of the issue in e-mail: https://mailarchive.ietf.org/arch/msg/insipid/2v2aaCg5azNTjQ0BMzOul7VsLcc/?qid=be7294686534ae5f3cf2269d125ca15d

3) No change. Hopefully the scope of logging is now clear 3.2, i.e. logging begins with the start of a dialog and ends when the dialog ends.

4) Revised the titles of 5.1.1 from "Error Cases" to "Missing "Log me" Marker Error Cases" and of 5.1.2 from "Non-Error Cases" to "Missing "Log me" Marker Non-Error Cases" to avoid confusion about whether the whole of section 5 is about error cases.  Also, as suggested moved the re-named non-error cases clause 5.1.2 below which shows a SIP intermediary log me marking on behalf of a non-supporting UA where it is normal for the "log me" marker to be missing in signalling from the UA.

5) Added "(no values allowed)" to the IANA registration table for the logme parameter as suggested by the review.

For review https://mailarchive.ietf.org/arch/msg/insipid/D5hPFygvlzPQR7JR582ajqwm7EA from Paul Giralt:

1) Re-worded section 3.6 Format of Logged Signaling to specify that the entire message MUST be logged.

2) As suggested, re-worded the description in 3.7 Marking Related Dialogs to clarify that logging ends with the final request or response, which is not necessarily 200 OK.

3) The example of signalling in 3.7 has been revised to exactly match RFC 5589, which is the scenario described. The review pointed out that logging is not controlled by the terminal that reported the problem. Alice's terminal has a problem with call transfer but cannot cause logging to start because it does not initiate the call that is transferred. However, troubleshooting is expected to be administrator controlled so it is normal for an administrator to initiate a call to Alice that she can attempt to transfer.  Also, not a lot of thought has been put into a scenario where logging starts mid-dialog. The behavior suggested by the comment would seem to have a very big impact because a UAC would have to log everything up to the point that it could determine if a dialog is being logged or not. Perhaps a half-way solution is to allow logging to start at any point in a dialog but then continue to the dialog end, but this possibility has not been discussed by the group.

4) The hierarchy of section 4.2 SIP Intermediaries Acting on Behalf of Endpoints has been revised along the lines of the comment to make sections and sub-sections relate more logically.

5) "Log Me" marking removed by Originating Network (now re-worded to say that Proxy 1 logs all signalling, including INVITE F2 and subsequent requests and responses as suggested by comment.

6) "Log Me" marking removed by Terminating Network (now split into, clarified to show which messages are logged.

7) Nits all corrected as suggested.

For review https://mailarchive.ietf.org/arch/msg/insipid/b5dqCNBeHnTQ94D32GskmgX1Z3U from Paul Kyzivat

1) In 3.7 Marking Related Dialogs, re-worded the introduction to the call transfer example to clarify that when a terminal is configured for logging then logging is general and not dependent on the scenario such as transfer.
Also in 3.7, re-checked and corrected signalling content in the call transfer figure (Fig. 2) and made signalling example match exactly RFC 5589, which is a more realistic call transfer scenario since the person who is called (Alice) transfers the call to someone else. Also, the new example highlights that troubleshooting is special behaviour that is arranged and controlled by the system administrator (Bob in this case).

2) It was commented that originating and terminating SIP intermediary are not defined but are used normatively. Therefore, in 4.2 SIP Intermediaries Acting on Behalf of Endpoints, re-worded to define the meaning of originating and terminating SIP intermediary and clarify that these entities are not identified by signalling but by network deployment.

3) To clarify the logging behaviour of a proxy that removes log me marking from incoming requests and responses, split  "Log Me" marking removed by Terminating Network from one case of the terminating network removing log me marking into two cases (now, One case showing when Proxy 2 supports log me marking and one case where Proxy 2 does not support logme marking.

4) For cases where a SIP intermediary deliberately removes log me marking, clarified that the SIP intermediary may nevertheless log the signalling as it might be useful for troubleshooting. The text "For troubleshooting purposes, Proxy 2 MAY also log the requests and responses received from or sent to Bob even though it removed "log me" marker prior to forwarding the messages to Bob." or similar has been added to clauses,, and

5) It was commented that the text in 5.1 Missing "Log me" Marker in Dialog Being Logged was not clear on what was an error case and what was not. Revised the introductory text to make it clearer what is an error case.

Peter (on behalf of the co-authors)