Subject: [sip-clf] minor nits on draft-ietf-sipclf-problem-statement-03

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 04:29:17 -0400

Howdy,
Currently draft-ietf-sipclf-problem-statement-03 has a section 8.2 which states in the first paragraph:
   Each SIP CLF record MUST contain the mandatory
   elements in the order shown below:
         Record size, Timestamp, Message type, Directionality, CSeq,
         R-URI, Destination:port:xport, Source:port:xport, To, From,
         Call-ID, Status, Server-Txn, Client-Txn

Some of that is specific to an ascii format.  For example, the order of the fields is specific to an ascii format (any TLV or templated format wouldn't need such an ordering requirement).  Also, the Record size is not a separate/new field for ipfix, as it's handled by the ipfix format natively.

The draft also has "Destination:port:xport" and "Source:port:xport", but those are really three separate fields each.

-hadriel

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Aug 2010 10:58:13 +0200

Seconded. Since IPFIX is order-independent, in developing the IPFIX representation, we interpret this to mean "must represent the following mandatory elements".

Record size, for instance, is part of the IPFIX framing. The presence of a response code can be used to determine whether a message is a response; we therefore don't need a field for it. Ordering is also unimportant (or rather, implementation-dependent) in IPFIX; our recommended templates placed fixed elements before variable in order to support record seeking.

While looking at the list of mandatory fields, is method not missing from this list? We treat it as mandatory in the SIPCLF IPFIX representation, and it seems like it should be...

Cheers,

Brian

On Aug 3, 2010, at 10:29 AM, Hadriel Kaplan wrote:

> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 04:32:28 -0500

On 08/03/2010 03:29 AM, Hadriel Kaplan wrote:
> Howdy, Currently draft-ietf-sipclf-problem-statement-03 has a section
> 8.2 which states in the first paragraph: Each SIP CLF record MUST
> contain the mandatory
> Some of that is specific to an ascii format.  For example, the order
> of the fields is specific to an ascii format (any TLV or templated
> format wouldn't need such an ordering requirement).

Hadriel: Right; for the indexed-ASCII, the mandatory fields
are in a block following the timestamp (please see figure on
page 5 in [1].)  I would like the fields in this block to be in a
certain order, so that one can visually inspect CLF records
and expect to find the first three fields consisting of
CSeq number, method, and R-URI.

A TLV or templated form like ipfix does not need to maintain
order if it does not want to.

> The draft also has "Destination:port:xport" and "Source:port:xport",
> but those are really three separate fields each.

Is there a specific reason to break these out into individual
components?

[1] http://tools.ietf.org/html/draft-salgueiro-sipclf-indexed-ascii-01

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/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 04:36:06 -0500

On 08/03/2010 03:58 AM, Brian Trammell wrote:
> Record size, for instance, is part of the IPFIX framing. The presence
> of a response code can be used to determine whether a message is a
> response; we therefore don't need a field for it.

The response byte allows a tool to skip that record quickly
if searching for requests, for instance.

> While looking at the list of mandatory fields, is method not missing
> from this list? We treat it as mandatory in the SIPCLF IPFIX
> representation, and it seems like it should be...

The method is part of the CSeq header.  That is, instead of
logging the CSeq number and the method separately, one can
simply log the entire CSeq header, which includes the number
and method.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 05:39:41 -0400

Right, Method is missing and should be put into the list in the problem-statement draft.

Also, the draft has a From and To which say "The From URI, including the tag" and "The To URI, including tag."  But the tags are header params, not URI params.  So really the tags are separate fields from the URIs as well, unless we'd rather just have the complete To and From header fields as whole strings including any header parameters.

-hadriel

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2010 4:58 AM
> To: Hadriel Kaplan
> Cc: SIP-CLF Mailing List
> Subject: Re: [sip-clf] minor nits on draft-ietf-sipclf-problem-statement-
> 03
> 
> Seconded. Since IPFIX is order-independent, in developing the IPFIX
> representation, we interpret this to mean "must represent the following
> mandatory elements".
> 
> Record size, for instance, is part of the IPFIX framing. The presence of a
> response code can be used to determine whether a message is a response; we
> therefore don't need a field for it. Ordering is also unimportant (or
> rather, implementation-dependent) in IPFIX; our recommended templates
> placed fixed elements before variable in order to support record seeking.
> 
> While looking at the list of mandatory fields, is method not missing from
> this list? We treat it as mandatory in the SIPCLF IPFIX representation,
> and it seems like it should be...
> 
> Cheers,
> 
> Brian
> 
> > Some of that is specific to an ascii format.  For example, the order of
> the fields is specific to an ascii format (any TLV or templated format
> wouldn't need such an ordering requirement).  Also, the Record size is not
> a separate/new field for ipfix, as it's handled by the ipfix format
> natively.
> >
> > The draft also has "Destination:port:xport" and "Source:port:xport", but
> those are really three separate fields each.
> >
> > -hadriel

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Aug 2010 11:41:51 +0200

> if searching for requests, for instance.

You have the same information in IPFIX, but you can skip on a per-set, as opposed to a per-record basis. If the Template doesn't have a response code, it's a request.

> simply log the entire CSeq header, which includes the number

Ahhh. Okay. We split this out into sipMethod and sipSequenceNumber, then...

Thanks,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Aug 2010 11:43:11 +0200

hi Hadriel, all,

The Tag is already separated from the From and To URIs in the IPFIX representation, i.e., sipFromURI, sipFromTag, and so on...

Regards,

Brian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 04:47:26 -0500

On 08/03/2010 04:39 AM, Hadriel Kaplan wrote:
> Also, the draft has a From and To which say "The From URI, including
> the tag" and "The To URI, including tag."  But the tags are header
> params, not URI params.  So really the tags are separate fields from
> the URIs as well, unless we'd rather just have the complete To and
> From header fields as whole strings including any header parameters.

Whether or not to have all To/From URI parameters and header parameters
is open to debate (my personal opinion is that for logging, we probably
do not want to log all To/From URI and header parameters --- i.e., make
them a SHOULD strength.)

I would, at the very least, like to allow the tag parameter at a
MUST strength since it has a bearing on dialogue creation.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 05:46:14 -0400

And this is why we keep saying the problem statement draft assumes or implies a specific implementation of the file format, namely the indexed ascii one.  :)

The indexed-ascii draft should be the one to indicate the ordering it wants.

And the "Destination:port:xport" really are separate fields - in indexed-ascii you're just changing the delimiter from TAB to COLON.  In the indexed-ascii draft it may well decide to do that in order to avoid having more index pointers, but that's just an optimization for indexed-ascii; the general requirement is to record those three fields somehow.  For something like ipfix, it makes more sense to keep them separate because the format has native field types for IP Addresses and uint16 port numbers.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vijay K. Gurbani
> Sent: Tuesday, August 03, 2010 5:32 AM
> To: [email-masked]

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Aug 2010 11:46:59 +0200

> order if it does not want to.

From a document-nitpickiness standpoint, this needs to be said somewhere, whether this is in problem statement or in a paragraph in IPFIX ("we interpret the problem statement requirements as follows, and hold the presented solution to meet the requirements as they apply to IPFIX" or something like that).

> Is there a specific reason to break these out into individual

For the IPFIX representation, they're already separate components from IEs in the standard data model: sourceIPv4Address, sourceTransportPort, protocolIdentifier (for transport), etc. 

Regards,

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 05:47:09 -0400

I was talking about the problem-statement draft.  Sorry about the confusion.

-hadriel

> Sent: Tuesday, August 03, 2010 5:43 AM
> To: Hadriel Kaplan
> Cc: SIP-CLF Mailing List
> The Tag is already separated from the From and To URIs in the IPFIX
> representation, i.e., sipFromURI, sipFromTag, and so on...
> 
> Regards,
> 
> Brian
> 
> > Also, the draft has a From and To which say "The From URI, including the
> tag" and "The To URI, including tag."  But the tags are header params, not
> URI params.  So really the tags are separate fields from the URIs as well,
> unless we'd rather just have the complete To and From header fields as
> whole strings including any header parameters.
> >
> > -hadriel
> >
> >
> of a
> from
> >>> Currently draft-ietf-sipclf-problem-statement-03 has a section 8.2
> which
> >> states in the first paragraph:
> of
> but

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 04:50:31 -0500

On 08/03/2010 04:41 AM, Brian Trammell wrote:
> You have the same information in IPFIX, but you can skip on a
> per-set, as opposed to a per-record basis. If the Template doesn't
> have a response code, it's a request.

OK; however, for maximum generality to fit any specific representation,
I'd rather leave the response byte in.  Those representations like
ipfix that have no use for it can simply explain that they don't
need it.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 04:59:02 -0500

On 08/03/2010 04:46 AM, Hadriel Kaplan wrote:
> And this is why we keep saying the problem statement draft assumes or
> implies a specific implementation of the file format, namely the
> indexed ascii one.  :)
>

OK, fair enough.  I can decouple the problem-statement draft by one
more order in the next iteration, especially now that we have
decided to use a table when describing the example.

Thanks.

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 05:57:49 -0400

> Sent: Tuesday, August 03, 2010 5:36 AM
> 

Yuck.  Is there a reason to record them together as a string?  I would almost see it if we could claim the SIPCLF could be recorded/generated at the point in a parser at which the parser has split up a message into headers but not yet parsed the header fields/contents (other than content-length).  But since the indexed-ascii draft has a flags field which indicates retransmissions, I assumed it had to be after parsing the CSeq as well. 

BTW, the problem-statement draft doesn't specify the retransmission flag - is it not mandatory?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 3 Aug 2010 06:02:08 -0400

> Sent: Tuesday, August 03, 2010 5:47 AM
> 

I'd argue we MUST NOT have SHOULDs like that - the fields need to be semantically and syntactically explicit and mandatory.

> MUST strength since it has a bearing on dialogue creation.

Right, but if we record a "URI" and a "tag param", we're recording two separate fields.  Again, a specific implementation like indexed-ascii can combine the two fields into one with a semi-colon delimiter if it wants, but they're two separate fields nonetheless.

OTOH if we record a whole header value, then it's one field.  

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Aug 2010 05:06:17 -0500

On 08/03/2010 04:57 AM, Hadriel Kaplan wrote:
> Yuck.  Is there a reason to record them together as a string?  I
> would almost see it if we could claim the SIPCLF could be
> recorded/generated at the point in a parser at which the parser has
> split up a message into headers but not yet parsed the header
> fields/contents (other than content-length).

In the same vein of keeping the problem-statement decoupled from
any representation, I will maintain two fields --- CSeq number and
Method --- in the next revision.

> flag - is it not mandatory?

The problem-statement does specify the retx flag --- please see
byte 2 in the metadata.

Thanks,

- vijay

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Aug 2010 12:11:29 +0200

Certainly; I'm not commenting on what should or shouldn't be in the problem statement, just ensuring that we (the IPFIX representation) can be deemed to meet all the problem statement requirements by representing the _information_ specified therein, not necessarily each field as specified.

Regards,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Aug 2010 12:48:08 +0200

Vijay,
> For the IPFIX representation, they're already separate components from IEs in the standard data model: sourceIPv4Address, sourceTransportPort, protocolIdentifier (for transport), etc.
This is exactly the point I made on the mic. last week...

Regards, Benoit.