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

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 27 Mar 2010 00:10:00 -0400

Sorry for dredging up an old email, but I was scanning old ones and came upon this... [I removed lots of text from the original]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cullen Jennings
> Sent: Wednesday, February 03, 2010 11:21 PM
> 
> I don't think this information model need to be extensible. In fact the
> one thing I am going to continue to strongly argue is that it should not
> be extensible. Note this does not mean we can not have new sip headers or
> new body types, we can, they just go in the list of sip headers or body
> type.

I don't understand that statement.  You don't want it to be extensible, but you're ok with adding more headers and bodies? 

> I'm against the needless complexity or arbitrary extensibility and would
> want to see a good argument made for adding things.

1) We won't get the list right.  We'll try, but odds are some admin will want header Foo which we thought she wouldn't want.
2) Some products should/need to record things others don't.  SBC's for example need to record some stuff that make no sense for a proxy, and likewise a forking proxy might need to record stuff a simple UAC wouldn't. We won't want to clutter the list of fields up to accommodate the different product types.
3) We haven't really talked about events or processing results, but I can imagine someday we might want to record more than just headers as part of the message record.  For example, if we ever make a deployable version of rfc4474, then a verifier generating a clf entry for a received Invite might want to add "verified" vs. not, or some such. ;)

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 27 Mar 2010 15:43:14 -0500

On 03/26/2010 11:10 PM, Hadriel Kaplan wrote:
> Sorry for dredging up an old email, but I was scanning old ones and
> came upon this... [I removed lots of text from the original]
[...]
>> I don't think this information model need to be extensible. In fact
>> the one thing I am going to continue to strongly argue is that it
>> should not be extensible. Note this does not mean we can not have
>> new sip headers or new body types, we can, they just go in the list
>> of sip headers or body type.
>
> I don't understand that statement.  You don't want it to be
> extensible, but you're ok with adding more headers and bodies?

If you look at the indexed-ASCII approach, it defines a limited
set of fixed headers (Timestamp, To, From, etc.)  Then it has a
TLV block where you can add as many headers as you want.
The advantage is that this scheme is extensible -- you add
anything you want in the TLV block without perturbing the
fixed block.  You can be creative and come up with a format
string that tell a SIP entity what to put in the TLV block
(a la Apache) at run-time.

> 1) We won't get the list right.  We'll try, but odds are some admin
> will want header Foo which we thought she wouldn't want.
> 2) Some products should/need to record things others don't.  SBC's for
> example need to record some stuff that make no sense for a proxy, and
> likewise a forking proxy might need to record stuff a simple UAC
> wouldn't. We won't want to clutter the list of fields up to
> accommodate the different product types.
> 3) We haven't really talked about events or processing results,
> but I can imagine someday we might want to record more than just
> headers as part of the message record.  For example, if we ever
> make a deployable version of rfc4474, then a verifier generating
> a clf entry for a received Invite might want to add "verified"
> vs. not, or some such. ;)

I believe all of the above use cases will be supported by the
TLV block.

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