From nobody Tue Dec 19 04:19:09 2017 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B194C126C2F; Tue, 19 Dec 2017 04:19:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: insipid@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151368594467.7472.1303383927838425864@ietfa.amsl.com> Date: Tue, 19 Dec 2017 04:19:04 -0800 Archived-At: Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-marking-09.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 12:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID WG of the IETF. Title : Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-marking-09.txt Pages : 37 Date : 2017-12-19 Abstract: SIP networks use signaling monitoring tools to diagnose user reported problems and for regression testing if network or user agent software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents, and therefore impractical to monitor SIP signaling end-to-end. This document describes an indicator for the SIP protocol which can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in normal user agent signaling. However, such marking can be carried end-to-end including the originating and terminating SIP user agents, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-marking-09 https://datatracker.ietf.org/doc/html/draft-ietf-insipid-logme-marking-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-marking-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 19 04:24:51 2017 Return-Path: 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 34E4612DA6B for ; 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-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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TL5tYpyhnzrL for ; Tue, 19 Dec 2017 04:24:47 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (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 ; Tue, 19 Dec 2017 04:24:46 -0800 (PST) Received: from [85.158.139.163] (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: [47.73.108.140] X-StarScan-Received: 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) (47.73.108.140) 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 (47.73.211.214) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 13:24:10 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 13:24:09 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.170]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 13:24:09 +0100 From: "Dawes, Peter, Vodafone Group" To: "insipid@ietf.org" CC: "Gonzalo Salgueiro (gsalguei@cisco.com)" , "Arun Arunachalam (carunach) (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 X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BDVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 12:24:50 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BDVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, Thanks very much for the further reviews of logme-marking-08. Below is a su= mmary of the resulting changes in revision -09 (https://datatracker.ietf.or= g/doc/draft-ietf-insipid-logme-marking/ ). Two issues came up that have been commented before as part of the requireme= nts discussion. The issue of whether to log all or part of the SIP signalling was raised du= ring the requirements discussion and it was concluded to log entire message= s (see RFC 8123 REQ1 and https://mailarchive.ietf.org/arch/msg/insipid/2v2a= aCg5azNTjQ0BMzOul7VsLcc/?qid=3Dbe7294686534ae5f3cf2269d125ca15d). 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 cu= rrent understanding is that logging is on a per-dialog granularity (RFC 812= 3 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 sug= gested 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 a= n incoming request to a terminal that has reported a problem. However, if w= e follow the understanding that logging is pre-planned and under administra= tor control, it seems unnecessary to include these mid-dialog cases. For review https://mailarchive.ietf.org/arch/msg/insipid/ttrOBeflHqEdes7DCp= lmotIMtq4 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 con= ditions that cause logging clearer. Also added text to specify how re-trans= missions are handled as suggested in the review. 2) No change made because logging the entire SIP message is a requirement i= n RFC 8123 REQ1 following previous discussion of the issue in e-mail: https= ://mailarchive.ietf.org/arch/msg/insipid/2v2aaCg5azNTjQ0BMzOul7VsLcc/?qid= =3Dbe7294686534ae5f3cf2269d125ca15d 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" Mark= er Error Cases" and of 5.1.2 from "Non-Error Cases" to "Missing "Log me" Ma= rker 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 c= ases clause 5.1.2 below 4.4.2.1. which shows a SIP intermediary log me mark= ing on behalf of a non-supporting UA where it is normal for the "log me" ma= rker 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/D5hPFygvlzPQR7JR58= 2ajqwm7EA from Paul Giralt: 1) Re-worded section 3.6 Format of Logged Signaling to specify that the ent= ire message MUST be logged. 2) As suggested, re-worded the description in 3.7 Marking Related Dialogs t= o clarify that logging ends with the final request or response, which is no= t necessarily 200 OK. 3) The example of signalling in 3.7 has been revised to exactly match RFC 5= 589, which is the scenario described. The review pointed out that logging i= s not controlled by the terminal that reported the problem. Alice's termina= l has a problem with call transfer but cannot cause logging to start becaus= e it does not initiate the call that is transferred. However, troubleshooti= ng is expected to be administrator controlled so it is normal for an admini= strator 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 mi= d-dialog. The behavior suggested by the comment would seem to have a very b= ig impact because a UAC would have to log everything up to the point that i= t could determine if a dialog is being logged or not. Perhaps a half-way so= lution is to allow logging to start at any point in a dialog but then conti= nue to the dialog end, but this possibility has not been discussed by the g= roup. 4) The hierarchy of section 4.2 SIP Intermediaries Acting on Behalf of Endp= oints has been revised along the lines of the comment to make sections and = sub-sections relate more logically. 5) 4.2.2.2.2 "Log Me" marking removed by Originating Network (now 4.4.2.2.)= re-worded to say that Proxy 1 logs all signalling, including INVITE F2 and= subsequent requests and responses as suggested by comment. 6) 4.2.2.2.4 "Log Me" marking removed by Terminating Network (now split int= o 4.4.2.4, 4.4.2.5) clarified to show which messages are logged. 7) Nits all corrected as suggested. For review https://mailarchive.ietf.org/arch/msg/insipid/b5dqCNBeHnTQ94D32G= skmgX1Z3U from Paul Kyzivat 1) In 3.7 Marking Related Dialogs, re-worded the introduction to the call t= ransfer example to clarify that when a terminal is configured for logging t= hen 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 transf= er figure (Fig. 2) and made signalling example match exactly RFC 5589, whic= h is a more realistic call transfer scenario since the person who is called= (Alice) transfers the call to someone else. Also, the new example highligh= ts that troubleshooting is special behaviour that is arranged and controlle= d by the system administrator (Bob in this case). 2) It was commented that originating and terminating SIP intermediary are n= ot defined but are used normatively. Therefore, in 4.2 SIP Intermediaries A= cting on Behalf of Endpoints, re-worded to define the meaning of originatin= g 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 4.2.2.2.4. "Log Me" marking re= moved by Terminating Network from one case of the terminating network remov= ing log me marking into two cases (now 4.4.2.4, 4.4.2.5). One case showing = when Proxy 2 supports log me marking and one case where Proxy 2 does not su= pport 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 purpo= ses, 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 messa= ges to Bob." or similar has been added to clauses 4.4.2.2, 4.4.2.4, and 4.4= .2.5. 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. Revi= sed the introductory text to make it clearer what is an error case. Regards, Peter (on behalf of the co-authors) --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BDVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

Thanks very much for the further reviews of logme-ma= rking-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 a= s part of the requirements discussion.

 

The issue of whether to log all or part of the SIP s= ignalling was raised during the requirements discussion and it was conclude= d to log entire messages (see RFC 8123 REQ1 and https://mailarchive.ietf.or= g/arch/msg/insipid/2v2aaCg5azNTjQ0BMzOul7VsLcc/?qid=3Dbe7294686534ae5f3cf22= 69d125ca15d).

 

Also, it was commented that it might be useful to be= able to start logging mid-dialog. This also came up during the requirement= s discussion and the current understanding is that logging is on a per-dial= og 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 Pa= ul 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-pla= nned and under administrator control, it seems unnecessary to include these= mid-dialog cases.

 

 

For review https://mailarchive.ietf.org/arch/msg/ins= ipid/ttrOBeflHqEdes7DCplmotIMtq4 from Christer Holmberg:

1) In 3.2 Starting and Stopping Logging, revised wit= h an initial paragraph that introduces the scope of logging, restructured t= he 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 mes= sage is a requirement in RFC 8123 REQ1 following previous discussion of the= issue in e-mail: https://mailarchive.ietf.org/arch/msg/insipid/2v2aaCg5azN= TjQ0BMzOul7VsLcc/?qid=3Dbe7294686534ae5f3cf2269d125ca15d 

 

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 Case= s" 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 c= lause 5.1.2 below 4.4.2.1. which shows a SIP intermediary log me marking on= behalf of a non-supporting UA where it is normal for the “log meR= 21; 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/ins= ipid/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 Ma= rking Related Dialogs to clarify that logging ends with the final request o= r 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 poi= nted out that logging is not controlled by the terminal that reported the p= roblem. Alice’s terminal has a problem with call transfer but cannot cause logging to start because it does not i= nitiate the call that is transferred. However, troubleshooting is expected = to be administrator controlled so it is normal for an administrator to init= iate 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 com= ment would seem to have a very big impact because a UAC would have to log e= verything 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.&n= bsp; 

 

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

 

5) 4.2.2.2.2 "Log Me" marking removed by O= riginating Network (now 4.4.2.2.) re-worded to say that Proxy 1 logs all si= gnalling, including INVITE F2 and subsequent requests and responses as sugg= ested by comment.  

 

6) 4.2.2.2.4 "Log Me" marking removed by T= erminating Network (now split into 4.4.2.4, 4.4.2.5) clarified to show whic= h messages are logged.  

 

7) Nits all corrected as suggested.

 

For review https://mailarchive.ietf.org/arch/msg/ins= ipid/b5dqCNBeHnTQ94D32GskmgX1Z3U from Paul Kyzivat

 

1) In 3.7 Marking Related Dialogs, re-worded the int= roduction to the call transfer example to clarify that when a terminal is c= onfigured for logging then logging is general and not dependent on the scen= ario such as transfer.  

Also in 3.7, re-checked and corrected signalling con= tent in the call transfer figure (Fig. 2) and made signalling example match= exactly RFC 5589, which is a more realistic call transfer scenario since t= he person who is called (Alice) transfers the call to someone else. Also, the new example highlights that troublesho= oting is special behaviour that is arranged and controlled by the system ad= ministrator (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 th= e meaning of originating and terminating SIP intermediary and clarify that these entities are not identified by sig= nalling but by network deployment.

 

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

 

4) For cases where a SIP intermediary deliberately r= emoves log me marking, clarified that the SIP intermediary may nevertheless= log the signalling as it might be useful for troubleshooting. The text &qu= ot;For troubleshooting purposes, Proxy 2 MAY also log the requests and responses received from or sent to Bob eve= n though it removed "log me" marker prior to forwarding the messa= ges to Bob." or similar has been added to clauses 4.4.2.2, 4.4.2.4, an= d 4.4.2.5.

 

5) It was commented that the text in 5.1 Missing &qu= ot;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 clear= er what is an error case.

 

Regards,

Peter (on behalf of the co-authors)

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99E30565BDVOEXM31Winterna_--