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

["Vijay K. Gurbani" <[e-mail]>]

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: [e-mail] / [e-mail]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq