Re: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)

"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 29 January 2010 13:55 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526BB28C15F for <sip-clf@core3.amsl.com>; Fri, 29 Jan 2010 05:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level:
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTsRbRkjzJqg for <sip-clf@core3.amsl.com>; Fri, 29 Jan 2010 05:55:56 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0447528C159 for <sip-clf@ietf.org>; Fri, 29 Jan 2010 05:55:55 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-715220; Fri, 29 Jan 2010 14:56:17 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6320F1EB82AB; Fri, 29 Jan 2010 14:56:17 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 29 Jan 2010 14:56:17 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Spencer Dawkins <spencer@wonderhamster.org>, SIP-CLF Mailing List <sip-clf@ietf.org>
Date: Fri, 29 Jan 2010 14:56:15 +0100
Thread-Topic: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)
Thread-Index: AcqfZEaDxHiNG/PlStqMhjJQJdVUwQBbThTg
Message-ID: <A444A0F8084434499206E78C106220CAB4EC4DCE@MCHP058A.global-ad.net>
References: <7505A2C58D8F4FD88B47D10EA74649CD@china.huawei.com> <4E300CA47C49464FA3D7B57F96443DA3@china.huawei.com>
In-Reply-To: <4E300CA47C49464FA3D7B57F96443DA3@china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 13:55:57 -0000

I have reviewed the draft. Generally it is in good shape and pretty well ready to go, apart from the following minor issues.

1. A general comment:
In section 1 it states:
"This document uses the term "SIP Server" that is defined to include
   the following SIP entities: user agent server , registrar, redirect
   server, a SIP proxy in the role of user agent server, and a B2BUA in
   the role of a user agent server." 
The first issue is that we define the term "SIP server", but throughout the rest of the document we sometimes talk about "SIP server" and sometimes about "SIP entity" (see, for example, section 3). We should be consistent.

Secondly, the definition specifically excludes UACs. This seems to suggest that a UAC (i.e., a UA initiating a transaction) should not include that transaction in the log file, yet when acting as a UAS (i.e., receiving a transaction) it should. In my opinion we should talk about UAs, not UASs or UACs (except where we are specifically in a context where UAC or UAS applies). In fact, in 5.1 it specifically DOES include UAC.

A related nit: In Section 4: "This
   format can be used by SIP clients, SIP Servers, proxies, and B2BUAs."
The term SIP server is already defined to include proxies and B2BUAs, so this is inconsistent.

So we need a term that includes any SIP entity (in my opinion "SIP entity" would do fine), and we should stick to that one term.

2. Specific comments in section 8:
"remotehost:  The DNS name or IP address of the upstream client."
Couldn't it also be that of the upstream server?

"contactlist:  Contact URIs in the response, if any.  A "-" field
      value may be used if there aren't any Contact URIs."
Why are we concerned only with contact URIs in responses, and not in requests?

"but to be safe, the working group
      should okay this since a specific SIP CLF format has not been
      defined yet."
This sounds like text that should be removed before publication.

"To get a gist of how these correlation directives
      help, please see Section 6 of a predecessor [5] to this draft."
Is this really meant to be retained - the reference will have expired?

Likewise the note at the end of section 8.

3. Specific comments in section 8:
"Accordingly, if the SIP CLF file is to be moved from
   the generating host, secure FTP or secure email must be used instead."
Should change to:
"Accordingly, if the SIP CLF file is to be moved from
   the generating host, a secure protocol such as secure FTP or secure email must be used instead."

4. RFC 2119 is referenced and terms defined, but I didn't find any normative language in the document.

5. Is RFC 3261 really a normative reference? There is nothing in the CLF document I can implement, and therefore there is nothing from RFC 3261 I need in order to implement.

5. Nits:
"the both the"

"Transporting SIP CLF files across the network pose" - change to "...poses".

"Other formats can be defined that include more headers (and the body)
   from Section 8" change to:
"Other formats can be defined that include more message fields (header fields and/or body parts)
   than those listed in Section 8"

"as a SIP CLF log writers "
change to
"as SIP CLF log writers "

John


> -----Original Message-----
> From: sip-clf-bounces@ietf.org 
> [mailto:sip-clf-bounces@ietf.org] On Behalf Of Spencer Dawkins
> Sent: 27 January 2010 15:20
> To: SIP-CLF Mailing List
> Subject: Re: [sip-clf] WGLC: SIPCLF Problem 
> Statement(draft-gurbani-sipclf-problem-statement-01)
> 
> Just as a wake-up call, we're about halfway through WGLC, and 
> I'm not seeing 
> evidence onlist that people are reading this draft and 
> agreeing that we 
> should adopt it (or even that we should not adopt it).
> 
> I'm assuming that Cullen likes the current version, but his 
> request to adopt 
> was actually for the previous version of this draft. Other 
> than Cullen, the 
> only post I've seen was from Eric, who is one of the draft authors.
> 
> Theo and I are looking for actual statements of support for 
> adopting drafts 
> as working group items - in this case, silence is NOT consent.
> 
> Thanks,
> 
> Spencer
> 
> 
> > Just to let people know, Theo and I agree that this draft should be 
> > adopted as a working group draft. After a quick once-over, 
> I think it's 
> > solid enough to start WGLC now.
> >
> > WGLC will end on 2010/02/05, which gives nearly three weeks 
> for people to 
> > post and discuss comments on the mailing list.
> >
> > Once WGLC is completed, I will ask Vijay to post a 
> draft-ietf-sipclf 00 
> > version addressing WGLC comments. I hope to be able to 
> request publication 
> > for that version of the draft-ietf-sipclf version, so 
> please don't be shy 
> > about sending comments on the individual draft currently posted (at 
> > 
> http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt).
> >
> > Thanks,
> >
> > Spencer, as co-chair 
> 
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf
>