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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

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 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 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) 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 into 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/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 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 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 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. Revised the introductory text to make it clearer what is an error case.

Regards,
Peter (on behalf of the co-authors)