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

[Anders Nygren <[e-mail]>]

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