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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Mon, 14 September 2015 09:55 UTC

Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B192C1B3802 for <insipid@ietfa.amsl.com>; Mon, 14 Sep 2015 02:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc7Q0eiBUzYq for <insipid@ietfa.amsl.com>; Mon, 14 Sep 2015 02:55:49 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7B21B3F21 for <insipid@ietf.org>; Mon, 14 Sep 2015 02:55:48 -0700 (PDT)
Received: from [85.158.136.83] by server-11.bemta-5.messagelabs.com id 96/54-24494-2A996F55; Mon, 14 Sep 2015 09:55:46 +0000
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-9.tower-36.messagelabs.com!1442224545!23475651!1
X-Originating-IP: [195.232.244.135]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14178 invoked from network); 14 Sep 2015 09:55:45 -0000
Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-9.tower-36.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2015 09:55:45 -0000
Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout03.vodafone.com (Postfix) with ESMTP id 3nF33P0bJgz17HNP; Mon, 14 Sep 2015 11:55:45 +0200 (CEST)
Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3nF33N6HxfzxPTS; Mon, 14 Sep 2015 11:55:44 +0200 (CEST)
Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3nF33N6B7NzxRb4; Mon, 14 Sep 2015 11:55:44 +0200 (CEST)
Received: from VOEXC26W.internal.vodafone.com (145.230.103.198) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 14 Sep 2015 11:53:46 +0200
Received: from VOEXM32W.internal.vodafone.com ([169.254.8.105]) by voexc26w ([145.230.103.198]) with mapi id 14.03.0224.002; Mon, 14 Sep 2015 11:53:36 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "insipid@ietf.org" <insipid@ietf.org>
Thread-Topic: Review of draft-ietf-insipid-logme-reqs-02
Thread-Index: AQHQqdFtOKOrMiiSR0O8l6HE5qr46J2yPRaAgAEwsqCANc9P8IArOgtAgCfUDxA=
Date: Mon, 14 Sep 2015 09:53:34 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8432306@voexm32w.internal.vodafone.com>
References: <5582D306.8070305@bell-labs.com> <2F9A1E5D-6304-4384-82C2-5EE19B953DDE@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xYE>
Cc: "Arun Arunachalam (carunach) (carunach@cisco.com)" <carunach@cisco.com>, "Vijay K. Gurbani" <vkg@bell-labs.com>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2015 09:55:53 -0000

Hello All,
Rev -04 of the logme requirements draft was uploaded a few weeks ago and the authors believe that this version resolves all comments from reviewers. Between -03  and -04, four of the more complex comments from Vijay were resolved; the comment and resolution are copied below in case the HTML table in the e-mail on 20th August was hard to read in plain text. 

Resolutions of comments made in version -03 were summarized in the e-mail of Thu 23/07/2015 14:13 and for most of them the commenter suggested the resolution.

Vijay, do the changes below address your concerns? Happy to hear further comments from anyone although I think all previous suggestions have been accepted and incorporated in the draft.

Regards,
Peter

[comment 1 of 4]
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?

[resolution 1 of 4]
At the beginning of clause 4. "Basic Debugging Procedure" clarified that logs contain the The entire SIP message (SIP headers and message body). Header fields are logged in their long form and not the compact form described in RFC 3261 clause 7.3.3.

[comment 2 of 4]
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, ...)?

[resolution 2 of 4]
At the end of clause 4. "Basic Debugging Procedure" clarified that when and how logs of signalling are retrieved is outside the scope of this draft.

[comment 3 of 4]
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?

[resolution 3 of 4]
At the end of clause 4. "Basic Debugging Procedure" clarified that the definition of stop event types and the configuration of stop events in the SIP entity is outside the scope of this document.

[comment 4 of 4]
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.

[resolution 4 of 4]
At the beginning of clause 4. "Basic Debugging Procedure" clarified that logging uses the SIP CLF format and included a reference to RFC 6873.

From: Dawes, Peter, Vodafone Group 
Sent: 20 August 2015 02:35
To: 'insipid@ietf.org'
Cc: 'Keith Drage'; 'Gonzalo Salgueiro (gsalguei)'; 'Vijay K. Gurbani'; Jörgen Axell (jorgen.axell@ericsson.com); Christer Holmberg (christer.holmberg@ericsson.com); Arun Arunachalam (carunach) (carunach@cisco.com)
Subject: RE: Review of draft-ietf-insipid-logme-reqs-02

Hello All,
As summarized below, the remaining open comments on version -02 have now been resolved in uploaded revision -04 (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/). 

Reviewer
Comment
Resolution
VIJAY
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?
[150819] At the beginning of clause 4. "Basic Debugging Procedure" clarified that logs contain the The entire SIP message (SIP headers and message body). Header fields are logged in their long form and not the compact form described in RFC 3261 clause 7.3.3.
VIJAY
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, ...)?
[150819] At the end of clause 4. "Basic Debugging Procedure" clarified that when and how logs of signalling are retrieved is outside the scope of this draft. 
VIJAY
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?
[150819] At the end of clause 4. "Basic Debugging Procedure" clarified that the definition of stop event types and the configuration of stop events in the SIP entity is outside the scope of this document.
VIJAY
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.
[150819] At the beginning of clause 4. "Basic Debugging Procedure" clarified that logging uses the SIP CLF format and included a reference to RFC 6873. 

The draft now has two authors as Arun Arunachalam has kindly offered to also contribute and helped resolve the comments. 

I believe that all of the review comments are now resolved. 

Regards,
Peter


From: Dawes, Peter, Vodafone Group 
Sent: 23 July 2015 06:13
To: 'insipid@ietf.org'
Cc: 'Keith Drage'; 'Gonzalo Salgueiro (gsalguei)'; 'Vijay K. Gurbani'; Jörgen Axell (jorgen.axell@ericsson.com); Christer Holmberg (christer.holmberg@ericsson.com)
Subject: RE: Review of draft-ietf-insipid-logme-reqs-02

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; insipid@ietf.org; draft-ietf-insipid-logme-reqs@tools.ietf.org
> 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:insipid-bounces@ietf.org] On Behalf Of Gonzalo
> > Salgueiro (gsalguei)
> > Sent: 18 June 2015 16:12
> > To: Vijay K. Gurbani
> > Cc: Keith Drage; insipid@ietf.org;
> > draft-ietf-insipid-logme-reqs@tools.ietf.org
> > 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 <vkg@bell-labs.com>
> 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} /
> > > vijay.gurbani@alcatel-lucent.com
> > > Web: http://ect.bell-labs.com/who/vkg/  | Calendar:
> > > http://goo.gl/x3Ogq
> >
> > _______________________________________________
> > insipid mailing list
> > insipid@ietf.org
> > https://www.ietf.org/mailman/listinfo/insipid