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

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

Hello Paul, Jörgen,
Thanks very much for the reviews which uncovered a number of areas that can be improved! I have given some responses in-line below but I didn't include the complete suggested revised text as some of it is long and might be difficult to follow outside the context of draft. If I didn't make an explicit response (e.g. on editorials) then it means I agree with the comment :-)

We would very much welcome further reviews from anyone else who has time to read through the draft, but I wanted to give some responses now because a lot of points have been raised already. 

Thanks and regards,
Peter  

> -----Original Message-----
> From: insipid [mailto:[e-mail]] On Behalf Of Jörgen Axell
> Sent: 09 June 2017 16:07
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07
> 
> Hi,
> 
> This is my review on this draft, trying to not duplicate Paul's comments:
> 
> 4.1 says "log me" header in one place, change to "log me" marker terminology
> "header" versus "header field" seems inconsistent

(Peter) Agreed, we will correct to "log me marker" and "header field" throughout. 

> 
> 4.2:
> The third sentence (starting with 'The "log me" marker...') seems a bit
> standalone. I think the text could have a condition e.g.: "If a "log me" marker is
> received by a user agent not supporting "log me" marking the user agent does
> not echo the "log me" marker in responses."

(Peter) We will re-word this sentence.

> I think the last bullet should say that the originating SIP intermediary echoes
> **received** "log me" markers in responses to in-dialog requests. As the text is
> now I get a bit uncertain if the node always puts in a "log me" marker in the
> response. If so it would be against the recommendation in 5.1.

(Peter) We will re-word this sentence.

> 
> 4.2.2.2.1 Editorial: Proxy-1-->Proxy 1
> 
> 4.2.2.2.2 first line has in In.
> Below figure 4 F6, remove "the" from "the Alice's".
> 
> Regards,
> Jörgen
> 
> -----Original Message-----
> From: insipid [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 05 June 2017 23:41
> To: [e-mail]
> Subject: Re: [Insipid] draft-ietf-insipid-logme-marking-07
> 
> I have reviewed the -07 version. This time I couldn't do it just by looking at the
> diff, so I did read it end to end. I do have a number of
> comments:
> 
> * Terminology:
> 
> Some places use "test case identifier" while others use "test identifier". Please
> pick one term and stick to it. Or perhaps the special term can be abandoned
> altogether by simply using Session-ID.

(Peter) We will use "test case identifier" throughout. 

> 
> * Section 3.1:
> 
> Example needs to use domain names taken from domains example.com or
> example.org.
> 
> * Section 3.7:
> 
> It would be helpful to include some message detail for F1, F2 and F3. It doesn't
> have to be complete, but should show the Session-ID header field.

(Peter) We will re-write the example in section 3.7 based on call transfer in RFC 5589. The revised example will include more message details to make it clearer that "log me" marking always begins with the initial SIP request from the originating user agent and also to show how the local-uuid component of the Session-ID header field value is used as the test case identifier.   

The fact "log me" marking always begins with the initial SIP request also relates to the comment below on section 5.2. 

> 
> * Section 4.1:
> 
> A couple of important things seem to have been left out of the list
> principles:
> 
> - the originating UA should itself log all the requests in the dialog.
> 
> - the terminating UA should also log in-dialog requests that it marks and sends,
> and the corresponding responses.
> 
> (This could be simplified by simply saying that both UAs should log all messages
> in the dialog.)

(Peter) We will revise the list of principles so that each bullet states a single principle and add a bullet stating that the terminating UA itself logs any in-dialog SIP requests that it sends. It will be clearer if we also make the list of principles for user agents parallel to the corresponding lis for intermediaries acting on behalf of user agents.

> 
> * Section 4.2:
> 
> Similar comment to that for 4.1.
> 
> * Section 4.2.1:
> 
> IMO what is written in this section and subsections is both incomplete and
> overly complex.
> 
> ISTM that this can be greatly simplified:
> 
> - a dialog on one "side" of the B2BUA may or may not be coupled to a related
> dialog on the other "side" for logme purposes.
> 
> - by default related dialogs on the two sides are coupled. In cases where the
> B2BUA is more complex some related dialogs might not be coupled. (You can
> say as much or as little as you want about this.)
> 
> - if a dialog on one side is logme marked then a coupled dialog on the other
> side must also be so marked. This affects all messages in both dialogs.
> 

(Peter) We will simplify section 4.2.1 based on this suggested text (thanks!) but I think it's useful to still say how they relate to the named B2BUA types in the taxonomy in RFC 7092.

> * Section 4.2.2.2.1:
> 
> The actions are labeled by message id (Fn), but those for F2 and F3 don't
> correspond to the corresponding message. Also you missed a message. I think
> you mean:
> 
>     F1 - Alice's UA does not insert a "log me" marker in the dialog-
>     creating INVITE request F1.  Nevertheless, Proxy 1 is configured to
>     detect the start of logging.  Proxy 1 logs INVITE request F1 and
>     maintains state that this dialog is being logged.
> 
>     F5 - Proxy 1 inserts a "log me" marker in INVITE request F5 before
>     forwarding it to Proxy 2.
> 
>     F16 - Proxy 1 inserts a "log me" marker in ACK request F16 before
>     forwarding it to Proxy 2).
> 
>     F22 - Proxy 1 inserts a "log me" marker in 200 response F22 before
>     forwarding it to Proxy 2.
> 

(Peter) Thanks, we will correct the numbering. Also I think it will help to add a few more requests/responses to the description (e.g. the 100 response and the in-dialog BYE sent by Bob ).

> Also, should Proxy 1 also be inserting a "log me" marker into F6, F11, F14, and
> F20? In this topology they will probably be ignored by Alice, but maybe there
> can be cases where they are not.

(Peter) I think Proxy 1 should be inserting a "log me" marker into F6. For F11, F14, and F20, Bob's UA should have echoed (responses F11, F14) or inserted (BYE request F20) the "log me" marker so we will make that clear. 

> 
> * Section 4.2.2.2.3:
> 
> You forgot to mention:
> 
>     F8 - Proxy 2 inserts a "log me" marker in the 100 response it
>     sends to Proxy 1.

(Peter) Agree.

> 
> * Section 4.2.2.2.4:
> 
> This section says:
> 
>     In Figure 6 below Proxy 2 removes "log me" marking from all SIP
>     requests and responses entering network B.  Proxy 1 therefore
>     maintains state of which dialogs are being "log me" marked in order
>     to "log me" mark all requests and responses that it receives from
>     Proxy 2.
> 
> The "therefore" in this doesn't make sense. IMO you can't expect that Proxy 1
> knows a priori that Proxy 2 will do that and hence maintain state. Rather, I
> think you need to assume that Proxy 1 maintains state in any case, and then
> uses it to mark things if it observes that they haven't been marked already. So I
> suggest:
> 
>     In Figure 6 below Proxy 2 removes "log me" marking from all SIP
>     requests and responses entering network B.  Proxy 1 maintains
>     the marking state of the dialog. When it observes that requests and
>     responses received from Proxy 2 are not marked it adds the
>     marking.
> 

(Peter) We will correct the wording. 

> However this seems to be in conflict with section 5.1. I don't know how to
> reconcile those.

(Peter) I don't think that the text is in conflict with section 5.1, but I could have misunderstood the point. Section 5.1 describes terminating proxies, i.e. Proxy 2. Proxy 2 will not see "log me" marking on e.g. 180 F9 but it will not be expecting it since it removed the marking itself. Proxy 1 is on the originating side so section 5.1 does not apply. 

> 
> * Section 5.2:
> 
> I question this. Consider 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. I think you do want to log in
> this case.
> 

I think the rule about "log me" marking that begins mid-dialog being an error is still OK but I might have mis-understood. Looking at the 3PCC example in RFC 3665 section 3.6 (below), "log me" marking must begin at INVITE F1. Bob will see INVITE F5 but this is not mid-dialog since as far as Bob is concerned INVITE F5 is the dialog-creating request. 


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    |
     |                                 |--------------->|
     |                                 |                |

   In this scenario, Alice places a call to Bob using first a Redirect
   server then a Proxy Server.  The INVITE message is first sent to the
   Redirect Server.  The Server returns a 302 Moved Temporarily response
   (F2) containing a Contact header with Bob's current SIP address.
   Alice then generates a new INVITE and sends to Bob via the Proxy
   Server and the call proceeds normally.  In this example, no SDP is
   present in the INVITE, so the SDP is carried in the ACK message.

   The call is terminated when Bob sends a BYE message.


> * Section 7:
> 
> I suggest simplifying the ABNF as follows:
> 
>          sess-id-param       =/ logme-param
> 
>          logme-param         = "logme"
> 

(Peter) The simpler the better. Does this still allow the remote parameter and the logme parameter to appear together? Does it retain the extensibility of Session-ID indicated by generic-param?

> I expect that issues may still be raised regarding security and privacy, but I'm
> not an expert on that stuff and will leave it to others.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid