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

"Vijay K. Gurbani" <vkg@bell-labs.com> Thu, 18 June 2015 14:16 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9069F1B321B for <insipid@ietfa.amsl.com>; Thu, 18 Jun 2015 07:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RzqwDTfuw-Bh for <insipid@ietfa.amsl.com>; Thu, 18 Jun 2015 07:16:16 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com []) (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 4891F1B3216 for <insipid@ietf.org>; Thu, 18 Jun 2015 07:16:15 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown []) by Websense Email Security Gateway with ESMTPS id 66F52EC2DEA80; Thu, 18 Jun 2015 14:16:10 +0000 (GMT)
Received: from umail.lucent.com (umail.ndc.lucent.com []) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t5IEGArE013254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2015 14:16:12 GMT
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com []) by umail.lucent.com (8.13.8/TPES) with ESMTP id t5IEG5Gb000482; Thu, 18 Jun 2015 09:16:05 -0500 (CDT)
Message-ID: <5582D306.8070305@bell-labs.com>
Date: Thu, 18 Jun 2015 09:17:42 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: insipid@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/lD_87m-plpvQ-gcv_QJdydhmnuA>
X-Mailman-Approved-At: Thu, 18 Jun 2015 09:18:29 -0700
Cc: "Drage, Keith \(Keith\)" <keith.drage@ALCATEL-LUCENT.COM>, Gonzalo Salgueiro <gsalguei@cisco.com>, draft-ietf-insipid-logme-reqs@tools.ietf.org
Subject: [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: Thu, 18 Jun 2015 14:16:19 -0000

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
   - 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?


- 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