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

[Chris Lonvick <[e-mail]>]

Hi Gonzalo,

I do like that proposal.  It does keep things simple and clean.  (I must 
have missed it earlier.)

I don't think that there will be any problem in using PEN=0 in this manner 
in this application.  I'll check with some people to see if they can think 
of anything.

If there is a problem in using PEN=0, the alternative would be for the 
IETF to register a PEN specifically for this application.  In that case, 
using PEN=<new assigned number> would mean that the TAG is pre-defined, 
and using any other number would mean that the TAG is vendor specified.

Best regards,
Chris

On Wed, 16 Mar 2011, Gonzalo Salgueiro 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
>
>
>
> 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
>>>>>
>>>>>
>>>
>>>
>
>