[Insipid] Review of draft-ietf-insipid-logme-reqs-02

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

All: I was asked by the chairs to review
draft-ietf-insipid-logme-reqs-02.  Review is below.

Generally, I believe the document needs a non-trivial amount of work to
flesh it out in a form ready for an Informational RFC.  I hope the
detailed comments below help the authors.

- Abstract, second paragraph: "This draft describes requirements for
  adding an indicator to the SIP protocol which can be used to mark
  signalling as of interest to logging."

  Here, it is the SIP message (or protocol data unit, PDU) that is
  deemed to be worthy of logging.  As written above, there is
  conflation between "SIP protocol" and "signalling"; after all,
  signalling *is* the SIP protocol.

  My suggestion would be to rewrite above sentence as:
  This draft describes requirements for adding an indicator to
  the SIP protocol data unit (PDU, or a SIP message) that marks
  the PDU as a candidate for logging.

- S1.  I think that this paragraph is important and sets the
  tone and expectation of the "log me" marker.  Thus it should be
  as clear and umabiguous as possible.  In its current text, the
  paragraph is rather rambling (sorry).  Here are the salient
  points that the paragraph is making:

  a. Service providers need to find out why users are experiencing
     signaling problems.
  b. Service providers need to run regression tests when a client
     software/hardwaare is upgraded.
  c. The diagnostics seeked by service providers may apply only to
     their network, or service providers may want an end-to-end
     diagnostic of a message, a set of messages (dialogue).
  d. The end-to-end diagnostics involve a number of caveats:
     different service providers, different countries, privacy
     expectations, trust domains, etc.

  New text should weave these points better than the current text does.

- S4: Number of questions here remain unanswered (at least to me):
   - It is not clear what is being logged.  The request line?
     All of the SIP headers, including the top line?  The body?
     A selected subset of SIP headers?  Selected subsets of the body?
     Short-form logging?  Long-form logging?
   - The diagnostic procedure calls for the entity logging the messages
     to send them to a server coordinating the diagnostics.  How is
     the URL to that server obtained?  What happens if the entity
     producing the logs is unable to reach the server?  Should
     logging continue locally?  Is the intent to reach this server in
     real-time?  What is the format by which the logging messages
     get to the server (raw, TLV, ...)?
   - How is the 'stop event' to terminate logging triggered?  Is
     the logging expiry time a parameter to the 'log me' marker?
     Is it in ms?  seconds?  hours?  number of dialogs? a specific
     dialog?
   - What is the interplay of the "log me" marker with the native
     logging support of a SIP entity?  Is it the case that the
     "log me" marker causes the SIP entity to start producing
     logs in its native format?  In SIP-CLF format?  This point is
     very important and some guidance must be provided.

- S5, REQ6 appears to exist for backwards compatibility.  If so
  just state it for context.

- S5, REQ7: It is not that the logging is stateless, it is that
  the SIP proxy is stateless (first sentence).  It may help to
  rewrite the first sentence to that effect.

- S6.1: s/the net hop/the next hop/

- S6.2.1: "The "log me" marker is not sensitive information,"
  However, in S6 above, you state that "Potential security impacts
  of a "log me" marker are whether the marker itself contains any
  sensitive information..."  So, is it sensitive or not?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq