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

"Gonzalo Salgueiro (gsalguei)" <> Thu, 18 June 2015 15:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 68B061A1BED for <>; Thu, 18 Jun 2015 08:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 24OaF3_MePoD for <>; Thu, 18 Jun 2015 08:12:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5461C1A02F1 for <>; Thu, 18 Jun 2015 08:12:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6020; q=dns/txt; s=iport; t=1434640323; x=1435849923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=62yHiQtnWCviEsSNHaHmdmaLNWnccgwmfiHUMZwwad0=; b=HgUdFWj7Y8t3JbokXV0WD4QGQRsfKdKnPds+8y2MSeJAPAXyQs2XoZXC 8VLJqyEYe068MxvhBWgdawwabJg+qxC1//aUfLbZrpKXkc1T1E2dIZaVI uZIxc/IFU7wGku7Oz9ZgrcBImUgDIGCo47DFfVUpSWX09f7TJFlJdROd/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208";a="160723477"
Received: from ([]) by with ESMTP; 18 Jun 2015 15:12:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5IFC2rG022975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 15:12:02 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 10:12:02 -0500
From: "Gonzalo Salgueiro (gsalguei)" <>
To: "Vijay K. Gurbani" <>
Thread-Topic: Review of draft-ietf-insipid-logme-reqs-02
Thread-Index: AQHQqdFY3CjRvF8vUECkDPX4uQNw/52ysn8A
Date: Thu, 18 Jun 2015 15:12:01 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: Keith Drage <keith.drage@ALCATEL-LUCENT.COM>, "" <>, "" <>
Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2015 15:12:05 -0000

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.



> On Jun 18, 2015, at 10:17 AM, Vijay K. Gurbani <> 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@{,} /
> Web:  | Calendar: