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

[Robert Sparks <[e-mail]>]

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.