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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 14 Jun 2017 14:18:21 -0500

Hello,

I was asked by the authors to review
draft-ietf-insipid-logme-marking-07.  My review is below.

Summary: good stuff, but some issues need to be addressed as documented
next.

MAJOR:

- S3.2: So, it appears from the last sentence that "log me" is scoped by
  the dialogue.  If through some configuration, a SIP UA is configured
  to insert the "logme" parameter, then the UA will continue inserting
  the parameter for all dialogues created by the UA until configured to
  stop inserting the parameter, right?

  If so, then the scope of the "logme" parameter is driven by
  configuration more than a dialogue.  This should be made clear in the
  text, as there are many places that state that "logme" is scoped to a
  dialogue (S6.4.5, for instance).

  I believe this is an important aspect to clarify: Is the "logme"
  scoped by a dialogue or through configuration, as time limited as that
  configuration may be?  My reading of the draft suggests that the
  scoping is through configuration, and S6.4.5 appears to support this
 (in my reading, at least).

- S3.4.1: I don't see the relationship between the two sentences.
  Perhaps simpler to say:

     When a user device inserts the "log me" marker, the marker MUST be
     be passed unchanged in the To and From headers across an edge proxy
     or a B2BUA adjacent to the user device.

- S3.4.2: Isn't the second paragraph in conflict with the MUST in S3.1?
  I know what you are getting at in the second paragraph of S3.4.2 ---
  providing an escape hatch for pragmatic reasons.  However, a strict
  interpretation would require relaxing one of the MUSTs.  Perhaps best
  to say in S3.1 that:

  In S3.1,
  OLD:
  ... does not introduce any device-specific or user-specific
  information and MUST be passed unchanged through SIP B2BUAs or other
  intermediaries.

  NEW:
  ... does not introduce any device-specific or user-specific
  information and MUST be passed unchanged through SIP B2BUAs or other
  intermediaries.  (See Section 3.4.2 where this normative behaviour may
  be relaxed for intermediaries in an external network.)

- S4.2.2.2.1: The F1, F2, and F3 messages do not convey much and just
  cause confusion.  My advice would be to remove F1, F2 and F3 and
  renumber F4 as F1.  Your interest is in showing Proxy-1 inserting
  "logme" on behalf of Alice, as such showing a INV/407/ACK transaction
  before the actual proxied INVITE does not convey any additional
  information besides cause confusion.

  I would also advise to physically show "logme" or its absence in the
  messages corresponding to F5.  I understand that you may not want to
  show the entire Session-ID header with the "logme" parameter, but a
  succinct indication like the one below should suffice:

  OLD:
  |                |
  |   INVITE F1    |
  |--------------->|

  NEW:
  |                |
  |   INVITE F1    |
  |   (logme)      |
  |--------------->|

  Similarly, if a UAS does not support "logme" and cannot echo it, use
something
  like:

  OLD:
  |                |
  |   180 F9       |
  |<---------------|

  NEW:
  |                |
  |   180 F9       |
  |   (no logme)   |
  |<---------------|

- S4.2.2.2.2: Same comment as above for F1, F2 and F3.

- S4.2.2.2.3: Same comment as above for F1, F2 and F3.

MINOR:

- S3.5: s/test identifier./test identifier (the local UUID of Session-ID
        header at the originating device)./

Nits:

- Abstract: s/as of interest/as being of interest/
- Abstract: s/regular user agent/normal user agent/
- S1, paragraph 1: s/upgraded regression/upgraded, regression/
- S3.1, paragraph 1: s/for a/in a/
- S3.2, paragraph 1: s/are "log me"/are similarly "log me"/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: [email-masked] / [email-masked]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jun 2017 17:17:11 -0400

>   (in my reading, at least).

I'm not an author, so this can be a test of how clear they have been.

IIUC, a given logme "session" is dialog scoped. (Though not exactly, 
since in the presence of B2BUAs it becomes a set of related dialogs.) 
This is identified by the SessionID. Those entities that did not 
initiate the logging need to keep state for that duration. And of course 
this then is tied to the resulting logs.

Some entities may also have some other state that causes them to 
initiate logging "sessions". The duration of that state is undefined.

Now the authors can say if I got it right.

	Thanks,
	Paul

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 15 Jun 2017 10:30:09 +0000

Hello Vijay, Paul,
Paul's summary is correct and the review comment from Vijay indicates that section 3.2 needs to be clearer on configuration vs. per-dialog scope of "log me" marking.

An example of configuration is that a service provider might have a test terminal programmed to run through a set of SIP sessions (call, call re-directed at set up, call transfer) and this terminal would be configured to "log me" mark all of them. An example of per-dialog scope is a SIP terminating user agent, which needs to be aware that a dialog is being "log me" marked (i.e. it needs to be stateful) in order to mark any in-dialog requests that it sends (e.g. BYE). Such a terminating UA knows that when the dialog ends it can close its signalling log for that dialog and stop marking requests that it sends. Such a user agent does not use configuration to perform "log me" marking.

We will clarify S3.2 in the next revision. 

Regards,
Peter

> -----Original Message-----
> From: insipid [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 14 June 2017 22:17
> To: [email-masked]
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-marking-07
> 
> > Summary: good stuff, but some issues need to be addressed as
> > documented next.
> >
> > MAJOR:
> >
> IIUC, a given logme "session" is dialog scoped. (Though not exactly, since in
> the presence of B2BUAs it becomes a set of related dialogs.) This is identified
> by the SessionID. Those entities that did not initiate the logging need to keep
> state for that duration. And of course this then is tied to the resulting logs.
> 
> Some entities may also have some other state that causes them to initiate
> logging "sessions". The duration of that state is undefined.
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jun 2017 07:59:23 -0500

Paul, Peter: Thank you for the feedback.

Peter, since Paul's recollection is on the spot, it appears to be
reasonable to use his text as a starting point.  S3.2 can be clarified
by replacing the existing paragraph to something like the following
(please feel free to discard, edit, or adopt):

  A user agent or proxy adds a "log me" marker in a request or response
  for two reasons: either it is configured to do so or it has detected
  that a dialog is being "log me" marked, causing it to maintain state
  to ensure that all requests and responses in the dialog are "log me"
  marked.

  When a user agent or proxy is configured to add a "log me" marker in
  messages, the duration that the user agent or proxy will be so
  configured is out of the scope of this document.  For instance, the
  user agent client or proxy could be configured to add a "log me"
  marker for a certain number of requests, or it could be configured to
  mark messages with a temporal scope (i.e., 9:00am - 10:00am every
  day), or it could be configured to mark messages when it encounters a
  specific "User-Agent" header.

  On the other hand, when a user agent or proxy detects that a dialog-
  initiating request is being "log me" marked, the scope of such marking
  extends to the lifetime of the dialog.  In addition, as discussed in
  Section 3.7, "log me" marked dialogues that create related dialogues
  (REFER) may transfer the marking to the related dialogues.  In such
  cases, the entire "session", identified by the Session-ID header, is
  "log me" marked.

Thanks,

- vijay

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 16 Jun 2017 14:30:09 +0000

Hello Vijay,

>     or a B2BUA adjacent to the user device. 

The current S3.4.1 mixes two ideas, firstly that only authorized and authenticated user agents are allowed to mark signalling ("Edge proxy or B2BUA checks whether the user device is allowed to make/receive e.g. calls, based on authentication and on authorization.") and secondly that marking must be passed unchanged. As you say, the current draft is confusing so in the next revision we will try to better explain these two aspects.

Regards,
Peter

> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: 15 June 2017 13:59
> To: Dawes, Peter, Vodafone Group <[email-masked]>; Paul
> Kyzivat <[email-masked]>
> Cc: [email-masked]; Arun Arunachalam (carunach) ([email-masked])
> <[email-masked]>
> Peter, since Paul's recollection is on the spot, it appears to be reasonable to
> use his text as a starting point.  S3.2 can be clarified by replacing the existing
> paragraph to something like the following (please feel free to discard, edit, or
> adopt):
> 
> > Paul's summary is correct and the review comment from Vijay indicates
> that section 3.2 needs to be clearer on configuration vs. per-dialog scope of
> "log me" marking.
> >
> > An example of configuration is that a service provider might have a test
> terminal programmed to run through a set of SIP sessions (call, call re-
> directed at set up, call transfer) and this terminal would be configured to "log
> me" mark all of them. An example of per-dialog scope is a SIP terminating
> user agent, which needs to be aware that a dialog is being "log me" marked
> (i.e. it needs to be stateful) in order to mark any in-dialog requests that it
> sends (e.g. BYE). Such a terminating UA knows that when the dialog ends it
> can close its signalling log for that dialog and stop marking requests that it
> sends. Such a user agent does not use configuration to perform "log me"
> marking.
> >
> >> initiate the logging need to keep state for that duration. And of course this
> then is tied to the resulting logs.
> >>