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

[Peter Musgrave <[e-mail]>]

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,

Peter

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf