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

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

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)