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

[Gonzalo Salgueiro <[e-mail]>]

I like this proposal as well. Despite the extra 5 bytes for vendor-specified optional fields, I think I prefer my proposal only from the point of view that it lines up nicely for both optional field types (and I think there is value in that). I could be easily swayed though... ;-)

My ordered preference list is:

1. My proposal with PEN=0 for pre-defined optional fields
2. Chris Lonvick's proposal of using my proposal with a newly registered/reserved PEN for pre-defined optional fields
3. This proposal

Regards,

Gonzalo


On Mar 17, 2011, at 1:04 PM, 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
>> 
>> 
>> 
>> 
>> 
>>