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

From: Anders Nygren <[email-masked]>
Date: Mon, 14 Mar 2011 20:53:10 -0600

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.

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.

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.

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 02:19:48 -0400

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

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

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 08:38:44 -0600

On Tue, Mar 15, 2011 at 12:19 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> 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.
> 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.
>
> 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 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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 10:55:11 -0400

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

---

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 10:45:14 -0600

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

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 <[email-masked]> 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 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
>
> I must say that I really dislike the proposed format for vendor specific
>
> fields.
>
> I think a better way to do this would be similar to diameter RFC3588, ch
>
> 4.1.
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 13:14:19 -0400

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

---

From: Anders Nygren <[email-masked]>
Date: Tue, 15 Mar 2011 11:40:54 -0600

On Tue, Mar 15, 2011 at 11:14 AM, Gonzalo Salgueiro <[email-masked]> 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.

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

/Anders

> On Tue, Mar 15, 2011 at 12:19 AM, Gonzalo Salgueiro <[email-masked]>
>
> wrote:
>
> "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
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 14:26:36 -0400

Sounds like we are converging.

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

> vendor extensions. If they have the same format I see no reason for the extra

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Mar 2011 12:36:31 -0700 (PDT)

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

---

From: Anders Nygren <[email-masked]>
Date: Wed, 16 Mar 2011 14:02:12 -0600

On Wed, Mar 16, 2011 at 1:36 PM, Chris Lonvick <[email-masked]> wrote:
> 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.  :-)

Since this is a text format I assumed it was the right thing to to.
(And if we should start worrying about one byte, I think there are some
commas "," that we could remove instead.)

But an alternative could be
tag 0x0000-0x7FFF   standard
tag 0x8000-0xFFFF   vendor

Or as Bill Gates almost said "Nobody needs more than 32K tags" :)

/Anders

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 16 Mar 2011 16:24:32 -0400

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

On Mar 16, 2011, at 3:36 PM, Chris Lonvick wrote:

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Mar 2011 16:38:41 -0700 (PDT)

Hi Gonzalo,

I do like that proposal.  It does keep things simple and clean.  (I must 
have missed it earlier.)

I don't think that there will be any problem in using PEN=0 in this manner 
in this application.  I'll check with some people to see if they can think 
of anything.

If there is a problem in using PEN=0, the alternative would be for the 
IETF to register a PEN specifically for this application.  In that case, 
using PEN=<new assigned number> would mean that the TAG is pre-defined, 
and using any other number would mean that the TAG is vendor specified.

Best regards,
Chris

---

From: Anders Nygren <[email-masked]>
Date: Thu, 17 Mar 2011 11:04:37 -0600

On Wed, Mar 16, 2011 at 2:24 PM, Gonzalo Salgueiro <[email-masked]> 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
> :
> - 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?

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

> me, but that's probably just me.  :-)  A good option for that is to tell the

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 17 Mar 2011 13:28:03 -0400

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

---

From: Anders Nygren <[email-masked]>
Date: Thu, 17 Mar 2011 11:45:12 -0600

I will not argue this any further. All 3 alternatives are fine with me.

/Anders

On Thu, Mar 17, 2011 at 11:28 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> 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... ;-)
> 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
>
> - A single format for both pre-defined and vendor-specified optional fields
>
> based on TLV format
>

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 17 Mar 2011 12:07:59 -0700 (PDT)

Hi,

I like this one as well.  Unfortunately I won't be in Prague for the 
discussion.

Thanks,
Chris