[Insipid] Review of draft-ietf-insipid-logme-marking-08

[Paul Giralt <[e-mail]>]

Here is my review of draft-ietf-insipid-logme-marking-08:

Section 3.6 - Does this specification require that the entire SIP message be logged? If so, it should be called out as a normative statement (SIP messages MUST be logged). If not, we should be more specific and indicate that they SHOULD be logged.

Section 3.7 - "ends with the final 200 OK of dialog1” first of all doesn’t really indicate which 200 OK it is referring to (I’m assuming 200 OK in response to BYE), but there is a good chance, especially if someone is trying to diagnose a call failure, that the dialog will terminate with a reason code other than a 200 OK. I think this should read something like “ends when the last message in the dialog is sent or received.” Subsequent sentences in this section have similar wording indicating the last message in the dialog instead of a 200 OK.

While the example shown in section 3.7 is clear, I don’t think it represents a typical example of a call transfer and the more typical case highlights a potential hole in the draft - namely, what happens when the device wishing to initiate the logging is the UAS instead of the UAC? A more typical call transfer scenario would be Alice *receiving* the call from Bob and transferring to Carol (as opposed to Alice calling Bob then transferring to Carol). If, as stipulated in the draft, Alice is the one reporting issues transferring calls and therefore is where we have enabled “log me” marking, how would this work? Section 4 clearly stipulates that “log me” marking is initiated on a dialog creating side which seems to imply that devices receiving a call cannot initiate a “log me” request. This seems like a hole to me.

Of course allowing the UAS to initiate a “log me” request has implications on the UAC that supports “log me”, but did not intend to log the call when it created the dialog. If we were to allow the UAS to insert a “log me” in response to a request that did not have a “log me” parameter, it would be desirable for the UAC to also log the dialog-initiating request. This means that a device supporting this specification must maintain a copy of any dialog-initiating request at least until the point where it can determine whether or not the receiving endpoint would like to log the call or not. This could be upon receiving the first response other than a 100 Trying. Has any thought been put into this scenario?

Section 4.2 - This first part of the section is talking specifically about intermediaries being configured to handle “log me” markings on behalf of a user agent, but then the subsections (4.2.1 and 4.2.2) revolve around handling of the marking by intermediaries independent of whether or not it’s being done on behalf of a UA. I think this should just be organized better so that 4.2.1 and 4.2.2 are peers with what’s in the 4.2 section as opposed to subsections as they seem to describe entirely different things.

Section 4.2.2.2.2 - In this scenario Proxy 1 is removing the “log me” parameter so as to not impose logging on Network B, however it would still be beneficial for Network A to log all requests and responses from Proxy 1 to Proxy 2, as these messages are still being initiated / terminated in Network A. This section indicates that Proxy 1 does not log the INVITE request F2 (and subsequent messages between Proxy 1 and Proxy 2). I feel we should at the very least indicate it is permissible and perhaps even desirable to log these messages even though the “log me” indication has been removed. Instead of "Proxy 1 does not log INVITE request F2” perhaps say “Proxy 1 MAY log INVITE request F2 even though it does not contain a “log me” marking”

Section 4.2.2.2.4 - Related to the comment above, this section does not stipulate at all which messages Proxy 1 MUST / SHOULD / MAY log. Are the messages between Proxy 1 and Proxy 2 logged by Proxy 1?


Nits:

Section 3.1 - sentence "This ability requires "log me" marker to be passed through SIP intermediaries. Session-ID header defined in ([RFC7989]) was chosen to carry the "log me" marker as a "logme" parameter since the session identifier is passed through SIP B2BUAs or other intermediaries.”

I think should read:

 "This ability requires a "log me" marker to be passed through SIP intermediaries. The Session-ID header defined in ([RFC7989]) was chosen to carry the "log me" marker as a "logme" parameter since the session identifier is passed through SIP B2BUAs or other intermediaries.”

Section 3.5 -  This is a comma splice and should be separated into two sentences or use a semicolon. For example:

   An originating or terminating user agent and SIP entities on the
   signaling path can log multiple SIP dialogs simultaneously. These
   dialogs are differentiated by their test case identifier (the local
   UUID of the Session-ID header field at the originating device).

Section 4.2 - This scenario suggests the following principles
   when a SIP intermediary is configured to initiate or handle "log me"
   marking on behalf of user agent:

Should have the word ‘a’ added before ‘user agent':

This scenario suggests the following principles
   when a SIP intermediary is configured to initiate or handle "log me"
   marking on behalf of a user agent: