Subject: [middisc] Poll re vendor ID format

From: "Knutsen, Andrew" <[email-masked]>
Date: Sun, 27 Jun 2010 15:41:16 -0700

I'm about to leave on a week vacation, but to keep things going I'd like to get some discussion going on the vendor ID format.  As it stands, its looking like this is most of the spec for the new option (along with some restrictions on use and warnings about misuse).

   I currently see three possibilities on the table:

    1) 8 bits of vendor ID, with special IDs reserved for a following standard type or OUI.
 
    2) As above, plus requiring a vendor specific type byte follow the vendor ID.
 
    3) 7 bits of vendor ID, with a bit reserved to indicate an alternate 7 bits of standard type. A special vendor ID would indicate a following OUI.

    The advantage of (1) is more vendor IDs.
    The advantage of (2) is the same format for vendor and standard types.
    The advantage of (3) is shorter standard types.

    Of course if anyone has other ideas they're welcome.

    I'd like to note that in my opinion, our goal is to achieve standardization in this area before too many vendors enter the fray... Ie, sometime in the next 20 years.

Andrew

---

From: Mark Day <[email-masked]>
Date: Sun, 27 Jun 2010 18:07:15 -0700

For myself, as long as I can do a vendor-specific message and lose only one byte for vendor ID, I think I'm OK.  So that rules out choice (2) but means I don't much care between (1) and (3).   

I think the numbers work out with 253 vendors in scheme 1 and 127 vendors in scheme 3.  
Since in either case the OUI escape would allow a much larger number of vendors if really needed, and we expect that this scheme should only be a bridge to a true standard in the not-too-distant future, I have a hard time seeing a strong reason for preferring one or the other.  

In the absence of a clear and convincing argument that gains rough consensus, I'd recommend tossing a coin to decide between 1 and 3.  

--Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Knutsen, Andrew
Sent: Sunday, June 27, 2010 6:41 PM
To: [email-masked]
Subject: [middisc] Poll re vendor ID format

 

Andrew
 
_______________________________________________
middisc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/middisc

---

From: Ron Frederick <[email-masked]>
Date: Mon, 28 Jun 2010 18:16:33 -0700

> In the absence of a clear and convincing argument that gains rough consensus, I'd recommend tossing a coin to decide between 1 and 3.

My preference would be for option 2 here, as I think it is the cleanest and simplest of the proposals when it comes to parsing and it remains reasonably compact. Of the other two, I prefer option 1 over option 3 because it avoids overloading vendor & type information in the same field.

If option 2 is unacceptable, I would argue to make the presence of a vendor-specific type byte which immediately follows the vendor byte as a SHOULD, if people are not comfortable making it a MUST. In cases where this is followed, it essentially becomes option 2, but it leaves open the door for vendors to encode the option type in some other way if they really need to save space. When they follow the recommendation, though, it makes both the vendor-specific and the standard options both follow the same format, and provides a simple way for a vendor to provide multiple options under a single vendor ID if they don't already have some other proprietary mechanism.

Option 2 also has an advantage when we define the special vendor code for the OUI -- we could keep the type byte in a fixed position and say that the OUI would follow this, so you'd end up with:

+---------------+---------------+---------------+---------------+---------------+---------------------------
+ vendor = 0xFF |      type     |              vendor OUI (3 bytes)             + type-specific payload...
+---------------+---------------+---------------+---------------+---------------+---------------------------

If we don't require the type field after the vendor field, would this mean that the OUI would have to come immediately after the vendor field and before the OUI, essentially making the position of the type field dependent on whether the vendor managed to get a single-byte vendor code assigned, even in cases where the vendor followed our recommendation of having a single byte type field at the beginning of their option? This seems more complex to me...

-- 
Ron Frederick
[email-masked]

---

From: Mark Day <[email-masked]>
Date: Mon, 28 Jun 2010 19:13:02 -0700

If option 2 is unacceptable, I would argue to make the presence of a vendor-specific type byte which immediately follows the vendor byte as a SHOULD, if people are not comfortable making it a MUST. In cases where this is followed, it essentially becomes option 2, but it leaves open the door for vendors to encode the option type in some other way if they really need to save space.

I like the idea of scheme 2 with a SHOULD instead of a MUST on the type byte.  Or maybe we can think of it as a compromise between scheme 1 and scheme 2.  Either way, as long as the second byte usage is suggested rather than mandated.

--Mark

---

From: Ron Frederick <[email-masked]>
Date: Wed, 30 Jun 2010 09:19:07 -0700

> I like the idea of scheme 2 with a SHOULD instead of a MUST on the type byte.  Or maybe we can think of it as a compromise between scheme 1 and scheme 2.  Either way, as long as the second byte usa…

In this design, what are your thoughts on handing the OUI case? Would you require the type byte in that case (just as we would for standard options where the vendor ID was 0x00) and put the OUI field after it?
-- 
Ron Frederick
[email-masked]

---

From: Mark Day <[email-masked]>
Date: Wed, 30 Jun 2010 11:23:08 -0700

Yes, I guess so.  Not exactly elegant conceptually, I admit.

But if the goal is to have the type byte in a predictable place across all standard, vendor-ID & OUI usages, while minimizing the number of bytes of mandatory overhead, I think it's the right solution.

--Mark

From: Ron Frederick [mailto:[email-masked]]
Sent: Wednesday, June 30, 2010 12:19 PM
To: Mark Day
Cc: [email-masked]
Subject: Re: [middisc] Poll re vendor ID format

In this design, what are your thoughts on handing the OUI case? Would you require the type byte in that case (just as we would for standard options where the vendor ID was 0x00) and put the OUI field after it?
--
Ron Frederick
[email-masked]<mailto:[email-masked]>