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

Robert Sparks <> Mon, 30 April 2012 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1605E21F8877 for <>; Mon, 30 Apr 2012 11:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ilQ8y3S-v18x for <>; Mon, 30 Apr 2012 11:42:36 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 32E0C21F8869 for <>; Mon, 30 Apr 2012 11:42:36 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q3UIgSGl041234 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 13:42:31 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Mon, 30 Apr 2012 13:42:27 -0500
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Gonzalo Salgueiro <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc:,, " Mailing" <>
Subject: Re: [sip-clf] AD review: draft-ietf-sipclf-format-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Apr 2012 18:42:37 -0000

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

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