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

"Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> Fri, 19 June 2015 07:36 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 3A9FF1A00CF for <insipid@ietfa.amsl.com>; Fri, 19 Jun 2015 00:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 XvTCvUD73iF8 for <insipid@ietfa.amsl.com>; Fri, 19 Jun 2015 00:36:25 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (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 8D7371A00AE for <insipid@ietf.org>; Fri, 19 Jun 2015 00:36:25 -0700 (PDT)
Received: from [85.158.138.179] by server-13.bemta-3.messagelabs.com id 1B/29-11060-776C3855; Fri, 19 Jun 2015 07:36:23 +0000
X-Env-Sender: Peter.Dawes@vodafone.com
X-Msg-Ref: server-6.tower-169.messagelabs.com!1434699383!13349083!1
X-Originating-IP: [195.232.244.133]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18882 invoked from network); 19 Jun 2015 07:36:23 -0000
Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-6.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jun 2015 07:36:23 -0000
Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout01.vodafone.com (Postfix) with ESMTP id 3mCX4k3BVCz1yG2; Fri, 19 Jun 2015 09:36:22 +0200 (CEST)
Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3mCX4k1wjKz16LB8; Fri, 19 Jun 2015 09:36:22 +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 mailint03.vodafone.com (Postfix) with ESMTPS id 3mCX4k1SWHz16L5v; Fri, 19 Jun 2015 09:36:22 +0200 (CEST)
Received: from VOEXC08W.internal.vodafone.com (145.230.101.28) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 19 Jun 2015 09:36:11 +0200
Received: from VOEXM31W.internal.vodafone.com ([169.254.7.90]) by voexc08w.internal.vodafone.com ([145.230.101.28]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 09:35:51 +0200
From: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "Vijay K. Gurbani" <vkg@bell-labs.com>
Thread-Topic: Review of draft-ietf-insipid-logme-reqs-02
Thread-Index: AQHQqdFtOKOrMiiSR0O8l6HE5qr46J2yPRaAgAEwsqA=
Date: Fri, 19 Jun 2015 07:35:50 +0000
Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE46B6@VOEXM31W.internal.vodafone.com>
References: <5582D306.8070305@bell-labs.com> <2F9A1E5D-6304-4384-82C2-5EE19B953DDE@cisco.com>
In-Reply-To: <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/9tnhAa8IMK3tcHeY22Ip_mJziUQ>
Cc: Keith Drage <keith.drage@ALCATEL-LUCENT.COM>, "insipid@ietf.org" <insipid@ietf.org>, "draft-ietf-insipid-logme-reqs@tools.ietf.org" <draft-ietf-insipid-logme-reqs@tools.ietf.org>
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: <http://www.ietf.org/mail-archive/web/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: Fri, 19 Jun 2015 07:36:28 -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: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