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

[Chris Lonvick <[e-mail]>]

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