From musgravepj@gmail.com Sun Apr 1 11:09:42 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 3AC4C21F88F3 for ; Sun, 1 Apr 2012 11:09:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMM-7MsR-my8 for ; Sun, 1 Apr 2012 11:09:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6598821F88F2 for ; Sun, 1 Apr 2012 11:09:38 -0700 (PDT) Received: by iazz13 with SMTP id z13so3825799iaz.31 for ; Sun, 01 Apr 2012 11:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=wY52Ju3uzGtWMjwRqfe543BNaO06sMI3znlmoR5CwV4=; b=Vc9mp3/E/xCBwDElqF8YXGjFF4vREHJIiNfFXiOvJw5TAhk49G8tWLnDUubpsQ68bB Wiz7qZrAQBDo8/U9rSb2bGdzhKD3xeKEujcx+9eIp84g0xuVL9eI5b2KKHh1ZNCKnwAD 89qXLKrOKKAk8r0bM/qhKFXiDPUcZKxiaSTKxTR8UACwmJ1Uxb3AWqEZlX/V2t0f/byv hDHAOQT7qwMNH5AZvKvow5hIXZVgOSlMTa70tVFifZlf3ZLHszyOp/3OWxyZWimrfBNU YLg28P/0mTNhae9PWCpJubFKr5UsZ0yAZm6euOGkSebPAQ7rmbc47NB4mOygYk6eGvAg C1Kg== Received: by 10.50.159.161 with SMTP id xd1mr3705697igb.15.1333303777917; Sun, 01 Apr 2012 11:09:37 -0700 (PDT) Received: from [192.168.1.105] ([204.237.33.112]) by mx.google.com with ESMTPS id md6sm9524993igc.0.2012.04.01.11.09.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 11:09:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FD07795-20DF-4B43-B22A-55A8899F6A74" From: Peter Musgrave In-Reply-To: <5EECD580-7FB7-41ED-A2CB-85100181A36D@cisco.com> Date: Sun, 1 Apr 2012 14:09:36 -0400 Message-Id: <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> References: <20120312191323.25429.64464.idtracker@ietfa.amsl.com> <5EECD580-7FB7-41ED-A2CB-85100181A36D@cisco.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.1257) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-06.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: Sun, 01 Apr 2012 18:09:42 -0000 --Apple-Mail=_0FD07795-20DF-4B43-B22A-55A8899F6A74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Robert, Gozallo, Vijay I have read the diffs in the document and think this is in good shape.=20= Do we feel that a final WGLC is needed for any of these changes - or = should I go ahead and do the writeup for IESG? Robert - as AD do the changes made here address your concerns?=20 SIP-CLFers: Any issues here? Peter=20 On 2012-03-12, at 4:14 PM, Gonzalo Salgueiro wrote: > Folks: >=20 > I have posted the -06 version of the SIP CLF Format Draft and it is = now in the archives at [1]. >=20 > This draft was meant to address the AD review items that were raised. = The diffs between the -05 and the -06 versions is at [2] >=20 > Some of the more substantial changes include: >=20 > - Added IANA registry for Version field and Transport Flags > - Addressed change request from ASCII to UTF-8 > - Updated escaping mechanism description for CRLF, TAB, '-', '?' > - Clarified treatment of repeated optional fields > - Cleaned up Timestamp and Length definitions > - Removed all body type restrictions > - Addressed a bunch of minor issues and nits > =20 > [1] http://tools.ietf.org/html/draft-ietf-sipclf-format > [2] http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipclf-format-06.txt= >=20 > Regards, >=20 > Gonzalo >=20 > On Mar 12, 2012, at 3:13 PM, 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: >> http://www.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>=20 >> _______________________________________________ >> sip-clf mailing list >> sip-clf@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-clf >>=20 >=20 --Apple-Mail=_0FD07795-20DF-4B43-B22A-55A8899F6A74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Robert, Gozallo, Vijay

I have read the diffs in = the document and think this is in good = shape. 

Do we feel that a final WGLC is = needed for any of these changes - or should I go ahead and do the = writeup for IESG?

Robert - as AD do the changes = made here address your = concerns? 

SIP-CLFers: Any issues = here?

Peter 


On 2012-03-12, at 4:14 PM, Gonzalo Salgueiro wrote:

Folks:

I = have posted the -06 version of the SIP CLF Format Draft and it is now in = the archives at [1].

This draft was meant to = address the AD review items that were raised. The diffs between the -05 = and the -06 versions is at [2]

Some of the more = substantial changes include:

- Added IANA = registry for Version field and Transport Flags
- Addressed = change request from ASCII to UTF-8
- Updated escaping = mechanism description for CRLF, TAB, '-', '?'
- Clarified = treatment of repeated optional fields
- Cleaned up Timestamp = and Length definitions
- Removed all body type = restrictions
- Addressed a bunch of minor issues and = nits
 


Gonzalo



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.

Title =           : Format for = the Session Initiation Protocol (SIP) Common Log Format (CLF)
Author(s) =       : Gonzalo Salgueiro
=             &n= bsp;           &nbs= p;Vijay Gurbani
=             &n= bsp;           &nbs= p;Adam Roach
= Filename        : = draft-ietf-sipclf-format-06.txt
Pages =           : = 28
= Date =            : = 2012-03-12

  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.


A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt=

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt<= br>
_______________________________________________
sip-clf = mailing = list
sip-clf@ietf.org
https://www.ietf.org/mailman/listinfo/sip-clf<= br>


= --Apple-Mail=_0FD07795-20DF-4B43-B22A-55A8899F6A74-- From vkg@bell-labs.com Mon Apr 2 08:06:24 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 7948C21F85C3 for ; Mon, 2 Apr 2012 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 HBMMLCgZ2zit for ; Mon, 2 Apr 2012 08:06:23 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B665C21F857F for ; Mon, 2 Apr 2012 08:06:20 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q32F6DPD021671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 10:06:13 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q32F6CD5031439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 10:06:13 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q32F6Bi4003094; Mon, 2 Apr 2012 10:06:11 -0500 (CDT) Message-ID: <4F79C188.2040400@bell-labs.com> Date: Mon, 02 Apr 2012 10:11:04 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Musgrave References: <20120312191323.25429.64464.idtracker@ietfa.amsl.com> <5EECD580-7FB7-41ED-A2CB-85100181A36D@cisco.com> <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> In-Reply-To: <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-06.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: Mon, 02 Apr 2012 15:06:24 -0000 On 04/01/2012 01:09 PM, Peter Musgrave wrote: > Hi Robert, Gozallo, Vijay > > I have read the diffs in the document and think this is in good shape. Peter: Thank you for going through the updated drafts. > Do we feel that a final WGLC is needed for any of these changes - or > should I go ahead and do the writeup for IESG? I will leave that question to the chairs and AD to decide. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From gsalguei@cisco.com Mon Apr 2 11:56:32 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 7B40E21F8599 for ; Mon, 2 Apr 2012 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 h4OL74+jCeQF for ; Mon, 2 Apr 2012 11:56:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F921F85E6 for ; Mon, 2 Apr 2012 11:56:31 -0700 (PDT) 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 q32IuUq0014200 for ; Mon, 2 Apr 2012 14:56:30 -0400 (EDT) Received: from rtp-vpn4-306.cisco.com (rtp-vpn4-306.cisco.com [10.82.209.50]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q32IuNIJ020003; Mon, 2 Apr 2012 14:56:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A656B643-9513-4213-91C5-B126FD76B658" From: Gonzalo Salgueiro In-Reply-To: <4F79C188.2040400@bell-labs.com> Date: Mon, 2 Apr 2012 14:56:20 -0400 Message-Id: References: <20120312191323.25429.64464.idtracker@ietfa.amsl.com> <5EECD580-7FB7-41ED-A2CB-85100181A36D@cisco.com> <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> <4F79C188.2040400@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1257) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-06.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: Mon, 02 Apr 2012 18:56:32 -0000 --Apple-Mail=_A656B643-9513-4213-91C5-B126FD76B658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 2, 2012, at 11:11 AM, Vijay K. Gurbani wrote: > On 04/01/2012 01:09 PM, Peter Musgrave wrote: >> Hi Robert, Gozallo, Vijay >>=20 >> I have read the diffs in the document and think this is in good = shape. >=20 > Peter: Thank you for going through the updated drafts. Thanks, indeed. >=20 >> Do we feel that a final WGLC is needed for any of these changes - or >> should I go ahead and do the writeup for IESG? >=20 > I will leave that question to the chairs and AD to decide. I'm of the mind that this isn't necessary but will gladly defer to the = chair and AD. Cheers, Gonzalo >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ >=20 --Apple-Mail=_A656B643-9513-4213-91C5-B126FD76B658 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 04/01/2012 01:09 PM, Peter Musgrave = wrote:
Hi Robert, Gozallo, = Vijay

I have read the = diffs in the document and think this is in good = shape.

Peter: Thank you for going through the = updated drafts.

Thanks, = indeed.

Do= we feel that a final WGLC is needed for any of these changes - = or
should I go ahead and do = the writeup for IESG?

I will leave that question to = the chairs and AD to decide.

I'm of = the mind that this isn't necessary but will gladly defer to the chair = and = AD.

Cheers,

Gonzalo
<= blockquote type=3D"cite">

Thanks,

- vijay
--
Vijay = K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. = 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-luc= ent.com
Web:   http://ect.bell-labs.com/who/vk= g/


= --Apple-Mail=_A656B643-9513-4213-91C5-B126FD76B658-- From rjsparks@nostrum.com Mon Apr 30 11:11:38 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 4026D21F8885 for ; Mon, 30 Apr 2012 11:11:38 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 J6ezFHOQWhtS for ; Mon, 30 Apr 2012 11:11:37 -0700 (PDT) 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 1C27421F87D6 for ; Mon, 30 Apr 2012 11:11:36 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3UIBREl036474 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 13:11:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F9ED5CE.7080909@nostrum.com> Date: Mon, 30 Apr 2012 13:11:26 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Musgrave References: <20120312191323.25429.64464.idtracker@ietfa.amsl.com> <5EECD580-7FB7-41ED-A2CB-85100181A36D@cisco.com> <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> In-Reply-To: <5761D2B4-AF1F-4FB9-9357-C3BF847B6CA8@gmail.com> Content-Type: multipart/alternative; boundary="------------020708060003050304050005" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sip-clf@ietf.org Mailing" Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-06.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: Mon, 30 Apr 2012 18:11:38 -0000 This is a multi-part message in MIME format. --------------020708060003050304050005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So I'm going through all the email since the original publication request on this document to make sure we haven't missed anything. A couple of points on this one (since I had not previously replied to it). On 4/1/12 1:09 PM, Peter Musgrave wrote: > Hi Robert, Gozallo, Vijay > > I have read the diffs in the document and think this is in good shape. > > Do we feel that a final WGLC is needed for any of these changes - or > should I go ahead and do the writeup for IESG? The changes between -05 and -06 were actually pretty massive. It created registries, it changed the capability of the mechanism (by forcing truncation of messages instead of repeating blocks when logging bodies of entire sip messages. The only comments on this message on list have been from Vijay and Gonzalo. It would be good to see some evidence that someone else in the group has at least looked at the changes. > > Robert - as AD do the changes made here address your concerns? Not completely - I reread the draft and my comments today - I'll be replying separately on those. > > SIP-CLFers: Any issues here? > > Peter > > > On 2012-03-12, at 4:14 PM, Gonzalo Salgueiro wrote: > >> Folks: >> >> I have posted the -06 version of the SIP CLF Format Draft and it is >> now in the archives at [1]. >> >> This draft was meant to address the AD review items that were raised. >> The diffs between the -05 and the -06 versions is at [2] >> >> Some of the more substantial changes include: >> >> - Added IANA registry for Version field and Transport Flags >> - Addressed change request from ASCII to UTF-8 >> - Updated escaping mechanism description for CRLF, TAB, '-', '?' >> - Clarified treatment of repeated optional fields >> - Cleaned up Timestamp and Length definitions >> - Removed all body type restrictions >> - Addressed a bunch of minor issues and nits >> [1] http://tools.ietf.org/html/draft-ietf-sipclf-format >> [2] http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipclf-format-06.txt >> >> Regards, >> >> Gonzalo >> >> On Mar 12, 2012, at 3:13 PM, Internet-Drafts@ietf.org >> wrote: >> >>> >>> 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. >>> >>> 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 >>> >>> 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. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt >>> >>> _______________________________________________ >>> sip-clf mailing list >>> sip-clf@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-clf >>> >> > --------------020708060003050304050005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So I'm going through all the email since the original publication request on this document to make sure we haven't missed anything.

A couple of points on this one (since I had not previously replied to it).

On 4/1/12 1:09 PM, Peter Musgrave wrote:
Hi Robert, Gozallo, Vijay

I have read the diffs in the document and think this is in good shape. 

Do we feel that a final WGLC is needed for any of these changes - or should I go ahead and do the writeup for IESG?
The changes between -05 and -06 were actually pretty massive. It created registries, it changed the capability of the
mechanism (by forcing truncation of messages instead of repeating blocks when logging bodies of entire sip messages.
The only comments on this message on list have been from Vijay and Gonzalo. It would be good to see some evidence
that someone else in the group has at least looked at the changes.

Robert - as AD do the changes made here address your concerns?
Not completely - I reread the draft and my comments today - I'll be replying separately on those.

SIP-CLFers: Any issues here?

Peter 


On 2012-03-12, at 4:14 PM, Gonzalo Salgueiro wrote:

Folks:

I have posted the -06 version of the SIP CLF Format Draft and it is now in the archives at [1].

This draft was meant to address the AD review items that were raised. The diffs between the -05 and the -06 versions is at [2]

Some of the more substantial changes include:

- Added IANA registry for Version field and Transport Flags
- Addressed change request from ASCII to UTF-8
- Updated escaping mechanism description for CRLF, TAB, '-', '?'
- Clarified treatment of repeated optional fields
- Cleaned up Timestamp and Length definitions
- Removed all body type restrictions
- Addressed a bunch of minor issues and nits
 

Regards,

Gonzalo

On Mar 12, 2012, at 3:13 PM, Internet-Drafts@ietf.org wrote:


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.

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

  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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipclf-format-06.txt

_______________________________________________
sip-clf mailing list
sip-clf@ietf.org
https://www.ietf.org/mailman/listinfo/sip-clf



--------------020708060003050304050005-- From rjsparks@nostrum.com Mon Apr 30 11:42:37 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 1605E21F8877 for ; Mon, 30 Apr 2012 11:42:37 -0700 (PDT) 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 ilQ8y3S-v18x for ; Mon, 30 Apr 2012 11:42:36 -0700 (PDT) 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 32E0C21F8869 for ; Mon, 30 Apr 2012 11:42:36 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3UIgSGl041234 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 13:42:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F9EDD13.6010507@nostrum.com> Date: Mon, 30 Apr 2012 13:42:27 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4F21DD3E.7000002@nostrum.com> <31A5C897-B767-4527-9346-905A80977F35@cisco.com> In-Reply-To: <31A5C897-B767-4527-9346-905A80977F35@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipclf-format@tools.ietf.org, sipclf-chairs@tools.ietf.org, "sip-clf@ietf.org Mailing" Subject: Re: [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: Mon, 30 Apr 2012 18:42:37 -0000 Hi Gonzalo - I'm going through all the messages in the threads since the original publication request of -05. There are some things we discuss below that still need touching in -06 (I'm preparing an evaluation of -06 separately and will include these in that message, but wanted to reply here to make it easier for everyone to follow the context) On 2/8/12 6:25 PM, Gonzalo Salgueiro wrote: > Robert - > > Thanks for your thorough and thoughtful review. Below are some inline > comments to your feedback. > > I will release the -06 version of the draft once we have settled on > all of the below points you have raised. > > > On Jan 26, 2012, at 6:09 PM, Robert Sparks wrote: > >> AD review: draft-ietf-sipclf-format-05 >> >> Summary: This document has open issues to address before progressing >> to IETF LC >> >> Major (mostly in document order) >> >> 5) The document should more explicitly discuss the decision to replace >> tabs with spaces. That decision was based on there being no known use >> of tabs in SIP messages that means something semantically other than >> whitespace. The discussion should point that out, and note that you >> will not be able to use the logged information to reconstruct a >> signature over the logged fields, and that any future (or proprietary) >> SIP header fields that include tabs with semantic meaning (carrying a >> blob perhaps) will lose this meaning while being logged. It should also >> be made brutally explicit whether you want this substitution to happen >> when you are logging the entire message, or a body (that might happen >> to have tabs in it). > > We will add a new paragraph that goes something > like this (the new paragraph is added at the end of S4.2 paragraph > "This data MUST appear ... (0x20) prior to being logged."): > > The decision to replace tabs with spaces was based on there > being no known use of tabs in SIP messages to convey any other > meaning than whitespace. Two consequences of the decision to > replace tab with a space character are: (a) it will become > impossible to reconstruct a signature over the logged field that > matches the signature over fields in the original SIP message, > and (b) any future SIP header fields that include tabs with a > different semantic meaning than simply signifying whitespace > will loose this meaning when logged. And finally, the tabs to > spaces substitution MUST occur when logging mandatory fields; > it SHOULD occur when when logging either the entire message or > simply a SIP body. Why SHOULD? When would you violate that SHOULD? >> Minor >> >> There are blocks of text in this document that are really laying out >> the problem. >> Can they be moved into the problem statement/information >> model/framework document >> or simply deleted? >> For example: "Implementing a logging scheme for SIP is a considerable >> challenge.", >> "Whilst one may question the value of the From URI [...]", etc. > > Ok. I'll scour the document for instances of such text and remove them. The "considerable challenge" sentence remains in -06? > > > >> In section 4.2's description of the To tag field you say "Value of the >> tag parameter (if present)" but don't talk about what to do if the tag >> parameter isn't present. In the parallel section on the From tag, you >> don't talk about the potential for messages without From tags. If it's >> the intent to not be able to log messages from legacy 2543 devices, >> that's >> fine, but the document should call that out as a design decision and >> it wouldn't >> hurt to provide some guidance on what to do if such a message shows up. > > I'll add some text to clarify and simplify this. Basically, if the tag > is present in To and From, > it is logged. If it is not present, a "-" is logged. I'll leave it at > that. The intent is not > to differentiate between messages from legacy rfc2543 devices versus the > updated rfc3261. > I'm not easily finding new text? If it's there, pointing at it from the descriptions in 4.2 will help. From rjsparks@nostrum.com Mon Apr 30 11:57:42 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 26AAE21F87D2 for ; Mon, 30 Apr 2012 11:57:42 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 YJMKuynn+cBp for ; Mon, 30 Apr 2012 11:57:41 -0700 (PDT) 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 2542521F86CE for ; Mon, 30 Apr 2012 11:57:41 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3UIveqS043616 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Apr 2012 13:57:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4F9EE0A4.2000905@nostrum.com> Date: Mon, 30 Apr 2012 13:57:40 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "sip-clf@ietf.org Mailing" Content-Type: multipart/alternative; boundary="------------030500050400050906080809" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sip-clf] AD review: draft-ietf-sipclf-format-06 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: Mon, 30 Apr 2012 18:57:42 -0000 This is a multi-part message in MIME format. --------------030500050400050906080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Summary: there are still a few remaining clarifications to capture before IETFLC on this document. This is an update to the AD review on -05. Thanks for addressing the majority of the concerns in that review. There are a few that remain, and the changes introduced some new ones. 1) Thanks for adding the additional description motivating replacing tabs with spaces when creating log entries. The new text says that this replacement SHOULD occur when logging bodies or entire messages. Why is this a SHOULD? When would you not do this replacement? The new text says the decision to do this substitution was based on there being "no known use of tabs in SIP messages". What possible unknown uses are there? It would be better to say "No standardized use of tabs". I also think you mean to scope that claim to SIP header fields. We allow logging arbitrary bodies, and I don't think we have done the research to claim that tabs are meaningless (other than as whitespace) in all possible body types. 2) The description of escaping and encoding in Tag=01 is still ambiguous. You say you must base64 encode any binary body. You also say you must escape CRLFs. I suspect you intend for those to be mutually exclusive? What are you expecting the implementer to use to decide if the body is binary or not? We should be making much more precise use of the terms defined in the media type specifications to make this clear (to avoid things like encoding a body that's already encoded). I don't remember a response to my question about whether log readers should unescape anything (apologies if I'm just not finding a response as I'm rereading the threads). I think from the context of the conversations, the intent was that such a reader would never unescape (since you want to read these with grep and the like). Someone reading a logged body isn't going to be able to tell that the logging system re-encoded a body into base64 unless you're leaving evidence of having done something somewhere else. Are you? 3) This sentence needs adjusting: " It should be noted that as a result of the escaping mechanisms used in this document ('-' and '?') a field that would normally be able to parse if it appeared in a SIP header (as opposed to a log file) may not be syntactically parsable by a SIP parser." I suggest this replacement: "It should be noted that any field value that is modified by the escaping mechanisms defined in this document before logging ('-','?', and CRLF) is likely no longer well-formed SIP and will fail when given to such a parser". 4) Section 4.2's description of To and From tags still doesn't say what to do when the tags aren't present (or am I missing that discussion)? 5) (Nit: the change of text from 'Internet-Draft' to 'RFC' highlighted a problem for me that was already in -05: I suggest this change:) OLD: A Base64 encoded version of this log entry (without the changes required to format it for an RFC) is shown below. NEW: A Base64 encoded version of this log entry (modified as required to format it for an RFC) is shown below. --------------030500050400050906080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Summary: there are still a few remaining clarifications to capture before IETFLC on this document.

This is an update to the AD review on -05. Thanks for addressing the majority of the concerns in that review. There are a few that remain, and the changes introduced some new ones.

1) Thanks for adding the additional description motivating replacing tabs with spaces when creating log entries. The new text says that this replacement SHOULD occur when logging bodies or entire messages. Why is this a SHOULD? When would you not do this replacement?

The new text says the decision to do this substitution was based on there being "no known use of tabs in SIP messages". What possible unknown uses are there? It would be better to say "No standardized use of tabs". I also think you mean to scope that claim to SIP header fields. We allow logging arbitrary bodies, and I don't think we have done the research to claim that tabs are meaningless (other than as whitespace) in all possible body types.

2) The description of escaping and encoding in Tag=01 is still ambiguous. You say you must base64 encode any binary body. You also say you must escape CRLFs. I suspect you intend for those to be mutually exclusive? What are you expecting the implementer to use to decide if the body is binary or not? We should be making much more precise use of the terms defined in the media type specifications to make this clear (to avoid things like encoding a body that's already encoded).

I don't remember a response to my question about whether log readers should unescape anything (apologies if I'm just not finding a response as I'm rereading the threads).
I think from the context of the conversations, the intent was that such a reader would never unescape (since you want to read these with grep and the like). Someone reading a logged body isn't going to be able to tell that the logging system re-encoded a body into base64 unless you're leaving evidence of having done something somewhere else. Are you?

3) This sentence needs adjusting: " It should be noted that as a result of the escaping mechanisms used in this document ('-' and '?') a field that would normally be able to parse if it appeared in a SIP header (as opposed to a log file) may not be syntactically parsable by a SIP parser." I suggest this replacement: "It should be noted that any field value that is modified by the escaping mechanisms defined in this document before logging ('-','?', and CRLF) is likely no longer well-formed SIP and will fail when given to such a parser".

4) Section 4.2's description of To and From tags still doesn't say what to do when the tags aren't present (or am I missing that discussion)?

5) (Nit: the change of text from 'Internet-Draft' to 'RFC' highlighted a problem for me that was already in -05:
I suggest this change:)
OLD:
    A Base64 encoded version of this log entry (without the changes
   required to format it for an RFC) is shown below.
NEW:
   A Base64 encoded version of this log entry (modified as
   required to format it for an RFC) is shown below.
--------------030500050400050906080809--