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

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 18 Jun 2015 15:12:01 +0000

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 <[email-masked]> 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} / [email-masked]
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 18 Jun 2015 09:17:42 -0500

Thanks,

- vijay

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 19 Jun 2015 07:35:50 +0000

Hi Gonzalo, Vijay,
Thanks Vijay for your thorough review of the draft and constructive comments and questions, I will address these and the comments from other reviewers in a -03 version as Gonzalo has indicated.

Regards,
Peter

> -----Original Message-----
> From: insipid [mailto:[email-masked]] On Behalf Of Gonzalo
> Salgueiro (gsalguei)
> Sent: 18 June 2015 16:12
> To: Vijay K. Gurbani
> Cc: Keith Drage; [email-masked]; [email-masked]
> Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02
> 
> 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
> 
> 
> > 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
> > deemed to be worthy of logging.  As written above, there is conflation
> > between "SIP protocol" and "signalling"; after all, signalling *is*
> > the SIP protocol.
> >
> > 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:
> >
> > - 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.
> >
> > 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
> > --
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid