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

Peter Musgrave <> Tue, 01 May 2012 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D08521F875B for <>; Tue, 1 May 2012 02:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ofQ2OHlzlKO for <>; Tue, 1 May 2012 02:50:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B1E121F8759 for <>; Tue, 1 May 2012 02:50:48 -0700 (PDT)
Received: by iazz13 with SMTP id z13so6520030iaz.31 for <>; Tue, 01 May 2012 02:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XERyMw6uwUH5Yxcm+x+sRAQSrC2vVs96L1eTughN0JE=; b=JKl9IRGdPh3Eft0SEUFnGdM8maW8shKnbBWfdkLgvl0cyKXEpMS46/N8ocbWIhVkue mnaKG5OJY7ldfBZ/2ps2RoCi02iJR+h6tyxWurBDdgxXdJh/3DNTdUcrVZsR5Tp7Zx46 FEs06EuMhR18N2QLAUMhwq+SeTr8PXFxpX5YDyjwlhKctuq+Lkp7lQpcT8koTsz+uiTg Z6htSADG/tkGtE3+/XwuGDsNXUfIFa/JIzin7YnBg/QLv3LME5Ms1ZtaWn6pbtcmQQUo kYOrDVWZIRd7ATRxhxGrGxaG/abXzNB+Q8v1N+gmeBklYN/1MaJ8F95xLMLT1jxj3O7U R6XQ==
Received: by with SMTP id q2mr1789336icr.52.1335865847494; Tue, 01 May 2012 02:50:47 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id cg9sm40514091igb.17.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 02:50:46 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Peter Musgrave <>
In-Reply-To: <>
Date: Tue, 1 May 2012 05:50:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Gonzalo Salgueiro <>
X-Mailer: Apple Mail (2.1257)
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: Tue, 01 May 2012 09:50:49 -0000

Thanks Gonzalo and Robert,

Based on Robert's earlier email about 06 and the number of changes, once we have 07 I will push for some additional scrutiny by the WG and do a WGLC.

Can I call for volunteers to review? The diffs since -05 will be the key areas to focus on.

Thanks all,


On 2012-05-01, at 4:53 AM, Gonzalo Salgueiro wrote:

> 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.
> _______________________________________________
> sip-clf mailing list