Re: [sip-clf] Vendor extensions in draft-ietf-sipclf-format-01.txt

[Gonzalo Salgueiro <[e-mail]>]

Thanks for raising your concerns Anders. 

As you know, this draft was just published today and its principal intent was to formulate an initial solution for SIP CLF extensibility.

A little history:
The current proposal for Vendor-specific extensions using a Syslog-like approach (i.e. name@<private enterprise number>) was something proposed over email and decided at the last SIPCLF Interim meeting in January. So this really is a first pass at implementing vendor-specificied optional fields.

That said, I'll comment inline to your points

On Mar 14, 2011, at 10:53 PM, Anders Nygren wrote:

> Hi
> I must say that I really dislike the proposed format for vendor specific fields.
> Having a variable length "tag" before the length field means that it
> is necessary
> to scan the tag looking for the ',' just to find the length field.
> 
You make a valid point. I'd like others to weigh in here and comment on whether they think this is a serious performance limitation. I'll propose this as a discussion point for the upcoming meeting in Prague. The reason for the variable length tag is that it is based on the SD-ID format from Syslog, which is variable in length (i.e. the unrestricted name before the '@').  I think using a Vendor-ID based on a PEN is common sense, so I'd like to stick with that if possible. We could decide on a fixed length name (or number to parallel the tag from the Pre-Defined Optional Fields) followed by four byte PEN.

> There is no simple way to tell he difference between a sip-clf
> optional field and
> a vendor specific optional field. So it will always be necessary to scan the
> record looking for the ',' .
> Actually looking at RFC 5424 ch 4.3.2 it looks like this would be a legal
> ID, "0001,FFFF,@12345" which would be difficult to differentiate from a
> standard optional field without a lot of work.
> 
Remember that that this draft restricts the scope of the syntax to the 2nd format definition of SD-IDs in RFC5424. Thus, the above wouldn't be a legal vendor-specified optional field since "0001" doesn't contain an '@', which is mandatory for a Vendor-ID as defined in the draft. So there should be no confusion there as the Vendor-ID from the vendor-specified optional fields and the Tag from the pre-defined optional fields can never be the same.

> I think a better way to do this would be similar to diameter RFC3588, ch 4.1.
> Then we could have just one format for standard optional fields and vendor
> specific fields
> 
> byte 1  0x09
> byte 2-5 Tag (Hex)
> byte 6-9 VendorId
> byte 10 0x2C
> byte 11-14 Length (Hex)
> byte 15 0x2C
> byte 16-.. Value (variable length)
> 
> Where VendorId is the IANA assigned "SMI Network Management Private
> Enterprise Codes"  [ASSIGNNO] value.
> VendorId=0 is used a for the standard optional fields defined in SIP-CLF.

I know that PEN = 0 is a Reserved value and if it is confirmed that it can be used in this way (as apparently DIAMETER did), then I think this proposal is very reasonable. This unifies both optional field types into a single seamless representation. I'll let others, like Chris Lonvick, more knowledgeable than I weigh in on this as well to confirm my thoughts.

Regards,

Gonzalo
> 
> /Anders
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf