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

[Chris Lonvick <[e-mail]>]

Hi,

I like this one as well.  Unfortunately I won't be in Prague for the 
discussion.

Thanks,
Chris

On Thu, 17 Mar 2011, Anders Nygren wrote:

> On Wed, Mar 16, 2011 at 2:24 PM, Gonzalo Salgueiro <[e-mail]> wrote:
>> Chris -
>> Thanks for the response. One very simple proposal I was offering that would
>> clean up the convoluted syntax and avoid having to look ahead for the '@' is
>> :
>> - A single format for both pre-defined and vendor-specified optional fields
>> based on TLV format
>> - This single format is based on syslog-like tag@PEN is used is used as the
>> "Tag" in TLV and where PEN=0 if it is not vendor-specified.
>> This eliminates any need for a V bit to specify standard, vendor,
>> experimental. Can you confirm that using the Reserved PEN=0 in this manner
>> is valid?
>> This seems to me a simple and elegant solution to this problem. Thoughts?
>> Regards,
>> Gonzalo
>>
>
> Yes, that is fine with me.
> Or to expand it and still keeping in line with syslog, (using a variants of
> both formats in RFC5424 ch 6.3.2. SD-ID, and not just the second format),
> and my previous proposals but avoids the vendor flag.
> It is still easy to parse, (if byte 5="," it is a standard field and
> if byte 5="@"
> it is a vendor extension), and it saves 5 bytes per optional field.
> And You don't have to worry about if PEN = 0 is allowed or not.
>
> In ABNF
>
> optional    = standard | vendor
> tag           = 4HEXDIG
> vendorID   = 4HEXDIG
> length      = 4HEXDIG
> standard   = tag "," length "," value
> vendor      = tag "@" vendorID ","  length "," value
>
> /Anders
>
>>
>> On Mar 16, 2011, at 3:36 PM, Chris Lonvick wrote:
>>
>> Hi,
>>
>> Sorry for the delay in responding - busy with the day job.  :-)
>>
>> I see where you're going with this.  You could preclude the 0x2C character
>> from the VendorID, and you could establish a fixed length for the VendorID,
>> but even with that you're still going to have to do a search ahead to see if
>> there is a 0x40 (@) in the field to determine if it's a vendor specific
>> optional field, or a pre-defined optional field.  As Anders says, not the
>> best way to quickly process.
>>
>> I also saw Anders' proposal for inserting a new 1-byte field in the Optional
>> Fields container.  Using a full byte for two options just seems wasteful to
>> me, but that's probably just me.  :-)  A good option for that is to tell the
>> IANA that the field currently has two options ("s" and "v") but may be
>> expanded at a later time.  In SSH we usually carved out three options:
>> standard, vendor, and experimental.  For experimental, we said that if you
>> come up with something new and want others to try it out (without having to
>> use a single PEN [sort'a]) then have everone agree upon a value in the
>> experimental range.  See the last bullet in section 5.1 of RFC 4254 for an
>> example.
>>
>> Regards,
>> Chris
>>
>> On Tue, 15 Mar 2011, Gonzalo Salgueiro wrote:
>>
>> 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
>>
>>
>>
>>
>>
>>
>