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

[Anders Nygren <[e-mail]>]

On Tue, Mar 15, 2011 at 12:19 AM, Gonzalo Salgueiro <[e-mail]> wrote:
> 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 that You did not understand the point I was trying to make.
As I understand the specification in the 2nd format definition of SD-IDs in
RFC5424, comma "," is allowed in the name part. So
"0001,FFFF,@<Vendor-ID>" would be a legal tag, that would be very difficult to
differentiate from a standard optional field with tag="0001", length="FFFF" and
a value starting with "@<Vendor-ID>"

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