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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Jun 2017 17:41:03 -0400

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.

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

* 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.)

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

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

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.

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

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

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

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

* Section 7:

I suggest simplifying the ABNF as follows:

         sess-id-param       =/ logme-param

         logme-param         = "logme"

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

---

From: Jörgen Axell <[email-masked]>
Date: Fri, 9 Jun 2017 15:07:13 +0000

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

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

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:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 05 June 2017 23:41
To: [email-masked]
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.

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

* Section 4.1:

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

* Section 4.2:

* Section 4.2.1:

IMO what is written in this section and subsections is both incomplete and overly complex.

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

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

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.

* Section 4.2.2.2.3:

You forgot to mention:

* Section 4.2.2.2.4:

This section says:

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:

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

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

* Section 7:

         logme-param         = "logme"

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
[email-masked]
https://www.ietf.org/mailman/listinfo/insipid

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Tue, 13 Jun 2017 11:03:07 +0000

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  

> From: insipid [mailto:[email-masked]] On Behalf Of Jörgen Axell
> Sent: 09 June 2017 16:07
> To: Paul Kyzivat; [email-masked]
> 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.

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

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

> (This could be simplified by simply saying that both UAs should log all messages

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

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

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

>     F8 - Proxy 2 inserts a "log me" marker in the 100 response it

(Peter) Agree.

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

(Peter) We will correct the wording. 

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

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

>          sess-id-param       =/ logme-param

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