From prvs=53658f5002=eburger@alum.mit.edu Wed Jan 18 17:08:11 2012 Return-Path: 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 7FEC511E80F9 for ; Wed, 18 Jan 2012 17:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 fUQcmsHxbkYY for ; Wed, 18 Jan 2012 17:08:11 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (ALUM-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id D18A611E80F8 for ; Wed, 18 Jan 2012 17:08:10 -0800 (PST) X-AuditID: 12074412-b7f1c6d00000092d-4f-4f176cfaed0b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B1.3B.02349.AFC671F4; Wed, 18 Jan 2012 20:08:10 -0500 (EST) Received: from [192.168.15.184] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (authenticated bits=0) (User authenticated as eburger@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id q0J188ew024624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2012 20:08:09 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Burger Eric In-Reply-To: <212E7733-3FF6-47D4-A3E3-65471F677A25@standardstrack.com> Date: Wed, 18 Jan 2012 20:08:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <212E7733-3FF6-47D4-A3E3-65471F677A25@standardstrack.com> To: "sip-clf@ietf.org Mailing" X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqPsrR9zf4Nd1IYstN9+yWxzb08/s wOSxZMlPJo+5e14wBzBFcdskJZaUBWem5+nbJXBnTJp4gr3gLHPF1q6ZTA2Mr5m6GDk5JARM JI4/PcEKYYtJXLi3nq2LkYtDSOAyo8T8ln/sEM5RJonZ1w+zgVQJC1hLzNv1lQXE5hUwlFi6 qZ0dxGYW0JK48e8l2FQ2AQ2JZ53bwWxOATeJnmtvGLsYOThYBFQlfm8pgSl/0f2CFcLWlli2 8DUzxEh7icmzuhlBbCEBV4ll9zaDrRIBWnX41VKwMRICshJNyzImMArMQnLELCRHzEIydQEj 8ypGucSc0lzd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2MkEAV2sG4/qTcIUYBDkYlHt4I EXF/IdbEsuLK3EOMkhxMSqK8h7KBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4d5oA5XhTEiur UovyYVLSHCxK4rw/F6v7CQmkJ5akZqemFqQWwWRlODiUJHjtgBEpJFiUmp5akZaZU4KQZuLg BBFcIBt4gDYkgxTyFhck5hZnpkMUnWJUlBLnbQRJCIAkMkrz4AbAUsorRnGgf4R5t4EczwNM R3Ddr4AGMwEN9mgSAxlckoiQkmpgXKPikeWhtXb+hsqmjXULd3WlftrxQXhmhXiIpq+yyHRZ 7j0qwRy+D7NW5/Rz8DXNnmux3isnS1xzWlvC/V7xxYx3RHztN3/JtK25KtW21jVo3ZQnKQdE 5kR8v6PyOvjzAukP8Q3nphWwiVxRsOyz4gnsnTHFeIZzAfec/olOvis+9hkXFp1RYinOSDTU Yi4qTgQAqgkK2QQDAAA= Cc: Saint-Andre Peter Subject: Re: [sip-clf] International Oops in sipclf Problem Statement X-BeenThere: sip-clf@ietf.org 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: Thu, 19 Jan 2012 01:08:11 -0000 The current text says SIPCLF fields are ASCII. However, as we know, SIP = fields are UTF-8. We propose changing all instances of ASCII in the = document with UTF-8. Same for the sipclf-format document. This is an = awesome catch by Peter Saint-Andre. Our guess is that most of you read octets and write octets. Rendering = programs will not quite work if an extended UTF-8 character pops up, but = that should be easy to fix. Anyone disagree? From musgravepj@gmail.com Fri Jan 20 02:49:33 2012 Return-Path: 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 58F1C21F85EA for ; Fri, 20 Jan 2012 02:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DEALS=2.3, RCVD_IN_DNSWL_LOW=-1] 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 TwuySzsQsyRk for ; Fri, 20 Jan 2012 02:49:32 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 39FDD21F85DB for ; Fri, 20 Jan 2012 02:49:32 -0800 (PST) Received: by qabj34 with SMTP id j34so260644qab.10 for ; Fri, 20 Jan 2012 02:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=Ia7By8sTe79PLK5P0mRDklFKZSlvghtEuA6UWqf5tpE=; b=oDqct7681cPePCuf7KwiRV/S/ZsOVgrGuuAQKq8AMiSGBo3yRlJLjvzR+aYo07tCGQ sQx3mCa+2cSThfMpXNnzIDnqa0CU+uiBeDMx4eTAG9WRueFgMpGM28nU4+PsHmGIIvbp +AvZBExUn2DTmXHx+FhATLFW/t2Y1bRTAWzKU= Received: by 10.224.111.6 with SMTP id q6mr32779664qap.65.1327056570417; Fri, 20 Jan 2012 02:49:30 -0800 (PST) Received: from [192.168.1.105] ([204.237.33.112]) by mx.google.com with ESMTPS id q14sm5873160qap.4.2012.01.20.02.49.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:49:29 -0800 (PST) From: Peter Musgrave Content-Type: multipart/alternative; boundary=Apple-Mail-4-857016233 Date: Fri, 20 Jan 2012 05:49:27 -0500 References: To: sip-clf@ietf.org Message-Id: <99979207-4176-46FC-AF7A-3B437D5D3B2B@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sip-clf] Fwd: AppsDir review of 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 10:49:33 -0000 --Apple-Mail-4-857016233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Claudio Allocchio > Date: January 19, 2012 5:21:29 AM EST > To: apps-discuss@ietf.org, draft-ietf-sipclf-format.all@tools.ietf.org > Subject: AppsDir review of draft-ietf-sipclf-format-05 >=20 >=20 > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-sipclf-format-05 > Title: Format for the Session Initiation Protocol (SIP) Common Log = Format > (CLF) > Reviewer: Claudio Allocchio > Review Date: 2012-01-18 > IETF Last Call Date: unknown > IESG Telechat Date: unknown >=20 > NOTE: is there is an IESG telechat which I'm missing, just copy this = messae to iesg ML! >=20 > Summary: >=20 > This draft is ready for publication as a Proposed Standard RFC; it = just needs one consideration about a minor issue about an external = reference, and fixing some Nits. >=20 > Major Issues: >=20 > NONE >=20 > Minor Issues: >=20 > just one ! >=20 > * Section "3. Document Conventions" >=20 > The authors have decided "For the sake of clarity and completeness" to = quote a full section of RFC4475 into this document. However there were = quite long discussions in the Apps Dir in other reviews if this quoting = practice is appropriate or not, because it can lead to discrepacies, = when the quoted document is updated or obsoleted, resuing in confusion = for the readers who just trust the quoted text without checking the = state of the referenced document. I would suggest, as in the other = cases, NOT to quote the external text, but to use an explicit external = reference only, urging the reader to check that "for the sake of = clarity". >=20 > Nits: >=20 > * Section "Copyright Notice" >=20 > change the year to 2012. >=20 > * Section "3. Document Conventions" >=20 > remember to change "formatting rules for Internet-Drafts" into = "formatting rules for RFCs" when published. >=20 > * Section "4. Format" >=20 > I do understand that it probably does not fit into the I-D formatting = line lenghts, but... maybe an attempt to add aside the SIP CLF record = depicted in Figure 1 the grouping described as >=20 > > > >=20 > in the figure 1 itself (on the left?) may help in reading the = distinction, and maybe may even not require to repeat portions of the = figure itself later in the I-D, like in figure 3, figure 4 and figure 5. = It is really a nit and just a suggestion. Not really important. >=20 > What I am suggesting: >=20 > +----------------------------------+ > /| | > / | | > P | | > o | | > I i | | > n n | | > d t | | > e e | | > x r | | > s | | > \ | | > \| | > +----------------------------------+ > /| | > / | | > M | | > a F | | > n i | | > d e | | > a l | | > t d | | > o s | | > r | | > y \ | | > \| | > +----------------------------------+ > /| | > / | | > O | | > p F | | > t i | | > i e | | > o l | | > n d | | > a s | | > l | | > \ | | > \| | > +----------------------------------+ >=20 > * Section "5. Example SIP CLF Record" >=20 > Remember to change "Due to internet-draft conventions" into "Due to = RFC conventions" when published (and also "to format it for an RFC" = later on...). >=20 > * =46rom the DataTracker ID Nits check tool (References Nits): >=20 > =3D=3D Unused Reference: 'RFC5612' is defined on line 984, but no = explicit > reference was found in the text >=20 > ** Downref: Normative reference to an Informational draft: > draft-ietf-sipclf-problem-statement (ref. > 'I-D.ietf-sipclf-problem-statement') >=20 > Comment: the document shepard is aware and has a solution for these = nits. Just apply it. >=20 > = --------------------------------------------------------------------------= ---- > Claudio Allocchio G A R R = Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=3DClaudio; = S=3DAllocchio; > fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr;= C=3Dit; >=20 > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --Apple-Mail-4-857016233 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Claudio Allocchio = <Claudio.Allocchio@garr.it>= ;
Date: January 19, 2012 5:21:29 AM EST
Subject: AppsDir review = of draft-ietf-sipclf-format-05


I have = been selected as the Applications Area Directorate reviewer for this = draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate).

Please resolve these comments along with any other = Last Call comments you may receive. Please wait for direction from your = document shepherd or AD before posting a new version of the = draft.

Document: draft-ietf-sipclf-format-05
Title: Format for = the Session Initiation Protocol (SIP) Common Log Format
=       (CLF)
Reviewer: Claudio = Allocchio
Review Date: 2012-01-18
IETF Last Call Date: = unknown
IESG Telechat Date: unknown

NOTE: is there is an IESG = telechat which I'm missing, just copy this messae to iesg = ML!

Summary:

This draft is ready for publication as a = Proposed Standard RFC; it just needs one consideration about a minor = issue about an external reference, and fixing some Nits.

Major = Issues:

NONE

Minor Issues:

just one !

* = Section "3. Document Conventions"

The authors have decided "For = the sake of clarity and completeness" to quote a full section of RFC4475 = into this document. However there were quite long discussions in the = Apps Dir in other reviews if this quoting practice is appropriate or = not, because it can lead to discrepacies, when the quoted document is = updated or obsoleted, resuing in confusion for the readers who just = trust the quoted text without checking the state of the referenced = document. I would suggest, as in the other cases, NOT to quote the = external text, but to use an explicit external reference only, urging = the reader to check that "for the sake of = clarity".

Nits:

* Section "Copyright Notice"

change = the year to 2012.

* Section "3. Document = Conventions"

remember to change "formatting rules for = Internet-Drafts" into "formatting rules for RFCs" when = published.

* Section "4. Format"

I do understand that it = probably does not fit into the I-D formatting line lenghts, but... maybe = an attempt to add aside the SIP CLF record depicted in Figure 1 the = grouping described as

=             &n= bsp;           &nbs= p;       <IndexPointers>
=             &n= bsp;           &nbs= p;       <MandatoryFields>
=             &n= bsp;           &nbs= p;       <OptionalFields>

= in the figure 1 itself (on the left?) may help in reading the = distinction, and maybe may even not require to repeat portions of the = figure itself later in the I-D, like in figure 3, figure 4 and figure 5. = It is really a nit and just a suggestion. Not really = important.

What I am suggesting:

=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
  P =   | =             &n= bsp;           &nbs= p;        |
  o =   | =             &n= bsp;           &nbs= p;        |
I i =   | =             &n= bsp;           &nbs= p;        |
n n =   | =             &n= bsp;           &nbs= p;        |
d t =   | =             &n= bsp;           &nbs= p;        |
e e =   | =             &n= bsp;           &nbs= p;        |
x r =   | =             &n= bsp;           &nbs= p;        |
  s =   | =             &n= bsp;           &nbs= p;        |
=    \  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
M =     | =             &n= bsp;           &nbs= p;        |
a F =   | =             &n= bsp;           &nbs= p;        |
n i =   | =             &n= bsp;           &nbs= p;        |
d e =   | =             &n= bsp;           &nbs= p;        |
a l =   | =             &n= bsp;           &nbs= p;        |
t d =   | =             &n= bsp;           &nbs= p;        |
o s =   | =             &n= bsp;           &nbs= p;        |
r =     | =             &n= bsp;           &nbs= p;        |
y  \ =  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
O =     | =             &n= bsp;           &nbs= p;        |
p F =   | =             &n= bsp;           &nbs= p;        |
t i =   | =             &n= bsp;           &nbs= p;        |
i e =   | =             &n= bsp;           &nbs= p;        |
o l =   | =             &n= bsp;           &nbs= p;        |
n d =   | =             &n= bsp;           &nbs= p;        |
a s =   | =             &n= bsp;           &nbs= p;        |
l =     | =             &n= bsp;           &nbs= p;        |
=    \  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+
* Section "5. Example SIP CLF Record"

Remember to change = "Due to internet-draft conventions" into "Due to RFC conventions" when = published (and also "to format it for an RFC" later on...).

* = =46rom the DataTracker ID Nits check tool (References Nits):

=  =3D=3D Unused Reference: 'RFC5612' is defined on line 984, but no = explicit
    reference was found in the = text

 ** Downref: Normative reference to an Informational = draft:
    draft-ietf-sipclf-problem-statement = (ref.
=     'I-D.ietf-sipclf-problem-statement')

Commen= t: the document shepard is aware and has a solution for these nits. Just = apply = it.

---------------------------------------------------------------= ---------------
Claudio Allocchio =             G =   A   R   R =          Claudio.Allocchio@garr.it =             &n= bsp;          Senior = Technical Officer
tel: +39 040 3758523 =      Italian Academic and =       G=3DClaudio; S=3DAllocchio;
fax: = +39 040 3758565        Research = Network         P=3Dgarr; = A=3Dgarr; C=3Dit;

=           PGP Key: http://www.cert.garr.it/= PGP/keys.php3#ca

= --Apple-Mail-4-857016233-- From musgravepj@gmail.com Fri Jan 20 02:50:22 2012 Return-Path: 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 A8A6721F8615 for ; Fri, 20 Jan 2012 02:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gkCHSUbooOAE for ; Fri, 20 Jan 2012 02:50:21 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A57EE21F860E for ; Fri, 20 Jan 2012 02:50:21 -0800 (PST) Received: by qabj34 with SMTP id j34so261035qab.10 for ; Fri, 20 Jan 2012 02:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NU3LRooRzdJpYrKR+zP83sdMjeHOpbMJ+yAkwRdCt6o=; b=N9UKfsj+yApNEgNM0a0Mw6u2V1vSK66qTVjnMsZXJJIcQY3vrGyhhmm/JRQCwo0+Gk iZHwbfSg0/4u7m51sxhMuxJCS+XGPy/AiYo0/UucQazauKH0SoxIP5qikyi5wjm9Uvc4 HC2qCPa67qiSJ7QJJDw1hriaJpRB0lwzttFh0= Received: by 10.224.177.132 with SMTP id bi4mr31655753qab.79.1327056621267; Fri, 20 Jan 2012 02:50:21 -0800 (PST) Received: from [192.168.1.105] ([204.237.33.112]) by mx.google.com with ESMTPS id q14sm5873160qap.4.2012.01.20.02.50.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:50:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Fri, 20 Jan 2012 05:50:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <212E7733-3FF6-47D4-A3E3-65471F677A25@standardstrack.com> To: Burger Eric X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org Mailing" , Saint-Andre Peter Subject: Re: [sip-clf] International Oops in sipclf Problem Statement X-BeenThere: sip-clf@ietf.org 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: Fri, 20 Jan 2012 10:50:22 -0000 Makes sense to me.=20 Ooops indeed! Thanks,=20 Peter (as individual) On 2012-01-18, at 8:08 PM, Burger Eric wrote: > The current text says SIPCLF fields are ASCII. However, as we know, = SIP fields are UTF-8. We propose changing all instances of ASCII in the = document with UTF-8. Same for the sipclf-format document. This is an = awesome catch by Peter Saint-Andre. >=20 > Our guess is that most of you read octets and write octets. Rendering = programs will not quite work if an extended UTF-8 character pops up, but = that should be easy to fix. >=20 > Anyone disagree? >=20 > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf From rjsparks@nostrum.com Thu Jan 26 15:10:00 2012 Return-Path: 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 DE33721F8646 for ; Thu, 26 Jan 2012 15:09:59 -0800 (PST) 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 GvOr5aFgjfD8 for ; Thu, 26 Jan 2012 15:09:55 -0800 (PST) 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 17CA721F863D for ; Thu, 26 Jan 2012 15:09:55 -0800 (PST) Received: from unexplicable.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0QN9onu002816 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 17:09:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F21DD3E.7000002@nostrum.com> Date: Thu, 26 Jan 2012 17:09:50 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "sip-clf@ietf.org Mailing" , sipclf-chairs@tools.ietf.org, draft-ietf-sipclf-format@tools.ietf.org, Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 23:10:00 -0000 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) 1) The version string claims it is hexadecimal encoded. The version for this document is expressed by the character A. Does that mean this is version 10 (base 10)? Are we limited to versions 10 through 15? (we only have one byte and section 6 points out that index lines always start with an alphabetical character). This description needs to be clarified. While you're looking at it, consider discussing whether a given log file can have records with different versions in it. 2) The description of Timestamp and Fractional Seconds is very confusing. What does it mean to be represented in big-endian fashion with a most significant octet and to be decimal encoded? It's very far from clear that you intend this to be an ascii string representing an integer, and it's not clear that you intend that it to be prefix-padded with 0s if necessary. Did the group consider using ABNF to describe these fields (or the whole log record) to avoid this kind of ambiguity? 3) The document should be clear about whether the flags field values are extensible, and if so, how extension is expected to be managed. How will you handle SIP received over DCCP, Websockets, or something we haven't heard of yet? 4) Section 4.2 speaks of placing "the actual values for the mandatory fields" into the record. It's not clear what "actual values" means. There are other sections of the document that talk about transforming (escaping) values before putting them in the log record, including dealing with tabs and edge conditions like field that has only a question mark in it. The concept of encoding and escaping needs to be much clearer throughout the document. 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). 6) There are a couple of places where you talk about escaping '-' and '?' characters. The document should note that this could produce a logged record that is not syntactically parsible with a SIP parser (quoted-pair is only used in certain places in SIP messages). There should also be some discussion about whether a log reader unescapes anything. 7) Why does Tag -01 restrict message bodies to just the listed types, especially with the open ended "miscellaneous text content" type category? If there's a real restriction here, it needs to be much more clearly stated. Why are you allowing any LWS for the separator between the content type header field value and the message body itself? Why isn't this simply a space? It is not clear what "byte encoded" means for representing binary bodies - do you mean expanding it into a hex representation, a uuencode representation, or soemthing else? 8) There's no description of Tag-02. The text following the line that starts the description of the tag speaks of more general things covering both tag-01 and tag-02. 9) When describing repeating tag-01 or tag-02 multiple times to deal with large entities, the document should be clear that the fragments get logged in order, and how to reassemble the actual entity. It should also say whether it's ok to interleave (for example) tag-01 fragements with other optional fields. 10) The description of the Length field in section 4.3 is ambiguous. It says "This length does not include the header shown in Figure 5." But figure 5 has nothing clearly identified as "the header". 11) Where does the document talk about how to log fields that are line folded in the original message? Is it ok for the logged field to contain CRLFs, or is the intent that the field be unfolded before logging? 12) It's not clear if the \r\n used in the examples of logging the SDP body are there as text-conventions for showing the example in an RFC, or if you intend that CRLFs be replaced by \r\n's when logging. If it's just a convention, please make it clear that the actual log record will have CRLFs. If you were expecting the CRLFs to be escaped in the log, there needs to be text that says that normatively somewhere, and you need to consider escaping the escape character. Minor There is a maintenance risk in having all the detail of each block duplicated in Figure 1. Please consider taking that figure up a level, showing the three blocks and how they're separated, and let the other figures show the internal detail. 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. In section 4.1, you talk of "a single, 52 character hexadecimal encoded string" between bytes 8 and 55. There are only 48 octets between bytes 8 and 55 (inclusive). Please adjust the text to note that you are also talking about the pointers to the optional fields or describe the shorter length. 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. There is a lot of descriptive text in 4.2's sections on the server and client transaction that is a copy of what's in the problem-statement/information model document. It would be better to just point to the description in the other document. Nits How is this a "functionally equivalent event logging mechanism"? Suggest replacing that sentence with the single word "analogous". In the introduction, the document claims to define a format that is no more difficult to generate, but it's not clear what it's being compared to. No more difficult than what? Section 4.1's description of Record Length can be misinterpreted. By listing a subset of the fields that are included, it leaves open whether any fields are excluded. It would be better to say "beginning with the Version octet and ending with the terminating line-feed". It would help to be more explicit that you are not logging the CRLF at the end of a given header field value. (Or is it an option for a logger to choose to do so?) Please consider scrubbing the message used in example 5 back to the minimal number of octets you need to make the example useful. In particular, consider removing elements that have not already been standardized. I'm surprised to see the literal strings "server-tx" and "client-tx" in the example log message. Was that what you really intended? The code snippet should be delineated as such, following the guidance in the TLP (see section 4.b of