Re: [sip-clf] draft-ietf-sipclf-format-00 comments

Gonzalo Salgueiro <gsalguei@cisco.com> Sat, 12 March 2011 00:29 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41DD3A6A14 for <sip-clf@core3.amsl.com>; Fri, 11 Mar 2011 16:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.473
X-Spam-Level:
X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm83mGPKRivn for <sip-clf@core3.amsl.com>; Fri, 11 Mar 2011 16:29:54 -0800 (PST)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 5D26D3A6AEA for <sip-clf@ietf.org>; Fri, 11 Mar 2011 16:29:54 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2C0VDlv017532; Fri, 11 Mar 2011 19:31:13 -0500 (EST)
Received: from dhcp-64-102-154-216.cisco.com (dhcp-64-102-154-216.cisco.com [64.102.154.216]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2C0VCm8016810; Fri, 11 Mar 2011 19:31:12 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-77--539874836"
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <AANLkTikyir9cWQTmfQOaOYFq9yhY9QQ+Zh01zDwO4yJG@mail.gmail.com>
Date: Fri, 11 Mar 2011 19:31:12 -0500
Message-Id: <2832080D-418A-41DD-80C9-2BA0053C1DBC@cisco.com>
References: <AANLkTimXr_8sHoUCOBkJtLR073=Z-m2A=jqbs4FXyNs+@mail.gmail.com> <B116D9C8-C234-44C7-B2D4-3F2C9860A8BD@cisco.com> <AANLkTi=c842r67B=BZU0Ep-_+mijeTvBw55M3qTEVvf1@mail.gmail.com> <7321A81E-1E05-4EBF-8250-1AF9DD09CEA4@cisco.com> <AANLkTikyir9cWQTmfQOaOYFq9yhY9QQ+Zh01zDwO4yJG@mail.gmail.com>
To: Anders Nygren <anders.nygren@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: sip-clf@ietf.org
Subject: Re: [sip-clf] draft-ietf-sipclf-format-00 comments
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 12 Mar 2011 00:29:55 -0000

Anders - 

Inline..
On Mar 11, 2011, at 6:54 PM, Anders Nygren wrote:

> Hi
> In chapter 4.1, the text
>  "The <IndexPointers> portion of the SIP CLF record is a 64-byte header
>   that indicates meta-data about the record."
> is repeated before and after the figure 3.

[GS] Fixed.
> 
> chapter 4.3 figure 5 shows a 0x0A after the TLVs. But I think that
> 0x0A is not part of the
> optional parameters portion but is the termination of the record, and
> should be included
> even if there are no optional parameters in the record.

[GS] In principle I agree with you. For the sake of graphical continuity, I'll need to get creative so that I don't need to represent the logical structure of the SIP CLF record as:

        <IndexPointers>
        <MandatoryFields>
        <OptionalFields>
	0x0A

I'll kick it around in my head as to how best represent that.  Great catch.

Regards,

Gonzalo
 
> 
> /Anders
> 
> 
> On Fri, Mar 11, 2011 at 5:07 PM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
>> Thanks Anders. This reflected an earlier intent for microsecond accuracy
>> that has since been rescinded. I have amended the text.
>> Regards,
>> Gonzalo
>> On Mar 11, 2011, at 5:43 PM, Anders Nygren wrote:
>> 
>> One more thing,
>> page 9,
>> The text says that fractional seconds is 6 bytes but figure 4 shows 3 bytes.
>> 
>> /Anders
>> 
>> On Fri, Mar 11, 2011 at 1:38 PM, Gonzalo Salgueiro <gsalguei@cisco.com>
>> wrote:
>> 
>> Anders -
>> 
>> Thanks for providing your feedback, it is much appreciated as we work
>> through developing this format.
>> 
>> I'm very glad to hear you are implementing this already and would be willing
>> to follow up with you offline to get some data points on how you decided to
>> do this, how difficult it was, and how useful you found it, what you would
>> change, etc.
>> 
>> Comments inline...
>> 
>> On Mar 11, 2011, at 1:01 PM, Anders Nygren wrote:
>> 
>> Hi
>> 
>> I am not sure what is the correct way for commenting on the SIP-CLF spec,
>> 
>> so I will do it here until someone tells me that there is a better
>> 
>> place to do it.
>> 
>> [GS] This is indeed the place.
>> 
>> I am trying to implement a log reader and writer according to
>> 
>> draft-ietf-sipclf-format-00 and have found a few small errors.
>> 
>> page 8:
>> 
>>   "Record Length (6 bytes):  Hexadecimal encoded total length of this
>> 
>>    log record, including "Flags" and "Record Length" fields, and
>> 
>>    terminating line-feed."
>> 
>> Should that include the version field as well?
>> 
>> [GS] Yes this does include the Version field. It is the length of the ENTIRE
>> record including all of <IndexPointers>, <MandatoryFields>, <OptionalFields>
>> 
>> The list of items in the text you have selected is not meant to be  complete
>> listing of all fields, rather a representative list indicating that
>> everything is included. If you think there is value in specifically
>> mentioning the Version field, then I will modify the text as follows:
>> 
>> Hexadecimal encoded total length of this log record, including "Version",
>> "Record Length", "Flags" fields, and terminating line-feed.
>> 
>> 
>> 
>> page 12:
>> 
>>   "Length Field (2 bytes):  Indicates the length of the value coded in
>> 
>>    this TLV, hexadecimal encoded.  This length does NOT include the
>> 
>>    TLV header."
>> 
>> The length field is shown as 4 bytes in figure 5.
>> 
>> Thanks. Great catch.  This is indeed wrong. The figure is correct. I will
>> change the text to 4 bytes.
>> 
>> Warm Regards,
>> 
>> Gonzalo
>> 
>> /Anders Nygren
>> 
>> _______________________________________________
>> 
>> sip-clf mailing list
>> 
>> sip-clf@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/sip-clf
>> 
>> 
>> 
>>