Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Sun, 06 August 2017 18:42 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 7DF8D131ECE; Sun, 6 Aug 2017 11:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.698
X-Spam-Level:
X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=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 WnySbHSxGaGB; Sun, 6 Aug 2017 11:42:28 -0700 (PDT)
Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 0BF7C127058; Sun, 6 Aug 2017 11:42:27 -0700 (PDT)
Received: from [193.109.255.99] by server-2.bemta-6.messagelabs.com id AB/07-27137-21367895; Sun, 06 Aug 2017 18:42:26 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleJIrShJLcpLzFFi42LR98zp0RVMbo8 0WDrB2KLxwTR2i0ePfjBZzL//jMmB2WPK742sHkuW/GQKYIpizcxLyq9IYM24uuUva8FSp4qj k1+yNDC+M+hi5OIQEtjGKHFq1w12COcQo8SWI3eZIJzDjBLf5s5lhnA2M0r8uziDtYuRg4NNw F5ixp6YLkZODhEBTYmPN84xg9jMAtkSn392gNnCAi4S/058Z4Wo8ZS49uw7E4StJ/H1zG8wm0 VAReLO8wlg9bwCoRInHnwBq2cUkJX40rgaaqa4xK0n88HqJQQEJJbsOc8MYYtKvHz8jxWiRkd iwe5PbBC2tsSyha+hZgpKnJz5hAXEFhJQlfi3chHTBEaRWUjGzkLSPgtJ+ywk7QsYWVYxahSn FpWlFukameklFWWmZ5TkJmbm6BoamOnlphYXJ6an5iQmFesl5+duYgRGDgMQ7GA8syDwEKMkB 5OSKG/8irZIIb6k/JTKjMTijPii0pzU4kOMMhwcShK8pxPbI4UEi1LTUyvSMnOAMQyTluDgUR LhFU0CSvMWFyTmFmemQ6ROMepyHJrx8xuTEEtefl6qlDivEUiRAEhRRmke3AhYOrnEKCslzMs IdJQQT0FqUW5mCar8K0ZxDkYlYd59IJfwZOaVwG16BXQEE9ARbxJbQY4oSURISTUwmn2a53ZA XYzvbvNT268PzuvYbhGpuzRJSChnxbrgm+bts1S6g4zSYypSlxhZs7Dx9oubLeuo43j3bYp76 VTj+HSrOzUtG5Yydnyzdimepzeh+PpKS88wi9LSqotmS+028X2f2Fvy4sXsxkdLntz/tWzKlM IqD/3I1S9X1NrO73gUL1yQ2ByqxFKckWioxVxUnAgAM/2fgSIDAAA=
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-13.tower-48.messagelabs.com!1502044941!130242575!10
X-Originating-IP: [47.73.108.140]
X-StarScan-Received:
X-StarScan-Version: 9.4.25; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28365 invoked from network); 6 Aug 2017 18:42:25 -0000
Received: from vgdpm14vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.140) by server-13.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Aug 2017 18:42:25 -0000
Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 6 Aug 2017 20:42:23 +0200
Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH10W.internal.vodafone.com (47.73.211.214) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 6 Aug 2017 20:42:22 +0200
Received: from AVOEXC04W.internal.vodafone.com (145.230.15.142) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 6 Aug 2017 20:42:22 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.167]) by AVOEXC04W.internal.vodafone.com ([145.230.15.142]) with mapi id 14.03.0361.001; Sun, 6 Aug 2017 20:42:21 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "insipid@ietf.org" <insipid@ietf.org>
CC: "Arun Arunachalam (carunach" <carunach@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>
Thread-Topic: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
Thread-Index: AdMO40NqLP76QTneR5qXtNkpE/eQyg==
Date: Sun, 6 Aug 2017 18:42:20 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E1640610@VOEXM31W.internal.vodafone.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/6iAK8HspcC7nXNBsQEARYNoC3TA>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
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: Sun, 06 Aug 2017 18:42:31 -0000

Hello All,
Thanks again for the in-depth reviews of the log me marking draft, and for helpfully suggesting how to resolve the issues raised for nearly all comments. Below is a summary of changes in -08 (https://www.ietf.org/id/draft-ietf-insipid-logme-marking-08.txt) listed under the corresponding review. We believe that all issues raised have been covered except for one question, which is whether a "log me" marker can legitimately appear mid-dialog in third party call control. The log me-marking draft section 5.2 says that marking appearing mid-dialog is an error: 

5.2.  "Log Me" Marker Appears Mid-Dialog

   "log me" marking that begins mid-dialog is an error case and the
   terminating user agent or edge proxy MUST NOT "log me" mark responses
   to the marked request, responses to subsequent requests in the
   dialog, or in-dialog requests from the terminating side.

For a case where a B2BUA  re-directs a call attempt not to the called party but to a third party, it was questioned whether that third party might legitimately initiate "log me" marking. We considered as an example section 3.6 of RFC 3665 copied below. In this case, Alice would have to initiate logging in F4 to troubleshoot any problem reported by Bob so we believe that the answer is no and section 5.2 is still correct. Section 4 of the logme-marking draft says ""Log me" marking is initiated on a dialog creating side controlled by configuration.  The dialog terminating side detects an incoming "log me" marker and reacts accordingly." which is consistent with Alice needing to initiate marking. We are happy to further discuss if someone has a different view. 

3.6.  Session via Redirect and Proxy Servers with SDP in ACK

   Alice        Redirect Server     Proxy 3             Bob
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|                |                |
     |     302 F2     |                |                |
     |<---------------|                |                |
     |     ACK F3     |                |                |
     |--------------->|                |                |
     |     INVITE F4                   |                |
     |-------------------------------->|    INVITE F5   |
     |             100  F6             |--------------->|
     |<--------------------------------|      180 F7    |
     |             180 F8              |<---------------|
     |<--------------------------------|                |
     |                                 |     200 F9     |
     |             200 F10             |<---------------|
     |<--------------------------------|                |
     |             ACK F11             |                |
     |-------------------------------->|     ACK F12    |
     |                                 |--------------->|
     |                Both Way RTP Media                |
     |<================================================>|
     |                                 |     BYE F13    |
     |             BYE F14             |<---------------|
     |<--------------------------------|                |
     |             200 F15             |                |
     |-------------------------------->|     200 F16    |
     |                                 |--------------->|
     |                                 |                |

Summary of changes in revision -08 per review:

https://mailarchive.ietf.org/arch/msg/insipid/FnXbZzJsWaMp9xoLFigVDu23CZg 

Revised section 3.2 as suggested by the reviewer to make the role of configuration and of the start and end of a dialog on log me marking clear. Added called party number as an example of a use case for logging. 

 Section 3.4.1 mixed two points, firstly that only authorized devices are allowed to perform marking and secondly that such marking should be passed unchanged. Revised this section to separate these points. Ensuring that only authorized devices perform "log me" marking is covered by the ""Authorization"" sub-clause of the ""Security"" section and does not need to be repeated here. Adopted the suggested text except that log me marking is in the session-ID header not To and From. 

 Section 3.1 says that B2BUAs and other intermediaries MUST pass the log me marker unchanged and yet section 3.4.2 says that if no agreement exists between peer networks then the "log me" marker MUST be removed at a network boundary. Adopted the reviewer's suggested text to allow the case of removing the marker. 
					
Revised section 4.2.2.2.1 to describe more of the messages and also show log me marking in the figure itself. 

 Similarly revised sections 4.2.2.2.2 and 4.2.2.2.3 to describe more of the messages and also show log me marking in the figure itself.
					
 In section 3.5 added that the local UUID in Session-ID is the test case identifier as suggested. 
					
Made the wording and editorial changes suggested at the end of the review.

https://mailarchive.ietf.org/arch/msg/insipid/LanUOni-7-5yEyTOb0oZwdbyNxo 

Section 4.1, corrected inconsistency of using term "log me" header in one place and "log me" marker in another
					
Section 4.2, reworded the final bullet for both SIP endpoints and intermediaries to make it clear how a user agent or intermediary echoes the marker. Rewrote the third sentence (starting with 'The "log me" marker...') to explicitly state that the text deals with the case where the terminating user agent does not echo the marker. Sentence added to describe the logging behavior of the terminating SIP intermediary. 
					
Corrected the editorial errors identified.

https://mailarchive.ietf.org/arch/msg/insipid/sZzybE-cgF7McXsYEjuy0xJH9NY 

Changed occurrences of "test identifier" to "test case identifier"
					 
Figure 1 domain names changed from "foocorp.com" to ""example.com"
					 
Re-wrote the example in section 3.7 based on call transfer in RFC 5589 but not identical. Included the details of key SIP requests and responses.
					
In section 4.1, revised the list of principles so that each bullet states a single principle. Added a bullet that the terminating UA itself logs any in-dialog SIP requests that it sends if allowed by policy. Made parallel the lists of principles for user agents and for intermediaries acting on behalf of user agents.
					
In section 4.2, same as above.
					
Simplified section 4.2.1, which describes the behaviour of B2BUAs. Replaced the example with a more common example of a contact center call controller element. 
					
In section 4.2.2.2.1 Fig. 3, which shows "log me" marking not supported by the originating UA, corrected the numbering of requests and responses. Also added descriptions of other requests and responses to clarify operation, including the comment on proxies inserting "log me" marking in responses to the UA that does not support "log me" marking. Described the logging behavior of Proxy 1.
					
In section 4.2.2.2.3 inserted text for message F8. Also updated 4.2.2.2.2 to state that Proxy 1 doesn't log requests and responses of the dialog between itself and Proxy 2 and in 4.2.2.2.3. added logging behavior of Proxy 2 
					
In section 4.2.2.2.4, corrected the wording above Fig. 6 which shows "log me" marking being removed by the terminating network. It was commented that the text above Fig. 6 is in conflict with section 5.1 which says that a marker missing from a dialog subject to marking is an error. Section 5.1 has been expanded to define and illustrate error and non-error cases." Also, added labels to Fig. 6 to show log me marking. 
					
Section 5.2 says that a "log me" marker appearing mid-dialog is an error, but this was questioned e.g. in a 3PCC case - Alice calls Bob via a B2BUA, then the B2BUA reconnects Alice to Charlie. It may turn out that Charlie has logme marking enabled. So this will appear during the dialog establishment with Charlie, but it will appear to be mid-dialog to Alice. However, are these not simply separate dialogs like the 3 separate dialogs in Section 3.7? It would help to see the signalling details so that we can analyse this case. 

ABNF simplified as suggested.

Best regards,
Peter and Arun (authors)