Subject: [sip-clf] One possible Information model for SIP CLF

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jan 2010 15:21:58 -0700

David raises and excellent point that we are unclear about our information model and that makes it harder for us to get work done quickly. I encourage people to read RFC 3444.

I think there is a very clear and well define information model for what we need in SIP CLF. 

For each SIP message that is logged, there is a Status-Line or Request-Line, an ordered list of pairs of where each pair has a header-name and a header-value, and finally there may be zero or one message-bodies. We also have where the message was coming from and going to from the transport layer as well as a timestamp. These are defined in RFC 3261. Formal language descriptions of one possible data model for them are provided in section 25.1. If people feel the strong need to have this information model in say UML, I suspect I could do the UML for this in ASCII. 

This is it. 

As usual, I don't claim to have a good handle on where this slides from being an IM to DM but it barely seems relevant for getting the job done. Now of course we could slide the IM differently, such as pulling out the SIP to and from tags as elements in the information model. I don't really care how we slice it apart but the key thing to me that doing so is really easy and largely already defined. I think that on a single 1 hour phone call we could probably come to consensus on what the information model needed to be. 

I would strongly argue that what we don't need is an extensible information model or a formal language schema for describing and extensible data model. SIP 2.0 is not going to be extended in a way that adds elements outside the above items. 

Keep it simple. You are trying to convince someone that currently has an fprintf to replace the it with this so make it easy. 

Cullen

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 Jan 2010 10:28:07 +0100

Yes, why don't we just do it? This group seems to have stalled. I don't have a strong opinion on the information model, so why not take Cullen's suggestion as a starting point and try to get consensus (having a call if necessary)? SIP-CLF is a useful work item, but not one worth spending years trying to find the optimum solution.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 12 January 2010 22:22
> To: SIP-CLF Mailing List
> Subject: [sip-clf] One possible Information model for SIP CLF
> 
> 
> David raises and excellent point that we are unclear about 
> our information model and that makes it harder for us to get 
> work done quickly. I encourage people to read RFC 3444.
> 
> For each SIP message that is logged, there is a Status-Line 
> or Request-Line, an ordered list of pairs of where each pair 
> has a header-name and a header-value, and finally there may 
> be zero or one message-bodies. We also have where the message 
> was coming from and going to from the transport layer as well 
> as a timestamp. These are defined in RFC 3261. Formal 
> language descriptions of one possible data model for them are 
> provided in section 25.1. If people feel the strong need to 
> have this information model in say UML, I suspect I could do 
> the UML for this in ASCII. 
> 
> This is it. 
> 
> As usual, I don't claim to have a good handle on where this 
> slides from being an IM to DM but it barely seems relevant 
> for getting the job done. Now of course we could slide the IM 
> differently, such as pulling out the SIP to and from tags as 
> elements in the information model. I don't really care how we 
> slice it apart but the key thing to me that doing so is 
> really easy and largely already defined. I think that on a 
> single 1 hour phone call we could probably come to consensus 
> on what the information model needed to be. 
> 
> I would strongly argue that what we don't need is an 
> extensible information model or a formal language schema for 
> describing and extensible data model. SIP 2.0 is not going to 
> be extended in a way that adds elements outside the above items. 
> 
> Keep it simple. You are trying to convince someone that 
> currently has an fprintf to replace the it with this so make it easy. 
> 
> 
> Cullen
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf
>