From internet-drafts@ietf.org Thu Nov 8 00:58: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 92AA621F8654; Thu, 8 Nov 2012 00:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tUzKz3pXlCm; Thu, 8 Nov 2012 00:58:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8C21F86DE; Thu, 8 Nov 2012 00:58:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121108085832.23504.29554.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2012 00:58:32 -0800 Cc: sip-clf@ietf.org Subject: [sip-clf] I-D Action: draft-ietf-sipclf-format-08.txt 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, 08 Nov 2012 08:58:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Common Log Format Working Group of th= e IETF. Title : Format for the Session Initiation Protocol (SIP) Common = Log Format (CLF) Author(s) : Gonzalo Salgueiro Vijay Gurbani Adam Roach Filename : draft-ietf-sipclf-format-08.txt Pages : 30 Date : 2012-11-08 Abstract: The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipclf-format There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipclf-format-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Thu Nov 8 01:06:10 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 C99F821F8755 for ; Thu, 8 Nov 2012 01:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd4m8McArKv8 for ; Thu, 8 Nov 2012 01:06:10 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D680D21F872A for ; Thu, 8 Nov 2012 01:06:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.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 qA8969Qe010484 for ; Thu, 8 Nov 2012 04:06:09 -0500 (EST) Received: from rtp-vpn4-1095.cisco.com (rtp-vpn4-1095.cisco.com [10.82.212.71]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8968YQ016798; Thu, 8 Nov 2012 04:06:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Gonzalo Salgueiro In-Reply-To: <508706F9.1020507@nostrum.com> Date: Thu, 8 Nov 2012 04:06:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121005015620.22856.1399.idtracker@ietfa.amsl.com> <869FCF91-1032-4411-A7D5-85CEE6F120E5@cisco.com> <508706F9.1020507@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1283) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt 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, 08 Nov 2012 09:06:10 -0000 Robert -=20 I posted the -08 version of the SIPCLF Format draft addressing the issue = you raised. I used the definition of 'unprintable' worked out on the = mailing list with Adam Roach (many thanks to him for that). I believe = this closes all issues. Cheers, Gonzalo On Oct 23, 2012, at 5:07 PM, Robert Sparks wrote: > The list has been silent on this. It needs review and comment please. >=20 > There is one part of the new text that is not right yet. >=20 > " The Value field for the optional element being logged MUST be Base64 > encoded if it has any characters outside of the UTF-8 character = set." > doesn't make sense. >=20 > This should be saying something like "if it contains any octets with = values between 0 and 31 inclusive, or 127". >=20 > RjS >=20 > On 10/4/12 9:13 PM, Gonzalo Salgueiro wrote: >> Folks: >>=20 >> I have posted the -07 version of the SIP CLF Format Draft and it is = now in the archives at [1]. >>=20 >> This draft was meant to address the few remaining AD review items = that were raised. The diffs between the -06 and the -07 versions are at = [2] >>=20 >> The principal changes include: >>=20 >> - Introduced Base64 Encoded Byte (BEB) to deal with optional logging = of non-UTF-8 message bodies >> - Added an example using BEB for logging a binary body >> - Clarified and expanded the text dealing with encoding, character = escaping, and usage of SIP CLF and put it all into its own section >> - Addressed several minor issues and nits >> =20 >> [1]=20 >> http://tools.ietf.org/html/draft-ietf-sipclf-format >>=20 >> [2]=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-07 >>=20 >>=20 >> Regards, >>=20 >> Gonzalo >>=20 >> On Mar 12, 2012, at 3:13 PM,=20 >> Internet-Drafts@ietf.org >> wrote: >>=20 >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the SIP Common Log Format = Working Group of the IETF. >>>=20 >>> Title : Format for the Session Initiation Protocol = (SIP) Common Log Format (CLF) >>> Author(s) : Gonzalo Salgueiro >>> Vijay Gurbani >>> Adam Roach >>> Filename : draft-ietf-sipclf-format-06.txt >>> Pages : 28 >>> Date : 2012-03-12 >>>=20 >>> The SIPCLF Workgroup has defined a common log format framework for >>> Session Initiation Protocol (SIP) servers. This common log format >>> mimics the successful event logging format found in well-known web >>> servers like Apache and web proxies like Squid. This document >>> proposes an indexed text encoding format for the SIP Common Log >>> Format (CLF) that retains the key advantages of a text-based = format, >>> while significantly increasing processing performance over a = purely >>> text-based implementation. This file format adheres to the SIP = CLF >>> data model and provides an effective encoding scheme for all >>> mandatory and optional fields that appear in a SIP CLF record. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>>=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> This Internet-Draft can be retrieved at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>>=20 >>>=20 >>> _______________________________________________ >>> sip-clf mailing list >>>=20 >>> sip-clf@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-clf >>>=20 >>>=20 >>>=20 >>=20 >> On Oct 4, 2012, at 9:56 PM,=20 >> Internet-Drafts@ietf.org >> wrote: >>=20 >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the SIP Common Log Format Working Group = of the IETF. >>>=20 >>> Title : Format for the Session Initiation Protocol = (SIP) Common Log Format (CLF) >>> Author(s) : Gonzalo Salgueiro >>> Vijay Gurbani >>> Adam Roach >>> Filename : draft-ietf-sipclf-format-07.txt >>> Pages : 30 >>> Date : 2012-10-04 >>>=20 >>> Abstract: >>> The SIPCLF Workgroup has defined a common log format framework for >>> Session Initiation Protocol (SIP) servers. This common log format >>> mimics the successful event logging format found in well-known web >>> servers like Apache and web proxies like Squid. This document >>> proposes an indexed text encoding format for the SIP Common Log >>> Format (CLF) that retains the key advantages of a text-based = format, >>> while significantly increasing processing performance over a = purely >>> text-based implementation. This file format adheres to the SIP = CLF >>> data model and provides an effective encoding scheme for all >>> mandatory and optional fields that appear in a SIP CLF record. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-sipclf-format >>>=20 >>>=20 >>> There's also a htmlized version available at: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-sipclf-format-07 >>>=20 >>>=20 >>> A diff from the previous version is available at: >>>=20 >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-07 >>>=20 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>>=20 >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>=20 >>> Internet-Draft directories:=20 >>> http://www.ietf.org/shadow.html >>>=20 >>> or=20 >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>>=20 >>>=20 >=20 From gsalguei@cisco.com Thu Nov 8 01:09:26 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 EB22F21F872A for ; Thu, 8 Nov 2012 01:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogo03CdN2GM6 for ; Thu, 8 Nov 2012 01:09:25 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE121F868F for ; Thu, 8 Nov 2012 01:09:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.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 qA899JnN010782 for ; Thu, 8 Nov 2012 04:09:19 -0500 (EST) Received: from rtp-vpn4-1095.cisco.com (rtp-vpn4-1095.cisco.com [10.82.212.71]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA899F3e019324; Thu, 8 Nov 2012 04:09:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Gonzalo Salgueiro In-Reply-To: <677D295A-BF44-490A-86C1-48C0472E6F58@gmail.com> Date: Thu, 8 Nov 2012 04:09:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26F322DA-8642-4CA7-B86F-4D9092AAE971@cisco.com> References: <20121005015620.22856.1399.idtracker@ietfa.amsl.com> <869FCF91-1032-4411-A7D5-85CEE6F120E5@cisco.com> <50870CB8.40908@nostrum.com> <5A63A1D1-5D2A-4EA8-9E7A-CDA3C9668DE5@cisco.com> <508719B1.4090108@nostrum.com> <2771A52D-9AE5-460F-A896-888AB334153C@cisco.com> <50883BAB.9070501@nostrum.com> <5885B8A1-2BB7-4A0D-879A-4739D41EB356@cisco.com> <677D295A-BF44-490A-86C1-48C0472E6F58@gmail.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1283) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt 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, 08 Nov 2012 09:09:27 -0000 Thanks for the review, Peter. The new -08 has been posted and can be = used for the shepherd write up. Cheers, Gonzalo On Oct 28, 2012, at 6:29 PM, Peter Musgrave wrote: > > Ok - I know less about UTF-8 than either Adam or Gonzalo, but the = rationale of being able to use text base tools is one I support.=20 >=20 > I read through the diffs and did not find anything else I wanted to = bring up.=20 > >=20 > > Once we agree on "printable" is there anything else people want to see = altered? > >=20 > Thanks,=20 >=20 > Peter >=20 > One nit:=20 > 4.3 s/macine/machine/ >=20 >=20 > On 2012-10-24, at 7:41 PM, Gonzalo Salgueiro = wrote: >=20 >> Thanks, Adam. I agree with both your assumptions. I think where we = diverged is whether C1 was on an equal footing with C0 as far as their = 'unprintability'. If C1 is handled nicely by text processing tools then = we can omit them. We all have a vested interest in minimizing the amount = we Base64 encode these optionally logged bodies and whole messages = within SIP CLF since it drastically reduces its usefulness and can = introduce information loss. Thus, I absolutely agree that we don't want = an accented Latin character or other valid UTF-8 non-control characters = (CJK/Cyrillic/Arabic/etc) to trigger a Base64 encoding. At this point I = think I will go with your original text for defining 'unprintable' = within the context of this document. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>=20 >> On Oct 24, 2012, at 3:04 PM, Adam Roach wrote: >>=20 >>> So, I think I understand your point. (And, to be clear, I don't = intend to hold myself out as a Unicode expert either). The rationale = behind what I'm proposing has two main assumptions: >>> =95 The whole point of choosing a non-binary record format is = allowing the use of commandline tools to work with records. Legacy = commandline tools will frequently make assumptions about what octetes = that correspond to ASCII control characters mean (e.g. 10 and 13), and = take certain actions based on them. By and large, I wouldn't expect the = same kind of reaction to octetes that represent extended control = characters, like those in the C1 set. I would expect normal commandline = tools to simply treat octets in the range of 128-255 as (relatively) = non-special, and process them normally. Cursory experimentation with the = commandline tools I have easily available leads me to believe that such = is the case. >>>=20 >>> =95 I presume that we do not want to force Base-64 encoding due = to the simple presence of an accented Latin character. Similarly, we = probably don't want a small number of characters from the = CJK/Cyrillic/Arabic/etc codepages to trigger Base-64 either.=20 >>> If I'm wrong about either of these assumptions, then we need to = re-visit what I'm proposing. >>>=20 >>> /a >>>=20 >>>=20 >>> On 10/24/12 1:30 AM, Gonzalo Salgueiro wrote: >>>> Adam - >>>>=20 >>>> Let me first state that I'm certainly no expert in UTF-8 and will = happily defer to you on this. I certainly get your point about octets = versus characters, especially since UTF-8 allows for multi-byte = characters. When I made the statement "outside the UTF-8 character = range" I was referring to the discrete set of characters from U+0000 to = U+7FFFFFFF (or U+10FFFF if using the restricted RFC 3629 definition). I = assumed this was a clearly bounded set. >>>>=20 >>>> To be clear, my only intent was to expand your original definition = of 'unprintable' beyond the C0 control codes (U+0000 to U+001F, U+007F) = to also include the well known C1 control codes (U+0080 to U+009F). To = avoid confusion, I should have used the Unicode code point notation. I = certainly don't want to try and go down the road of specifying what = characters are 'printable', but I thought C1 control codes were worth = stating explicitly in the same way you did C0 control codes. Your = original definition seemed unnecessarily restrictive since the C1 = control codes, for example, are not printable but are certainly a valid = UTF-8 sequence of octets greater than or equal to 128. Does that make = sense? >>>>=20 >>>> If you think your original definition of 'unprintable' is broad = enough, then I will use that. >>>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>> On Oct 23, 2012, at 6:26 PM, Adam Roach wrote: >>>>=20 >>>>=20 >>>>> On 10/23/12 16:56, Oct 23, Gonzalo Salgueiro wrote: >>>>>=20 >>>>>> "For the purposes of this document, we define 'unprintable' to = mean a string of octets that: (a) contains an octet with a value in the = range of 0 to 31, inclusive; (b) contains an octet with a value of 127, = (c) contains any octet greater than or equal to 128 which is a = formatting or control character (such as 128 to 159) within the UTF-8 = character set; or (d) falls outside the UTF-8 character range, as = specified by [UNICODE]." >>>>>>=20 >>>>>> Does that sound ok? >>>>>>=20 >>>>> I think we're still talking past each other here. >>>>>=20 >>>>> "Outside the UTF-8 character range" simply isn't a sensible thing = to say. What we're talking about putting into a log record is a series = of *octets*, not a series of *characters*. UTF-8 is an encoding that = defines how octets are put together to make characters. >>>>>=20 >>>>> Once you start talking about the octets as if they *are* = characters, you're conflating two very different things. So, for = example, you can't talk about "a string of octets that... falls outside = the UTF-8 character range." >>>>>=20 >>>>> You can talk about a string of bytes that does not form a valid = UTF-8 sequence, and that's almost certainly what you want to say here. >>>>>=20 >>>>> I'm also getting a bit lost in what you mean when you say "which = is a formatting or control character (such as 128 to 159)." Keep in mind = that we're still talking about *octets* here, not characters. In UTF-8, = there's nothing special about an octet with a value of 128. There's = nothing special about an octet with a value of 159. Both can appear as = the second octet in a two-octet character. Or the second or third octet = in a three-octet character. And so on. The same goes for everything = between 128 and 191. >>>>>=20 >>>>> Now, octet values of 192, 193, and 245-255 won't appear in valid = UTF-8. If we wanted to be abundantly careful, we could call those out as = being invalid. But I think we catch those just fine if we talk about = octets that form valid UTF-8 sequences. >>>>>=20 >>>>> Or are you meaning to call out UTF-8 code points like U+0080 (the = Latin-1 padding character)? Because that has nothing to do with an = *octet* with a value of 128. It would be encoded as a two-octet sequence = starting with 194. However, if we're intending to go down the rabbit = hole of making decisions about whether to Base-64 encode based on which = UTF-8 codepoints we want to consider "printable," then we've got years = of draft refinement ahead of us (I can already imagine the right-to-left = mark arguments). That way lies madness. >>>>>=20 >>>>> All of which is a very long winded way to say: octets are not = characters and characters are not octets; and you need to write the text = in a way that does not mix them with each other. >>>>>=20 >>>>> /a >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> sip-clf mailing list >> sip-clf@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-clf >=20 >=20 From internet-drafts@ietf.org Thu Nov 8 12:18: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 232C521F87EF; Thu, 8 Nov 2012 12:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eg5LQOLLFSp; Thu, 8 Nov 2012 12:17:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE26521F86D3; Thu, 8 Nov 2012 12:17:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121108201740.16251.37845.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2012 12:17:40 -0800 Cc: sip-clf@ietf.org Subject: [sip-clf] I-D Action: draft-ietf-sipclf-format-09.txt 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, 08 Nov 2012 20:18:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Common Log Format Working Group of th= e IETF. Title : Format for the Session Initiation Protocol (SIP) Common = Log Format (CLF) Author(s) : Gonzalo Salgueiro Vijay Gurbani Adam Roach Filename : draft-ietf-sipclf-format-09.txt Pages : 30 Date : 2012-11-08 Abstract: The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipclf-format There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipclf-format-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Thu Nov 8 12:29:13 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 5965521F88F4 for ; Thu, 8 Nov 2012 12:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4CXYJazqVLS for ; Thu, 8 Nov 2012 12:29:12 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3140221F88DD for ; Thu, 8 Nov 2012 12:29:12 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.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 qA8KTBh5018011 for ; Thu, 8 Nov 2012 15:29:11 -0500 (EST) Received: from rtp-vpn5-771.cisco.com (rtp-vpn5-771.cisco.com [10.82.235.6]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8KTAMm015312; Thu, 8 Nov 2012 15:29:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Gonzalo Salgueiro In-Reply-To: <26F322DA-8642-4CA7-B86F-4D9092AAE971@cisco.com> Date: Thu, 8 Nov 2012 15:29:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19BA0235-F7D5-4FAE-9D4B-6F008A22A1A6@cisco.com> References: <20121005015620.22856.1399.idtracker@ietfa.amsl.com> <869FCF91-1032-4411-A7D5-85CEE6F120E5@cisco.com> <50870CB8.40908@nostrum.com> <5A63A1D1-5D2A-4EA8-9E7A-CDA3C9668DE5@cisco.com> <508719B1.4090108@nostrum.com> <2771A52D-9AE5-460F-A896-888AB334153C@cisco.com> <50883BAB.9070501@nostrum.com> <5885B8A1-2BB7-4A0D-879A-4739D41EB356@cisco.com> <677D295A-BF44-490A-86C1-48C0472E6F58@gmail.com> <26F322DA-8642-4CA7-B86F-4D9092AAE971@cisco.com> To: Peter Musgrave , Robert Sparks X-Mailer: Apple Mail (2.1283) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt 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, 08 Nov 2012 20:29:13 -0000 Peter -=20 I just posted an -09 where the *only* change was to remove a paragraph = from the IANA Considerations section that Robert mentioned was = problematic given the RFC 5226 designations already utilized in that = section. A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-09 This version is the now ready for IETF LC. Cheers, Gonzalo On Nov 8, 2012, at 4:09 AM, Gonzalo Salgueiro wrote: > Thanks for the review, Peter. The new -08 has been posted and can be = used for the shepherd write up. >=20 > Cheers, >=20 > Gonzalo >=20 > On Oct 28, 2012, at 6:29 PM, Peter Musgrave wrote: >=20 >> >> Ok - I know less about UTF-8 than either Adam or Gonzalo, but the = rationale of being able to use text base tools is one I support.=20 >>=20 >> I read through the diffs and did not find anything else I wanted to = bring up.=20 >> >>=20 >> >> Once we agree on "printable" is there anything else people want to = see altered? >> >>=20 >> Thanks,=20 >>=20 >> Peter >>=20 >> One nit:=20 >> 4.3 s/macine/machine/ >>=20 >>=20 >> On 2012-10-24, at 7:41 PM, Gonzalo Salgueiro = wrote: >>=20 >>> Thanks, Adam. I agree with both your assumptions. I think where we = diverged is whether C1 was on an equal footing with C0 as far as their = 'unprintability'. If C1 is handled nicely by text processing tools then = we can omit them. We all have a vested interest in minimizing the amount = we Base64 encode these optionally logged bodies and whole messages = within SIP CLF since it drastically reduces its usefulness and can = introduce information loss. Thus, I absolutely agree that we don't want = an accented Latin character or other valid UTF-8 non-control characters = (CJK/Cyrillic/Arabic/etc) to trigger a Base64 encoding. At this point I = think I will go with your original text for defining 'unprintable' = within the context of this document. >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On Oct 24, 2012, at 3:04 PM, Adam Roach wrote: >>>=20 >>>> So, I think I understand your point. (And, to be clear, I don't = intend to hold myself out as a Unicode expert either). The rationale = behind what I'm proposing has two main assumptions: >>>> =95 The whole point of choosing a non-binary record format is = allowing the use of commandline tools to work with records. Legacy = commandline tools will frequently make assumptions about what octetes = that correspond to ASCII control characters mean (e.g. 10 and 13), and = take certain actions based on them. By and large, I wouldn't expect the = same kind of reaction to octetes that represent extended control = characters, like those in the C1 set. I would expect normal commandline = tools to simply treat octets in the range of 128-255 as (relatively) = non-special, and process them normally. Cursory experimentation with the = commandline tools I have easily available leads me to believe that such = is the case. >>>>=20 >>>> =95 I presume that we do not want to force Base-64 encoding due = to the simple presence of an accented Latin character. Similarly, we = probably don't want a small number of characters from the = CJK/Cyrillic/Arabic/etc codepages to trigger Base-64 either.=20 >>>> If I'm wrong about either of these assumptions, then we need to = re-visit what I'm proposing. >>>>=20 >>>> /a >>>>=20 >>>>=20 >>>> On 10/24/12 1:30 AM, Gonzalo Salgueiro wrote: >>>>> Adam - >>>>>=20 >>>>> Let me first state that I'm certainly no expert in UTF-8 and will = happily defer to you on this. I certainly get your point about octets = versus characters, especially since UTF-8 allows for multi-byte = characters. When I made the statement "outside the UTF-8 character = range" I was referring to the discrete set of characters from U+0000 to = U+7FFFFFFF (or U+10FFFF if using the restricted RFC 3629 definition). I = assumed this was a clearly bounded set. >>>>>=20 >>>>> To be clear, my only intent was to expand your original definition = of 'unprintable' beyond the C0 control codes (U+0000 to U+001F, U+007F) = to also include the well known C1 control codes (U+0080 to U+009F). To = avoid confusion, I should have used the Unicode code point notation. I = certainly don't want to try and go down the road of specifying what = characters are 'printable', but I thought C1 control codes were worth = stating explicitly in the same way you did C0 control codes. Your = original definition seemed unnecessarily restrictive since the C1 = control codes, for example, are not printable but are certainly a valid = UTF-8 sequence of octets greater than or equal to 128. Does that make = sense? >>>>>=20 >>>>> If you think your original definition of 'unprintable' is broad = enough, then I will use that. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>> On Oct 23, 2012, at 6:26 PM, Adam Roach wrote: >>>>>=20 >>>>>=20 >>>>>> On 10/23/12 16:56, Oct 23, Gonzalo Salgueiro wrote: >>>>>>=20 >>>>>>> "For the purposes of this document, we define 'unprintable' to = mean a string of octets that: (a) contains an octet with a value in the = range of 0 to 31, inclusive; (b) contains an octet with a value of 127, = (c) contains any octet greater than or equal to 128 which is a = formatting or control character (such as 128 to 159) within the UTF-8 = character set; or (d) falls outside the UTF-8 character range, as = specified by [UNICODE]." >>>>>>>=20 >>>>>>> Does that sound ok? >>>>>>>=20 >>>>>> I think we're still talking past each other here. >>>>>>=20 >>>>>> "Outside the UTF-8 character range" simply isn't a sensible thing = to say. What we're talking about putting into a log record is a series = of *octets*, not a series of *characters*. UTF-8 is an encoding that = defines how octets are put together to make characters. >>>>>>=20 >>>>>> Once you start talking about the octets as if they *are* = characters, you're conflating two very different things. So, for = example, you can't talk about "a string of octets that... falls outside = the UTF-8 character range." >>>>>>=20 >>>>>> You can talk about a string of bytes that does not form a valid = UTF-8 sequence, and that's almost certainly what you want to say here. >>>>>>=20 >>>>>> I'm also getting a bit lost in what you mean when you say "which = is a formatting or control character (such as 128 to 159)." Keep in mind = that we're still talking about *octets* here, not characters. In UTF-8, = there's nothing special about an octet with a value of 128. There's = nothing special about an octet with a value of 159. Both can appear as = the second octet in a two-octet character. Or the second or third octet = in a three-octet character. And so on. The same goes for everything = between 128 and 191. >>>>>>=20 >>>>>> Now, octet values of 192, 193, and 245-255 won't appear in valid = UTF-8. If we wanted to be abundantly careful, we could call those out as = being invalid. But I think we catch those just fine if we talk about = octets that form valid UTF-8 sequences. >>>>>>=20 >>>>>> Or are you meaning to call out UTF-8 code points like U+0080 (the = Latin-1 padding character)? Because that has nothing to do with an = *octet* with a value of 128. It would be encoded as a two-octet sequence = starting with 194. However, if we're intending to go down the rabbit = hole of making decisions about whether to Base-64 encode based on which = UTF-8 codepoints we want to consider "printable," then we've got years = of draft refinement ahead of us (I can already imagine the right-to-left = mark arguments). That way lies madness. >>>>>>=20 >>>>>> All of which is a very long winded way to say: octets are not = characters and characters are not octets; and you need to write the text = in a way that does not mix them with each other. >>>>>>=20 >>>>>> /a >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> sip-clf mailing list >>> sip-clf@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-clf >>=20 >>=20 >=20 > _______________________________________________ > sip-clf mailing list > sip-clf@ietf.org > https://www.ietf.org/mailman/listinfo/sip-clf >=20 From musgravepj@gmail.com Thu Nov 8 14:12: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 CE95821F853B for ; Thu, 8 Nov 2012 14:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OScUcZWHM90B for ; Thu, 8 Nov 2012 14:12:32 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7E21F85B6 for ; Thu, 8 Nov 2012 14:12:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so5574172iec.31 for ; Thu, 08 Nov 2012 14:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=L8X0awZuKsW4govmGW8l+2sGU8+YJijkJWsyz0NWWD4=; b=bXzVRGRyxdI//Ez3yvnx/Y4qaeXLyQ9CcciN/SgeQjdNv9vXHqRvrtsqDeUJW2ftMw jHVutvlLV/t6cCUejCmr1AWB2Eod6+sDIXXzg7CvJjSNeW80D/aonEwlehKEFvc2nuCa PLJGR5kA8tIGNTnOhWhTEH6Zt/YzzVZavA1Xo75b0+t1+nzk++qE/3rE5kJq/ZlWFN9F 7sxP69vB3oMcgJvK9cL0TUyZn/dXwQK5aOO0AcjIK0V0zvXhvbOu7xfouaxAOS1rRPG3 hXuz+k0kyMRo1a/+KIFd18itZVuobfYwXiSL23PsRbkfFhrvKNqHt0TeZzNj8tnpQRzF 8j9w== Received: by 10.42.176.194 with SMTP id bf2mr8508313icb.50.1352412752302; Thu, 08 Nov 2012 14:12:32 -0800 (PST) Received: from [192.168.1.108] ([204.237.33.112]) by mx.google.com with ESMTPS id xn10sm5422462igb.4.2012.11.08.14.12.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 14:12:31 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Musgrave In-Reply-To: <19BA0235-F7D5-4FAE-9D4B-6F008A22A1A6@cisco.com> Date: Thu, 8 Nov 2012 17:12:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <730A5C4C-51AE-4E07-A9CE-7A8D8BA4F3D9@gmail.com> References: <20121005015620.22856.1399.idtracker@ietfa.amsl.com> <869FCF91-1032-4411-A7D5-85CEE6F120E5@cisco.com> <50870CB8.40908@nostrum.com> <5A63A1D1-5D2A-4EA8-9E7A-CDA3C9668DE5@cisco.com> <508719B1.4090108@nostrum.com> <2771A52D-9AE5-460F-A896-888AB334153C@cisco.com> <50883BAB.9070501@nostrum.com> <5885B8A1-2BB7-4A0D-879A-4739D41EB356@cisco.com> <677D295A-BF44-490A-86C1-48C0472E6F58@gmail.com> <26F322DA-8642-4CA7-B86F-4D9092AAE971@cisco.com> <19BA0235-F7D5-4FAE-9D4B-6F008A22A1A6@cisco.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.1499) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt 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, 08 Nov 2012 22:12:33 -0000 Ok.=20 I will check and then update the writeup and issue.=20 I will also issue the data model writeup so both can go forward.=20 Peter On 2012-11-08, at 3:29 PM, Gonzalo Salgueiro wrote: > Peter -=20 >=20 > I just posted an -09 where the *only* change was to remove a paragraph = from the IANA Considerations section that Robert mentioned was = problematic given the RFC 5226 designations already utilized in that = section. >=20 > A diff from the previous version is available at: >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-09 >=20 > This version is the now ready for IETF LC. >=20 >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On Nov 8, 2012, at 4:09 AM, Gonzalo Salgueiro wrote: >=20 >> Thanks for the review, Peter. The new -08 has been posted and can be = used for the shepherd write up. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >> On Oct 28, 2012, at 6:29 PM, Peter Musgrave wrote: >>=20 >>> >>> Ok - I know less about UTF-8 than either Adam or Gonzalo, but the = rationale of being able to use text base tools is one I support.=20 >>>=20 >>> I read through the diffs and did not find anything else I wanted to = bring up.=20 >>> >>>=20 >>> >>> Once we agree on "printable" is there anything else people want to = see altered? >>> >>>=20 >>> Thanks,=20 >>>=20 >>> Peter >>>=20 >>> One nit:=20 >>> 4.3 s/macine/machine/ >>>=20 >>>=20 >>> On 2012-10-24, at 7:41 PM, Gonzalo Salgueiro = wrote: >>>=20 >>>> Thanks, Adam. I agree with both your assumptions. I think where we = diverged is whether C1 was on an equal footing with C0 as far as their = 'unprintability'. If C1 is handled nicely by text processing tools then = we can omit them. We all have a vested interest in minimizing the amount = we Base64 encode these optionally logged bodies and whole messages = within SIP CLF since it drastically reduces its usefulness and can = introduce information loss. Thus, I absolutely agree that we don't want = an accented Latin character or other valid UTF-8 non-control characters = (CJK/Cyrillic/Arabic/etc) to trigger a Base64 encoding. At this point I = think I will go with your original text for defining 'unprintable' = within the context of this document. >>>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>>=20 >>>> On Oct 24, 2012, at 3:04 PM, Adam Roach wrote: >>>>=20 >>>>> So, I think I understand your point. (And, to be clear, I don't = intend to hold myself out as a Unicode expert either). The rationale = behind what I'm proposing has two main assumptions: >>>>> =95 The whole point of choosing a non-binary record format is = allowing the use of commandline tools to work with records. Legacy = commandline tools will frequently make assumptions about what octetes = that correspond to ASCII control characters mean (e.g. 10 and 13), and = take certain actions based on them. By and large, I wouldn't expect the = same kind of reaction to octetes that represent extended control = characters, like those in the C1 set. I would expect normal commandline = tools to simply treat octets in the range of 128-255 as (relatively) = non-special, and process them normally. Cursory experimentation with the = commandline tools I have easily available leads me to believe that such = is the case. >>>>>=20 >>>>> =95 I presume that we do not want to force Base-64 encoding due = to the simple presence of an accented Latin character. Similarly, we = probably don't want a small number of characters from the = CJK/Cyrillic/Arabic/etc codepages to trigger Base-64 either.=20 >>>>> If I'm wrong about either of these assumptions, then we need to = re-visit what I'm proposing. >>>>>=20 >>>>> /a >>>>>=20 >>>>>=20 >>>>> On 10/24/12 1:30 AM, Gonzalo Salgueiro wrote: >>>>>> Adam - >>>>>>=20 >>>>>> Let me first state that I'm certainly no expert in UTF-8 and will = happily defer to you on this. I certainly get your point about octets = versus characters, especially since UTF-8 allows for multi-byte = characters. When I made the statement "outside the UTF-8 character = range" I was referring to the discrete set of characters from U+0000 to = U+7FFFFFFF (or U+10FFFF if using the restricted RFC 3629 definition). I = assumed this was a clearly bounded set. >>>>>>=20 >>>>>> To be clear, my only intent was to expand your original = definition of 'unprintable' beyond the C0 control codes (U+0000 to = U+001F, U+007F) to also include the well known C1 control codes (U+0080 = to U+009F). To avoid confusion, I should have used the Unicode code = point notation. I certainly don't want to try and go down the road of = specifying what characters are 'printable', but I thought C1 control = codes were worth stating explicitly in the same way you did C0 control = codes. Your original definition seemed unnecessarily restrictive since = the C1 control codes, for example, are not printable but are certainly a = valid UTF-8 sequence of octets greater than or equal to 128. Does that = make sense? >>>>>>=20 >>>>>> If you think your original definition of 'unprintable' is broad = enough, then I will use that. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Gonzalo >>>>>>=20 >>>>>> On Oct 23, 2012, at 6:26 PM, Adam Roach wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On 10/23/12 16:56, Oct 23, Gonzalo Salgueiro wrote: >>>>>>>=20 >>>>>>>> "For the purposes of this document, we define 'unprintable' to = mean a string of octets that: (a) contains an octet with a value in the = range of 0 to 31, inclusive; (b) contains an octet with a value of 127, = (c) contains any octet greater than or equal to 128 which is a = formatting or control character (such as 128 to 159) within the UTF-8 = character set; or (d) falls outside the UTF-8 character range, as = specified by [UNICODE]." >>>>>>>>=20 >>>>>>>> Does that sound ok? >>>>>>>>=20 >>>>>>> I think we're still talking past each other here. >>>>>>>=20 >>>>>>> "Outside the UTF-8 character range" simply isn't a sensible = thing to say. What we're talking about putting into a log record is a = series of *octets*, not a series of *characters*. UTF-8 is an encoding = that defines how octets are put together to make characters. >>>>>>>=20 >>>>>>> Once you start talking about the octets as if they *are* = characters, you're conflating two very different things. So, for = example, you can't talk about "a string of octets that... falls outside = the UTF-8 character range." >>>>>>>=20 >>>>>>> You can talk about a string of bytes that does not form a valid = UTF-8 sequence, and that's almost certainly what you want to say here. >>>>>>>=20 >>>>>>> I'm also getting a bit lost in what you mean when you say "which = is a formatting or control character (such as 128 to 159)." Keep in mind = that we're still talking about *octets* here, not characters. In UTF-8, = there's nothing special about an octet with a value of 128. There's = nothing special about an octet with a value of 159. Both can appear as = the second octet in a two-octet character. Or the second or third octet = in a three-octet character. And so on. The same goes for everything = between 128 and 191. >>>>>>>=20 >>>>>>> Now, octet values of 192, 193, and 245-255 won't appear in valid = UTF-8. If we wanted to be abundantly careful, we could call those out as = being invalid. But I think we catch those just fine if we talk about = octets that form valid UTF-8 sequences. >>>>>>>=20 >>>>>>> Or are you meaning to call out UTF-8 code points like U+0080 = (the Latin-1 padding character)? Because that has nothing to do with an = *octet* with a value of 128. It would be encoded as a two-octet sequence = starting with 194. However, if we're intending to go down the rabbit = hole of making decisions about whether to Base-64 encode based on which = UTF-8 codepoints we want to consider "printable," then we've got years = of draft refinement ahead of us (I can already imagine the right-to-left = mark arguments). That way lies madness. >>>>>>>=20 >>>>>>> All of which is a very long winded way to say: octets are not = characters and characters are not octets; and you need to write the text = in a way that does not mix them with each other. >>>>>>>=20 >>>>>>> /a >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sip-clf mailing list >>>> sip-clf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sip-clf >>>=20 >>>=20 >>=20 >> _______________________________________________ >> sip-clf mailing list >> sip-clf@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-clf >>=20 >=20 From musgravepj@gmail.com Fri Nov 30 06:32:23 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 1E64B21F88E9; Fri, 30 Nov 2012 06:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm+0jzpJ-RHO; Fri, 30 Nov 2012 06:32:21 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 639E921F86D8; Fri, 30 Nov 2012 06:32:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so818156ieb.31 for ; Fri, 30 Nov 2012 06:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=3xjZfYIjf7FBIIjJxoz7quvYTWABEk8OBmbpG5Hay5U=; b=yaEEixTT4r0rdkGILL7X1Qd+43mEhRIBNIAGR6AQxgE/ATtqnIr5cg4HMU4UygXM42 s6IQGvsmmZfOzEfE3sxE8bDsZ3FPaHzVYnvsk4Sr7sy0WVOAQOMdo/PCCu8gHN8z2aTW Y2sC/4c0h//TKs7QGdEuWmYHjcewXO1tpUZzppYBVHqI98SXFvhGxKYQCKMWZeiS0Hoc T+o6s/7+SEXAbEhaTQNfseQxSsBex3LNDvZrXQQLq8ts/+WrLJuOQdR+l2+0Ws2molRX M9vyxZdt+Z1i8qydfYdZClpOHmPaueXtLDD2DS8qX9atWYE9E699QGSKoT5wgsB5FmNl Gfdw== Received: by 10.50.0.193 with SMTP id 1mr1229008igg.0.1354285940866; Fri, 30 Nov 2012 06:32:20 -0800 (PST) Received: from [192.168.1.108] ([204.237.33.112]) by mx.google.com with ESMTPS id uj11sm10106747igb.15.2012.11.30.06.32.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 06:32:20 -0800 (PST) From: Peter Musgrave Content-Type: multipart/alternative; boundary="Apple-Mail=_B579145E-962F-4EFF-B254-79EB25189C04" Date: Fri, 30 Nov 2012 09:32:17 -0500 Message-Id: <75A3BD8B-4AC9-4EE4-B0CC-C1A79707E246@gmail.com> To: iesg-secretary@ietf.org, Robert Sparks Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "sip-clf@ietf.org Mailing" Subject: [sip-clf] PubRequest for draft-ietf-sipclf-problem-statement-11 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, 30 Nov 2012 14:32:23 -0000 --Apple-Mail=_B579145E-962F-4EFF-B254-79EB25189C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii draft-ietf-sipclf-problem-statement-11 (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet Standard, Informational, Experimental, or Historic)? Why is = this the proper type of RFC? Is this type of RFC indicated in the title = page header? This document is a proposed standard. It defines a data model for = logging SIP messages.=20 (2) The IESG approval announcement includes a Document Announcement = Write-Up. Please provide such a Document Announcement Write-Up. Recent = examples can be found in the "Action" announcements for approved = documents. The approval announcement contains the following sections: Technical Summary: The Session Initiation Protocol does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document provides motivation=20= for a common format and defines the mandatory fields for such a log = as well as a need to allow extensions. Working Group Summary: There were some issues with respect the choice of indexed-ascii versus = binary representation. This stalled the WG progress for a number of = meeting. This is described in more detail in (9) below. The final = product now has good support in the WG.=20 This document has had one cycle of IESG review. This review raised = issues to do with internationalization, UTF as well as concerns that the = write up did not fully reflect some of the WG discussion. These issues = have been addressed in the -11 version and this revised write-up. Document Quality: Are there existing implementations of the protocol? Have a significant = number of vendors indicated their plan to implement the specification? = Are there any reviewers that merit special mention as having done a = thorough review, e.g., one that resulted in important changes or a = conclusion that the document had no substantive issues? If there was a = MIB Doctor, Media Type or other expert review, what was its course = (briefly)? In the case of a Media Type review, on what date was the = request posted? There are some implementations as indicated by Vijay Gurbani:.=20 At least three implementations are known, although none deployed as far as I can tell. One was being implemented by Anders Nygren, as posted on the list [1]. ALU has an early implementation, but it is conditionally compiled into the code. Illinois Institute of Technology did an implementation based on Asterix codebase, but I do not think the students gave it back to Asterix. [1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00435.html Personnel: Peter Musgrave is the document shepherd. Robert Sparks in the responsible AD.=20 (3) Briefly describe the review of this document that was performed by = the Document Shepherd. If this version of the document is not ready for = publication, please explain why the document is being forwarded to the = IESG. The post-IESG review document was reviewed by Peter Musgrave andRobert = Sparks. Prior to IESG review it had several WG last-Calls.=20 (4) Does the document Shepherd have any concerns about the depth or = breadth of the reviews that have been performed? No concerns about the reviews depth/breadth.=20 (5) Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place. No broader review was deemed necessary.=20 (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the = IESG should be aware of? For example, perhaps he or she is uncomfortable = with certain parts of the document, or has concerns whether there really = is a need for it. In any event, if the WG has discussed those issues and = has indicated that it still wishes to advance the document, detail those = concerns here. No specific concerns.=20 (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR = disclosures. No IPR disclosure has been filed.=20 (9) How solid is the WG consensus behind this document? Does it = represent the strong concurrence of a few individuals, with others being = silent, or does the WG as a whole understand and agree with it? The consensus for the fields which any format solution needs to log have = been uncontroversial. The minimal set of fields are basic to any SIP = record keeping and an extension mechanism allows customization by those = who need more.=20 The discussion of potential mechanisms and alignment with existing = mechanism was more spirited. Syslogand Ipfix logging have had advocates = at various times. The IETF77 minutes record a discussion about a need to look seriously at = IPFIX. Syslog was also discussed and a comment made that data was too = much for syslog (and was concurred with by chair of syslog). Some comments made (DaveH) - suggesting syslog needs further scrutiny = (http://www.ietf.org/mail-archive/web/sip-clf/current/msg00105.html). = Comments were made expressing concern about binary content in SIP = messages (Hadriel Kaplan) and extreme sizes of some elements (Cullen = Jennings). Syslog expert (Rainer Gerhards) indicated that the size = issues should not be a major concern although there are parts of the = syslog community that prefer small sizes. The final email in this chain = is http://www.ietf.org/mail-archive/web/sip-clf/current/msg00141.html = and after that no one "went to bat" for syslog and energy went into = discussions of IPFIX versus Indexed ASCII.=20 The IPFIX vs indexed-ASCII discussion lasted for a number of meeting = cycles with neither garnering complete support. Over time the group = decided to proceed with indexed ascii. There is agreement that the data = model defined by sipclf could be used as a basis for an IPFIX format = should some future group wish to define one. =20 (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate = email messages to the Responsible Area Director. (It should be in a = separate email because this questionnaire is publicly available.) There have been no signs of extreme discontent.=20 (11) Identify any ID nits the Document Shepherd has found in this = document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts = Checklist). Boilerplate checks are not enough; this check needs to be = thorough. There is one NIT: =3D=3D Outdated reference: A later version (-09) exists of draft-ietf-sipclf-format-05 This document is moving to IESG approval in parallel with this document.=20= (12) Describe how the document meets any required formal review = criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. (13) Have all references within this document been identified as either = normative or informative? Yes. (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their completion? None. (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in = the Last Call procedure. There are no down refs. (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the = abstract, and discussed in the introduction? If the RFCs are not listed = in the Abstract and Introduction, explain why, and point to the part of = the document where the relationship of this document to the other RFCs = is discussed. If this information is not in the document, explain why = the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). N/A (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document = Shepherd to validate sections of the document written in a formal = language, such as XML code, BNF rules, MIB definitions, etc. N/A. --Apple-Mail=_B579145E-962F-4EFF-B254-79EB25189C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

(1) What type of RFC is being requested (BCP, = Proposed Standard, Internet Standard, Informational, Experimental, or = Historic)? Why is this the proper type of RFC? Is this type of RFC = indicated in the title page header?

This document is a proposed = standard. It defines a data model for logging SIP messages. 

Technical Summary:

The Session = Initiation Protocol does not have a common log

   = format, and as a result, each server supports a distinct log = format

   that makes it unnecessarily complex = to produce tools to do trend

   analysis and = security detection.  This document provides motivation 

   well as a need to allow = extensions.

Working Group Summary:

There were some = issues with respect the choice of indexed-ascii versus binary = representation. This stalled the WG progress for a number of meeting. = This is described in more detail in (9) below. The final product now has = good support in the WG. 

This document has had one cycle = of IESG review. This review raised issues to do with = internationalization, UTF as well as concerns that the write up did not = fully reflect some of the WG discussion. These issues have been = addressed in the -11 version and this revised write-up.

Document Quality:

Are there existing = implementations of the protocol? Have a significant number of vendors = indicated their plan to implement the specification? Are there any = reviewers that merit special mention as having done a thorough review, = e.g., one that resulted in important changes or a conclusion that the = document had no substantive issues? If there was a MIB Doctor, Media = Type or other expert review, what was its course (briefly)? In the case = of a Media Type review, on what date was the request posted?

There are some implementations as indicated by Vijay = Gurbani:. 

At = least three implementations are known, although none deployed as = far
as I can = tell.
One was being = implemented by Anders Nygren, as posted on the list [1].
ALU has an early = implementation, but it is conditionally compiled into
the code.  Illinois = Institute of Technology did an implementation based
on Asterix codebase, but I do = not think the students gave it back to
Asterix.


Peter Musgrave is the document shepherd.

Robert Sparks in the responsible AD. 

The post-IESG review document was reviewed by Peter Musgrave = andRobert Sparks. Prior to IESG review it had several WG = last-Calls. 

(4) Does the document Shepherd have any concerns = about the depth or breadth of the reviews that have been = performed?

No concerns about the reviews = depth/breadth. 

(5) Do portions of the document need = review from a particular or from broader perspective, e.g., security, = operational complexity, AAA, DNS, DHCP, XML, or internationalization? If = so, describe the review that took place.

No broader review was = deemed necessary. 

(6) Describe any specific concerns or = issues that the Document Shepherd has with this document that the = Responsible Area Director and/or the IESG should be aware of? For = example, perhaps he or she is uncomfortable with certain parts of the = document, or has concerns whether there really is a need for it. In any = event, if the WG has discussed those issues and has indicated that it = still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed = that any and all appropriate IPR disclosures required for full = conformance with the provisions of BCP 78 and BCP 79 have already been = filed. If not, explain why?

Yes.

(8) Has an IPR = disclosure been filed that references this document? If so, summarize = any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG = consensus behind this document? Does it represent the strong concurrence = of a few individuals, with others being silent, or does the WG as a = whole understand and agree with it?

The consensus for the fields = which any format solution needs to log have been uncontroversial. The = minimal set of fields are basic to any SIP record keeping and an = extension mechanism allows customization by those who need = more. 

The discussion of potential mechanisms and = alignment with existing mechanism was more spirited. Syslogand Ipfix = logging have had advocates at various times.

The IETF77 minutes record = a discussion about a need to look seriously at IPFIX. Syslog was also = discussed and a comment made that data was too much for syslog (and was = concurred with by chair of syslog).
Some comments made (DaveH) - suggesting syslog needs further = scrutiny (http://www.ietf.org/mail-archive/web/sip-clf/current/msg00105.html).= Comments were made expressing concern about binary content in SIP = messages (Hadriel Kaplan) and extreme sizes of some elements (Cullen = Jennings). Syslog expert (Rainer Gerhards) indicated that the size = issues should not be a major concern although there are parts of the = syslog community that prefer small sizes. The final email in this chain = is http://www.ietf.org/mail-archive/web/sip-clf/current/msg00141.html = and after that no one "went to bat" for syslog and energy went into = discussions of IPFIX versus Indexed ASCII. 

The IPFIX vs indexed-ASCII discussion lasted for = a number of meeting cycles with neither garnering complete support. Over = time the group decided to proceed with indexed ascii. There is agreement = that the data model defined by sipclf could be used as a basis for an = IPFIX format should some future group wish to define one.  


(10) Has anyone threatened an appeal or = otherwise indicated extreme discontent? If so, please summarise the = areas of conflict in separate email messages to the Responsible Area = Director. (It should be in a separate email because this questionnaire = is publicly available.)

There have been no signs of extreme = discontent. 

(11) Identify any ID nits the Document Shepherd = has found in this document. (See http://www.ietf.org/tools/idnit= s/ and the Internet-Drafts Checklist). Boilerplate checks are not = enough; this check needs to be thorough.

There is one NIT:

 =3D=3D Outdated reference: A = later version (-09) exists of

     = draft-ietf-sipclf-format-05


(12) Describe how the document meets any = required formal review criteria, such as the MIB Doctor, media type, and = URI type reviews.

N/A.

(13) Have all references within = this document been identified as either normative or informative?

(14) Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? = If such normative references exist, what is the plan for their = completion?

None.

(15) Are there downward = normative references references (see RFC 3967)? If so, list these = downward references to support the Area Director in the Last Call = procedure.

There are no down refs.

(16) Will = publication of this document change the status of any existing RFCs? Are = those RFCs listed on the title page header, listed in the abstract, and = discussed in the introduction? If the RFCs are not listed in the = Abstract and Introduction, explain why, and point to the part of the = document where the relationship of this document to the other RFCs is = discussed. If this information is not in the document, explain why the = WG considers it unnecessary.

No.

(17) Describe the = Document Shepherd's review of the IANA considerations section, = especially with regard to its consistency with the body of the document. = Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. = Confirm that newly created IANA registries include a detailed = specification of the initial contents for the registry, that allocations = procedures for future registrations are defined, and a reasonable name = for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review = for future allocations. Provide any public guidance that the IESG would = find useful in selecting the IANA Experts for these new = registries.

N/A

(19) Describe reviews and = automated checks performed by the Document Shepherd to validate sections = of the document written in a formal language, such as XML code, BNF = rules, MIB definitions, etc.

To: "iesg-secretary@ietf.org" , Robert Sparks Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "sip-clf@ietf.org Mailing" Subject: [sip-clf] PubRequest: draft-ietf-sipclf-format-09 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, 30 Nov 2012 14:34:59 -0000 --Apple-Mail=_FA796736-2CF4-4522-8392-4B818FD8B73D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii draft-ietf-sipclf-format-09 (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet Standard, Informational, Experimental, or Historic)? Why is = this the proper type of RFC? Is this type of RFC indicated in the title = page header? Proposed Standard. (2) The IESG approval announcement includes a Document Announcement = Write-Up. Please provide such a Document Announcement Write-Up. Recent = examples can be found in the "Action" announcements for approved = documents. The approval announcement contains the following sections: Technical Summary: The Session Initiation Protocol does not have a common log format, and = as a result, each server supports a distinct log format that makes it = unnecessarily complex to produce tools to do trend analysis and security = detection. This document describes a text based format based on the = data model defined in the companion document sipclf-problem-statement. = This format uses an indexed text approach to facilitate rapid searching = of the log contents while retaining the advantages of a generic text = search and filtering tools.=20 Working Group Summary: The discussion of indexed-ascii specifically did not result in any = contentious issues in the WG discussion. More generally the choice of = indexed ascii was more difficult for the WG. That process is described = in the write-up for sipclf-problem-statement. Document Quality: There were sample implementations of the indexed ascii format written by = Peter Musgrave and placed on the sipclf Wiki page.=20 Additional information from Vijay Gurbani: At least three implementations are known, although none deployed as far as I can tell. One was being implemented by Anders Nygren, as posted on the list [1]. ALU has an early implementation, but it is conditionally compiled into the code. Illinois Institute of Technology did an implementation based on Asterix codebase, but I do not think the students gave it back to Asterix. [1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00435.html Personnel: Peter Musgrave is the shepherd. Robert Sparks is the responsible AD. (3) Briefly describe the review of this document that was performed by = the Document Shepherd. If this version of the document is not ready for = publication, please explain why the document is being forwarded to the = IESG. This document has been read fully by the shepherd. Nits were checked.=20 (4) Does the document Shepherd have any concerns about the depth or = breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place. No. (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the = IESG should be aware of? For example, perhaps he or she is uncomfortable = with certain parts of the document, or has concerns whether there really = is a need for it. In any event, if the WG has discussed those issues and = has indicated that it still wishes to advance the document, detail those = concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR = disclosures. None. (9) How solid is the WG consensus behind this document? Does it = represent the strong concurrence of a few individuals, with others being = silent, or does the WG as a whole understand and agree with it? The WG understands this document. As described in the write-up for = sip-clf-problem-statement there were two competing strategies. This = document describes the strategy that was adopted. Once discussion = focused on the specifics of HOW to log SIP in a text format the work = group understood the objective and worked towards it.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate = email messages to the Responsible Area Director. (It should be in a = separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this = document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts = Checklist). Boilerplate checks are not enough; this check needs to be = thorough. Yes. There is one error (a normative reference to the problem = statement). This reference will be correct once the AD changes the = status of the problem statement to proposed standard. (12) Describe how the document meets any required formal review = criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. (13) Have all references within this document been identified as either = normative or informative? Yes. (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in = the Last Call procedure. There are reference to a parallel document (sipclf-problem-statement). = These need to move in parallel to avoid issues with downward normative = references.=20 (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the = abstract, and discussed in the introduction? If the RFCs are not listed = in the Abstract and Introduction, explain why, and point to the part of = the document where the relationship of this document to the other RFCs = is discussed. If this information is not in the document, explain why = the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). This document defines two new registries. The new registries are: IANA has created a registry of Version values entitled "SIP CLF Version Values". IANA has created a registry of SIP CLF Transport Flag values entitled "SIP CLF Transport Flag Values". It is the opinion of the shepherd that these are reasonable names.=20 (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. The two new registries are "SIPCLF Version values" and "SIP CLF = Transport Flags".=20 (19) Describe reviews and automated checks performed by the Document = Shepherd to validate sections of the document written in a formal = language, such as XML code, BNF rules, MIB definitions, etc. N/A --Apple-Mail=_FA796736-2CF4-4522-8392-4B818FD8B73D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

(1) What type of RFC is being = requested (BCP, Proposed Standard, Internet Standard, Informational, = Experimental, or Historic)? Why is this the proper type of RFC? Is this = type of RFC indicated in the title page header?

Proposed = Standard.

(2) The IESG approval announcement includes a = Document Announcement Write-Up. Please provide such a Document = Announcement Write-Up. Recent examples can be found in the "Action" = announcements for approved documents. The approval announcement contains = the following sections:

Technical Summary:

Working Group Summary:

The discussion of = indexed-ascii specifically did not result in any contentious issues in = the WG discussion. More generally the choice of indexed ascii was more = difficult for the WG. That process is described in the write-up for = sipclf-problem-statement.

Document Quality:

There were sample implementations of the indexed ascii format = written by Peter Musgrave and placed on the sipclf Wiki = page. 

            Additional = information from Vijay Gurbani:

At least three implementations = are known, although none deployed as far
as I can tell.

One was being implemented by Anders Nygren, as = posted on the list [1].
the code. =  Illinois Institute of Technology did an implementation = based
on Asterix = codebase, but I do not think the students gave it back to
Asterix.


Personnel:

Peter Musgrave is the = shepherd.

Robert Sparks is the responsible AD.

This document has been read fully by the shepherd. Nits were = checked. 

(4) Does the document Shepherd have any concerns = about the depth or breadth of the reviews that have been = performed?

No.

(5) Do portions of the document = need review from a particular or from broader perspective, e.g., = security, operational complexity, AAA, DNS, DHCP, XML, or = internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the = Document Shepherd has with this document that the Responsible Area = Director and/or the IESG should be aware of? For example, perhaps he or = she is uncomfortable with certain parts of the document, or has concerns = whether there really is a need for it. In any event, if the WG has = discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

No concerns.

(8) Has an IPR disclosure been filed that = references this document? If so, summarize any WG discussion and = conclusion regarding the IPR disclosures.

None.


(10) Has anyone threatened an appeal or = otherwise indicated extreme discontent? If so, please summarise the = areas of conflict in separate email messages to the Responsible Area = Director. (It should be in a separate email because this questionnaire = is publicly available.)

No.

(11) Identify any ID nits the = Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnit= s/ and the Internet-Drafts Checklist). Boilerplate checks are not = enough; this check needs to be thorough.

Yes. There is one error = (a normative reference to the problem statement). This reference will be = correct once the AD changes the status of the problem statement to = proposed standard.

(12) Describe how the document meets any = required formal review criteria, such as the MIB Doctor, media type, and = URI type reviews.

N/A.

(13) Have all references within = this document been identified as either normative or informative?

(14) Are there normative references to documents = that are not ready for advancement or are otherwise in an unclear state? = If such normative references exist, what is the plan for their = completion?

No.

(15) Are there downward = normative references references (see RFC 3967)? If so, list these = downward references to support the Area Director in the Last Call = procedure.

There are reference to a parallel document = (sipclf-problem-statement). These need to move in parallel to avoid = issues with downward normative references. 

(16) Will = publication of this document change the status of any existing RFCs? Are = those RFCs listed on the title page header, listed in the abstract, and = discussed in the introduction? If the RFCs are not listed in the = Abstract and Introduction, explain why, and point to the part of the = document where the relationship of this document to the other RFCs is = discussed. If this information is not in the document, explain why the = WG considers it unnecessary.

No.

(17) Describe the = Document Shepherd's review of the IANA considerations section, = especially with regard to its consistency with the body of the document. = Confirm that all protocol extensions that the document makes are = associated with the appropriate reservations in IANA registries. Confirm = that any referenced IANA registries have been clearly identified. = Confirm that newly created IANA registries include a detailed = specification of the initial contents for the registry, that allocations = procedures for future registrations are defined, and a reasonable name = for the new registry has been suggested (see RFC 5226).

IANA has created a registry of Version values entitled "SIP = CLF

   Version Values".
IANA has created a
   Flag Values".


(18) List any new = IANA registries that require Expert Review for future allocations. = Provide any public guidance that the IESG would find useful in selecting = the IANA Experts for these new registries.

The two new = registries are "SIPCLF Version values" and "SIP CLF Transport = Flags". 

(19) Describe reviews and automated checks = performed by the Document Shepherd to validate sections of the document = written in a formal language, such as XML code, BNF rules, MIB = definitions, etc.

N/A


= --Apple-Mail=_FA796736-2CF4-4522-8392-4B818FD8B73D-- From rjsparks@nostrum.com Fri Nov 30 07:46:54 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 F2E6321F8B06 for ; Fri, 30 Nov 2012 07:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgtF9p05CDDD for ; Fri, 30 Nov 2012 07:46:53 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20821F8B13 for ; Fri, 30 Nov 2012 07:46:50 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAUFkgrU038078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 30 Nov 2012 09:46:45 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50B8D4DD.9090703@nostrum.com> Date: Fri, 30 Nov 2012 09:46:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "sip-clf@ietf.org Mailing" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Subject: [sip-clf] Moving forward with draft-ietf-sipclf-problem-statement and draft-ietf-sipclf-format 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, 30 Nov 2012 15:46:54 -0000 All - Peter has updated the writeups for both of the drafts in the subject. I will be taking both through IETF LC (this will be a 2nd last call for the problem-statement draft), and through IESG evaluation together. Watch for the last call announcement early next week. Thanks, RjS