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

[Gonzalo Salgueiro <[e-mail]>]

Sounds like we are converging.

On Mar 15, 2011, at 1:40 PM, Anders Nygren wrote:

> On Tue, Mar 15, 2011 at 11:14 AM, Gonzalo Salgueiro <[e-mail]> wrote:
>> 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.
> 
> The vendor flag I mentioned would not be in the Flags field in <IndexPointers>.
> It would be in the TLV structure. So that PEN=0 would not  need to be used
> to indicate that it is a standard optional parameter.
> 
Do you know of any issues with using PEN=0 in this manner?  I don't. It appears that DIAMETER does it, so I suspect it is fine.

> 
>> 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?
> 
> Yes.
> The purpose of the extra pointer was to make parsing simpler in the case where
> there are two different formats for the standard optional parameters and the
> vendor extensions. If they have the same format I see no reason for the extra
> pointer.

OK. So just to confirm, as an implementer, you don't see any added value in specifically being able to identify the beginning of the vendor-specified optional fields (if present)? Knowing the beginning of the combined optional fields is fine (provided they use the same general syntax)?

Regards,

Gonzalo

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