Re: [sip-clf] AD review: draft-ietf-sipclf-format-05

Gonzalo Salgueiro <gsalguei@cisco.com> Tue, 01 May 2012 08:53 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: sip-clf@ietfa.amsl.com
Delivered-To: sip-clf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFDA21F86D4 for <sip-clf@ietfa.amsl.com>; Tue, 1 May 2012 01:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzayvBUzPUQF for <sip-clf@ietfa.amsl.com>; Tue, 1 May 2012 01:53:16 -0700 (PDT)
Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id DF12221F86C9 for <sip-clf@ietf.org>; Tue, 1 May 2012 01:53:16 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q418rF8g014939 for <sip-clf@ietf.org>; Tue, 1 May 2012 01:53:16 -0700 (PDT)
Received: from [10.21.86.251] ([10.21.86.251]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q418rC9U018836; Tue, 1 May 2012 01:53:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <4F9EDD13.6010507@nostrum.com>
Date: Tue, 1 May 2012 04:53:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D98ACB6-FD8B-43C6-9A96-5B83712CCC35@cisco.com>
References: <4F21DD3E.7000002@nostrum.com> <31A5C897-B767-4527-9346-905A80977F35@cisco.com> <4F9EDD13.6010507@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1257)
Cc: draft-ietf-sipclf-format@tools.ietf.org, sipclf-chairs@tools.ietf.org, "sip-clf@ietf.org Mailing" <sip-clf@ietf.org>
Subject: Re: [sip-clf] AD review: draft-ietf-sipclf-format-05
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2012 08:53:17 -0000

Thanks for the feedback Robert. I'm traveling this week but I'll look through your other email and provide responses to your individual comments. Once we settle on the text I'll produce an -07 version for you to take to the IESG.

Cheers,

Gonzalo

On Apr 30, 2012, at 2:42 PM, Robert Sparks wrote:

> Hi Gonzalo -
> 
> I'm going through all the messages in the threads since the original publication request of -05.
> There are some things we discuss below that still need touching in -06
> (I'm preparing an evaluation of -06 separately and will include these in that message, but wanted to reply here to make it easier for everyone to follow the context)
> 
> On 2/8/12 6:25 PM, Gonzalo Salgueiro wrote:
>> Robert -
>> 
>> Thanks for your thorough and thoughtful review. Below are some inline comments to your feedback.
>> 
>> I will release the -06 version of the draft once we have settled on all of the below points you have raised.
>> 
>> 
>> On Jan 26, 2012, at 6:09 PM, Robert Sparks wrote:
>> 
>>> AD review: draft-ietf-sipclf-format-05
>>> 
>>> Summary: This document has open issues to address before progressing to IETF LC
>>> 
>>> Major (mostly in document order)
>>> 
> <snip/>
>>> 5) The document should more explicitly discuss the decision to replace
>>> tabs with spaces. That decision was based on there being no known use
>>> of tabs in SIP messages that means something semantically other than
>>> whitespace. The discussion should point that out, and note that you
>>> will not be able to use the logged information to reconstruct a
>>> signature over the logged fields, and that any future (or proprietary)
>>> SIP header fields that include tabs with semantic meaning (carrying a
>>> blob perhaps) will lose this meaning while being logged. It should also
>>> be made brutally explicit whether you want this substitution to happen
>>> when you are logging the entire message, or a body (that might happen
>>> to have tabs in it).
>> 
>> We will add a new paragraph that goes something
>> like this (the new paragraph is added at the end of S4.2 paragraph
>> "This data MUST appear ... (0x20) prior to being logged."):
>> 
>> The decision to replace tabs with spaces was based on there
>> being no known use of tabs in SIP messages to convey any other
>> meaning than whitespace.  Two consequences of the decision to
>> replace tab with a space character are: (a) it will become
>> impossible to reconstruct a signature over the logged field that
>> matches the signature over fields in the original SIP message,
>> and (b) any future SIP header fields that include tabs with a
>> different semantic meaning than simply signifying whitespace
>> will loose this meaning when logged.  And finally, the tabs to
>> spaces substitution MUST occur when logging mandatory fields;
>> it SHOULD occur when when logging either the entire message or
>> simply a SIP body.
> Why SHOULD? When would you violate that SHOULD?
> 
> 
> <snip/>
>>> Minor
>>> 
> 
>>> There are blocks of text in this document that are really laying out the problem.
>>> Can they be moved into the problem statement/information model/framework document
>>> or simply deleted?
>>> For example: "Implementing a logging scheme for SIP is a considerable challenge.",
>>> "Whilst one may question the value of the From URI [...]", etc.
>> 
>> Ok. I'll scour the document for instances of such text and remove them.
> The "considerable challenge" sentence remains in -06?
>> 
>> 
>> 
>>> In section 4.2's description of the To tag field you say "Value of the
>>> tag parameter (if present)" but don't talk about what to do if the tag
>>> parameter isn't present. In the parallel section on the From tag, you
>>> don't talk about the potential for messages without From tags. If it's
>>> the intent to not be able to log messages from legacy 2543 devices, that's
>>> fine, but the document should call that out as a design decision and it wouldn't
>>> hurt to provide some guidance on what to do if such a message shows up.
>> 
>> I'll add some text to clarify and simplify this. Basically, if the tag is present in To and From,
>> it is logged. If it is not present, a "-" is logged. I'll leave it at that. The intent is not
>> to differentiate between messages from legacy rfc2543 devices versus the
>> updated rfc3261.
>> 
> I'm not easily finding new text? If it's there, pointing at it from the descriptions in 4.2 will help.
> 
>