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

[Anders Nygren <[e-mail]>]

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