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

["Spencer Dawkins" <[e-mail]>]

John, thank you for the as-always-careful read and comments...

Anyone else seeing anything that the working group needs to know about?

Thanks!

Spencer

----- Original Message ----- 
From: "Elwell, John" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>; "SIP-CLF Mailing List" 
<[e-mail]>
Sent: Friday, January 29, 2010 7:56 AM
Subject: RE: [sip-clf] WGLC: SIPCLF 
ProblemStatement(draft-gurbani-sipclf-problem-statement-01)


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: [e-mail]
> [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf
> =