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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Thanks for the detailed review, Vijay.

Peter - Considering the nature of the comments below, a new version addressing Vijay and Christer’s review feedback would be needed before moving to WGLC.

Cheers,

Gonzalo


> On Jun 18, 2015, at 10:17 AM, Vijay K. Gurbani <[e-mail]> wrote:
> 
> 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