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

[Anders Nygren <[e-mail]>]

On Wed, Mar 16, 2011 at 1:36 PM, Chris Lonvick <[e-mail]> 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.  :-)

Since this is a text format I assumed it was the right thing to to.
(And if we should start worrying about one byte, I think there are some
commas "," that we could remove instead.)

But an alternative could be
tag 0x0000-0x7FFF   standard
tag 0x8000-0xFFFF   vendor

Or as Bill Gates almost said "Nobody needs more than 32K tags" :)

/Anders

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