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

Robert Sparks <rjsparks@nostrum.com> Mon, 30 April 2012 18:42 UTC

Return-Path: <rjsparks@nostrum.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 1605E21F8877 for <sip-clf@ietfa.amsl.com>; Mon, 30 Apr 2012 11:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilQ8y3S-v18x for <sip-clf@ietfa.amsl.com>; Mon, 30 Apr 2012 11:42:36 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0C21F8869 for <sip-clf@ietf.org>; Mon, 30 Apr 2012 11:42:36 -0700 (PDT)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (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 rjsparks@nostrum.com)
Message-ID: <4F9EDD13.6010507@nostrum.com>
Date: Mon, 30 Apr 2012 13:42:27 -0500
From: Robert Sparks <rjsparks@nostrum.com>
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 <gsalguei@cisco.com>
References: <4F21DD3E.7000002@nostrum.com> <31A5C897-B767-4527-9346-905A80977F35@cisco.com>
In-Reply-To: <31A5C897-B767-4527-9346-905A80977F35@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
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: 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)
>>
<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.