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

[Jörgen Axell <[e-mail]>]

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

* 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

_______________________________________________
insipid mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/insipid