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

[Paul Kyzivat <[e-mail]>]

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