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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hello All,
As an initial follow-up to those reviewers who made suggestions on draft-ietf-insipid-logme-reqs-02 I have uploaded revision -03 (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/) with the changes summarized below. Some comments on version -02 remain to be resolved but require more than wording clarifications so I will respond to them separately.

Comments on the changes in -03 or anything else are welcome.

Regards,
Peter



Reviewer

Comment

Resolution

VIJAY

  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.

[20150722] sentence changed in abstract as suggested.

VIJAY

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.

[20150722] new wording proposed for clause 1. Introduction

VIJAY

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

[20150722] REQ6 revised to clarify compatibility with UAs that have not implemented "logme" marking

VIJAY

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.

[20150722] REQ7 revised to clarify that a proxy may be stateless, not the logging of SIP.

VIJAY

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

[20150722] net corrected to next

VIJAY

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?

[20150722] 6. Security Considerations re-worded to clarify that the introductory section just lists the issues to be checked and does not give an opinion or conclusion about them.

CHRISTER

I don't understand REQ4, saying "SIP entities SHOULD log SIP requests
> >> or responses with a "log me" marker."

[20150723] REQ4 reworded to clarify that the logme marker functions to identify SIP messages that are of interest to diagnostics or regression testing so a SIP entity that encounters this marker should log the signalling if possible.

CHRISTER

Also, in e.g. REQ6 it is then said that proxies MAY insert the
> >> marker, which seems to contradict.

[20150723] Added a sentence to REQ6 to clarify that an entity that inserts a "log me" marker should also log the request/response as per REQ4.

CHRISTER

REQ4 could be re-written slightly more clearly as "SIP entities SHOULD
> > log SIP requests or responses that contain a "log me" marker." The SIP
> > entity checks for the presence of a "log me" marker and writes any
> > request or response that contains a "log me" marker to a log file.

[20150723] REQ4 text revised as suggested.

CHRISTER

(REQ4)
> I think it would be good to say "SIP entities that support the mechanism
> SHOULD...", to make it clear that we don't expect certain behaviour from SIP
> entities that do not support the mechanism. Some people may say it's
> obvious, but I think it's good to have it explicit :)

[20150723] Condition added to REQ4 as suggested

CHRISTER

Regarding REQ5, does that also apply to UAs that do NOT support the
> >> mechanism? If so, I think that should be explicitly stated, because
> >> it will have big impact on the technical solution.
> >>
> > UEs that do not support the mechanism are not expected to echo the
> > "log me" marker because they don't know about it. However, if the "log
> > me" marker solution is a header field parameter of the Session-ID
> > header field, as currently proposed, then I guess that even UEs that do not
> support inserting a "log me" marker will echo it if it echoes the whole
> Session-ID header field.
>
> Sure, but that is irrelevant as far as the requirements are concerned :)
>
> So, if we don't REQUIRE anything from UAs that don't support the
> mechanism, I again think it's good to explicitly talk about UAs that support
> the mechanism.

[20150723] Condition added to REQ5 as suggested.

JORGEN

Section 3: I assume the Network A, B, C has no connection to Country A, B, C. Maybe numbers or different letters is clearer.

[20150723] Country letters changed to Q, X, Y, Z

JORGEN

REQ-6: I understand that if the SIP proxy marks a response for logging because the UAS did not echo the log-me marker, then it needs to remember that the marker was present in the request. It is harder to understand what the SIP proxy needs to remember if it decides to mark a request that the UA did not mark. Is this rather configuration than remembering something?

[20150723] REQ9 added to scope "log me" marking to a per-dialog granularity. This makes it possible for UAs and SIP proxies to determine when to start and stop marking.

JORGEN

6.2.1 The text following "Activating a debug mode" contains a number of "it" which I find hard to read. I assume "it" refers to the activation request but I don't think that is clear from the text.

[20150723] In section 6.2.1, replaced each occurrence of "it" (new text between asterisks) as follows.

The "log me" marker is not sensitive information, although (it) *the "log me" marker* will sometimes be inserted because a particular device is experiencing problems.

Activating a debug mode affects the operation of a terminal,
   therefore (it) *debugging configuration* must be supplied by an authorized server to an
   authorized terminal, (it) *debugging configuration* must not be altered in transit, and (it) must
   not be readable by an unauthorized third party.

Logged signalling is privacy-sensitive data, therefore (it) *signalling logs* must be
   passed to an authorized server, (it) must not be altered in transit,
   and (it) must not be readable by an unauthorized third party.

JORGEN

On the nit side, REQ-1 contains a "log me", which I believe should be "log-me".

For consistency, the hyphen has been removed from "log-me" throughout.

GONZALO

Redundant references

[20150723]
RFC2629 "Writing I-Ds and RFCs using XML": deleted from references as not essential to draft
RFC3261 "SIP: Session Initiation Protocol": reference to 3261 added to introduction clause
RFC3311 "The Session Initiation Protocol (SIP) UPDATE Method": deleted from references as not essential to draft
RFC3428 "Session Initiation Protocol (SIP) Extension for Instant Messaging": deleted from references as not essential to draft
RFC3552 "Guidelines for Writing RFC Text on Security Considerations": deleted from references as not essential to draft
RFC3903 "Session Initiation Protocol (SIP) Extension for Event State Publication": deleted from references as not essential to draft
RFC6086 "Session Initiation Protocol (SIP) INFO Method and Package Framework": deleted from references as not essential to draft







> -----Original Message-----

> From: Dawes, Peter, Vodafone Group

> Sent: 19 June 2015 08:36

> To: 'Gonzalo Salgueiro (gsalguei)'; Vijay K. Gurbani

> Cc: Keith Drage; [e-mail]; [e-mail]

> Subject: RE: Review of draft-ietf-insipid-logme-reqs-02

>

> 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:[e-mail]] On Behalf Of Gonzalo

> > Salgueiro (gsalguei)

> > Sent: 18 June 2015 16:12

> > To: Vijay K. Gurbani

> > Cc: Keith Drage; [e-mail]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>

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

> >

> > 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]<mailto:[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}<mailto:vkg@%7bbell-labs.com,acm.org%7d> /

> > > [e-mail]<mailto:[e-mail]>

> > > Web: http://ect.bell-labs.com/who/vkg/  | Calendar:

> > > http://goo.gl/x3Ogq

> >

> > _______________________________________________

> > insipid mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://www.ietf.org/mailman/listinfo/insipid