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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 18 Jan 2010 12:44:22 -0600

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

> Folks: I have updated the SIPCLF problem statement draft
> pursuant to the discussion we had in Hiroshima.  Sorry for
> the delay in getting this out.
>
> By far, the biggest discussion point in Hiroshima for the
> problem statement was to provide reasons for what we have
> today (CDR, Wireshark) and why it does not work.  To that extent,
> I have done the following:
>
> 1) I have added a new Section 5 (Alternative approaches to SIP
>  CLF);
> 2) I have added an explicit section that contains the problem
>  statement (newly added Section 3.)
> 3) I have taken out the old S7 (Relationship to other
>  protocols.)  In Hiroshima, we discarded syslog; no one spoke
>  for or against IDMEF.
>
>  The only other protocol that is being considered right now
>  is IPFIX.
>
> Another point of discussion in Hiroshima was that some manner
> of correlation to trace a call end-to-end is needed and should
> be supported by the SIP CLF mechanism.  As far as SIP CLF
> supporting such a mechanism is concerned, it will do so since
> it is designed to extensible (and in fact, in S6, one of the
> use cases --- the third one --- is exactly this one.)  As to
> the problem statement draft or the solutions draft specifying
> such a correlation header, my understanding is that this is
> out of scope for the working group.
>
> Certainly the solutions exist in form of Hadriel's session
> correlation header that can be used or some ad-hoc means
> between two enterprises to correlate calls [1].  But whether
> or not the problem statement or the solutions draft should spell
> out explicitly how to standardize this correlation primitive
> and perform this correlation, I believe that is currently out
> of scope.
>
> The URL for the -01 version is:
> http://www.ietf.org/id/draft-gurbani-sipclf-problem-statement-01.txt
>
> The IETF tools page should be updated shortly so you can perform
> a diff against -00 (until then, use the following tiny URL:
> http://tinyurl.com/00-01-diff).
>
> I suspect that at least one more revision will be required, but
> I promise to get the revision out as soon as I have some
> sizable review comments in.  Please do review the -01 revision
> and post your comments.
>
> [1] Adam Roach mentioned in Hiroshima at the mic that even
>  without an explicit correlation header, one could correlate
>  calls simply by noting that the request left my network with a
>  Call-ID of X and shows up at your network with a Call-ID of Y,
>  etc.
>
> Thank you,
>
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 27 Jan 2010 09:19:58 -0600

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.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jan 2010 14:56:15 +0100

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: [email-masked] 
> [mailto:[email-masked]] 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)
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 11:37:26 -0600

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" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "SIP-CLF Mailing List" 
<[email-masked]>
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.

"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?

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"

"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"

John

> =

---

From: Eric Burger <[email-masked]>
Date: Fri, 29 Jan 2010 19:50:55 -0500

I clearly think it's ready to go :-)

On Jan 29, 2010, at 12:37 PM, Spencer Dawkins wrote:

> ----- Original Message ----- From: "Elwell, John" <[email-masked] 
> >
> To: "Spencer Dawkins" <[email-masked]>; "SIP-CLF Mailing  
> List" <[email-masked]>
> 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:
> 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.
>
> 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.
>
> 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"
>