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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Thu, 20 August 2015 01:35 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 3773F1A8A63 for <insipid@ietfa.amsl.com>; Wed, 19 Aug 2015 18:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level:
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dJLTCeAmopFG for <insipid@ietfa.amsl.com>; Wed, 19 Aug 2015 18:35:18 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) (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 A3BB91A1EE8 for <insipid@ietf.org>; Wed, 19 Aug 2015 18:35:17 -0700 (PDT)
Received: from [195.245.230.51] by server-16.bemta-3.messagelabs.com id 41/1B-03763-3DE25D55; Thu, 20 Aug 2015 01:35:15 +0000
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-13.tower-33.messagelabs.com!1440034514!22652727!1
X-Originating-IP: [195.232.244.133]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19407 invoked from network); 20 Aug 2015 01:35:14 -0000
Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-13.tower-33.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Aug 2015 01:35:14 -0000
Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout01.vodafone.com (Postfix) with ESMTP id 3mxT7Q2rvrz1yFx; Thu, 20 Aug 2015 03:35:14 +0200 (CEST)
Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3mxT7Q1Q6XzfZYr; Thu, 20 Aug 2015 03:35:14 +0200 (CEST)
Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3mxT7Q0v2dzfZCM; Thu, 20 Aug 2015 03:35:14 +0200 (CEST)
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.43]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0224.002; Thu, 20 Aug 2015 03:35:13 +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: AQHQqdFtOKOrMiiSR0O8l6HE5qr46J2yPRaAgAEwsqCANc9P8IArOgtA
Date: Thu, 20 Aug 2015 01:35:13 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83FED4C@VOEXM31W.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: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C83FED4CVOEXM31Winterna_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/qmVInL8eBmDUxrh215XaaBEjnHo>
Cc: "Arun Arunachalam \(carunach\) \(carunach@cisco.com\)" <carunach@cisco.com>, Keith Drage <keith.drage@ALCATEL-LUCENT.COM>, "Gonzalo Salgueiro \(gsalguei\)" <gsalguei@cisco.com>, =?utf-8?B?SsO2cmdlbiBBeGVsbCAoam9yZ2VuLmF4ZWxsQGVyaWNzc29uLmNvbSk=?= <jorgen.axell@ericsson.com>, "Christer Holmberg \(christer.holmberg@ericsson.com\)" <christer.holmberg@ericsson.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: Thu, 20 Aug 2015 01:35:25 -0000

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<mailto:insipid@ietf.org>; draft-ietf-insipid-logme-reqs@tools.ietf.org<mailto: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<mailto:insipid@ietf.org>;

> > draft-ietf-insipid-logme-reqs@tools.ietf.org<mailto: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<mailto: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}<mailto:vkg@%7bbell-labs.com,acm.org%7d> /

> > > vijay.gurbani@alcatel-lucent.com<mailto:vijay.gurbani@alcatel-lucent.com>

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

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

> >

> > _______________________________________________

> > insipid mailing list

> > insipid@ietf.org<mailto:insipid@ietf.org>

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