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

[Gonzalo Salgueiro <[e-mail]>]

Anders - 

You are absolutely right, I did misunderstand your point the first time around. I thought you were saying '001' was the Vendor-ID, when in fact you were saying that "0001,FFFF,@<PEN>" is the Vendor-ID. Since the name in front of the '@' is only restricted in the following way:

- MUST be printable US-ASCII strings
- MUST NOT contain an at-sign ('@', ABNF %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters.

it indeed means your example is a valid Vendor-ID and could cause confusion. While this would be very unlikely to happen in practice [I can't imagine an implementer intentionally doing this], it is undesired. I think this fact makes your original proposal that much more elegant than the existing one.

Regards, 

Gonzalo


On Mar 15, 2011, at 10:38 AM, Anders Nygren wrote:

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