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

[Gonzalo Salgueiro <[e-mail]>]

Anders - 

This would make good fodder for discussion by the group on the list as well as in Prague.  It would be my preference not to further overload the current Flags field in <IndexPointers> with additional and additional flag with pre-defined, vendor-specified, and both settings. I think the most elegant solution is:
 
1. The single format you proposed for both Pre-Defined and Vendor-Specific optional fields (where, if allowed, PEN=0 signifies Pre-Defined optional field).
2. Based on group consensus, decide whether (a) we stick with a single pointer is needed in <IndexPointers> to indicate the beginning of the optional fields (i.e. both pre-defined and vendor-specified) or whether (b) there is value in adding an additional pointer added to <IndexPointers>, where one pointer points to the start of the Pre-Defined optional fields and the other points to the start of Vendor-specified fields.

Sound reasonable?

Regards,

Gonzalo
On Mar 15, 2011, at 12:45 PM, Anders Nygren wrote:

> I would like to modify/extend my original proposal with the following
> two alternatives.
> 
> 1, Two TLV pointers.
> Background:
> The current draft-01 contains only one TLV pointer, "TLV Start
> Pointer", that points
> to the optional parameters block. This block contains both the standard optional
> parameters and the vendor extensions.
> 
> Change:
> Add a new pointer "Vendor Extensions Pointer". So "TLV Start Pointer" points to
> the standard optional parameters. And "Vendor Extensions Pointer" points to
> the vendor extensions block.
> The contents of the Standard optional parameters have the format
> proposed in draft-01,
> and the contents of the Vendor extension block have the format I
> proposed earlier.
> 
> 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)
> 
> 2, Common format
> Keep one common format for both standard optional parameters and
> vendor extensions
> more in line with diameter, RFC3588, ch 4.1
> 
> 0x09                1 byte
> vendor flag        1 byte     "s" = standard or "v" = vendor
> Tag (Hex)          4 bytes
> 0x2C                1 byte
> Length (Hex)     4 bytes
> [VendorId          4 bytes]  Only present if vendor flag="v"
> 0x2C
> Value (variable length)
> 
> /Anders
> 
> On Tue, Mar 15, 2011 at 8:55 AM, Gonzalo Salgueiro <[e-mail]> 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
>> 
>> 
>> 
>>