Subject: [sip-clf] Changes to proposed charter based on discussion in Stockholm

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Aug 2009 11:53:15 -0500

Please review and comment on the text at

http://svn.resiprocate.org/viewsvn/ietf-drafts/clf/clf-draft-charter.txt?revision=3692&view=markup

RjS

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Aug 2009 17:08:34 -0500

> http://svn.resiprocate.org/viewsvn/ietf-drafts/clf/clf-draft-charter.txt?revision=3692&view=markup 

Robert: Overall, the writeup looks great.  I especially
think that the operational guidelines and security
guidance are advantageous outcomes of the hallway
conversation we had with various folks in Stockholm.

I do have one suggestion:

OLD:
* the need to search, merge, and summarize the log records
   from diverse elements.

NEW:
* the need to search, merge, and summarize the log records
   from a log file produced by the corresponding SIP element.

Rationale: I believe that what you are trying to say is
that search, merge, and summarization is being performed
by the administrator or user responsible for a specific
SIP element.  That is, a user may well summarize all the
sessions he or she established during the day, while a
system administrator will be more interested in a summary
of all the sessions set up through the proxy.  Each
principal -- user or the administrator -- is looking at
the log records produced by the specific SIP element they
have access to; respectively, UA and proxy.

Thanks for getting this out.

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Aug 2009 17:36:10 -0500

Thanks for looking at this Vijay.

Your suggestion negates exactly what the text was trying to say though.

The word "diverse" was there on purpose. I've heard an expectation from
the conversation so far to be able to merge records from several  
different
elements on the path of a request (multiple proxies, and potentially  
both
(even several) endpoints, and do something sensible, like answer "what
happened with this request".

RjS

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 20 Aug 2009 19:39:42 -0500

> Your suggestion negates exactly what the text was trying to say though.

Robert: Then I am confused.  More inline.

> the conversation so far to be able to merge records from several different
> elements on the path of a request (multiple proxies, and potentially both

Sure, but that is what the *second* bullet item is covering, is it not?
Namely,

   * the need to correlate messages from multiple elements
     related to a given request (that may fork) or a
     given dialog.

This is what allows folks to correlate a request across multiple
elements using something akin to Hadriel's session-id draft.

The first bullet covers cases where a proxy may want to create
a search tree of forked requests, or where a proxy's administrator
wants to do some trend analysis on a the proxy's log file.  The
first bullet also covers the case where a user wants to do some
analysis on his or her UA's local log file.

Thanks,

- 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}
WWW:   http://ect.bell-labs.com/who/vkg

---

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Aug 2009 09:45:40 -0500

Yes, you're right. But see below:

> analysis on his or her UA's local log file.
And a site administrator may want to merge multiple logs from
a series of proxies and app-servers and run that same trend
analysis.

The text as written does not preclude performing these operations
on data from a single element. Are you wanting to restrict it to
only data from one element? Or are you just trying to make sure the
from-one-element case is covered?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 10:03:02 -0500

> from-one-element case is covered?

Robert: The latter; I want to make sure that the from-one-element
case is covered as well (or at least, not precluded.)

Thanks,

- vijay

---

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Aug 2009 10:09:10 -0500

> case is covered as well (or at least, not precluded.)
I think its a stretch to read the current text in a way that precludes  
that, but
how about this adjustment:

  * the need to search, merge, and summarize the log records
    from one or more possibly diverse elements.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Aug 2009 11:00:27 -0500

Robert Sparks wrote:
> that, but how about this adjustment:
> 

Robert: Sure, the above is good; I do agree it is a stretch,
but being a little pedantic to lessen any illusion of
ambiguity probably never hurts.

Thanks for entertaining my comments.

- vijay