From ron.frederick@bluecoat.com Thu Jul 1 18:37:30 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235D33A6805 for ; Thu, 1 Jul 2010 18:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.155 X-Spam-Level: * X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNsz1zDV5Kfj for ; Thu, 1 Jul 2010 18:37:29 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 3495E3A6803 for ; Thu, 1 Jul 2010 18:37:28 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o621berX023084; Thu, 1 Jul 2010 18:37:40 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 18:37:35 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-68--920255519 From: Ron Frederick In-Reply-To: Date: Thu, 1 Jul 2010 18:37:35 -0700 Message-Id: <2177A9D6-6D49-4E9E-B745-11C15EFDF43E@bluecoat.com> References: <4AD792A7-029D-4042-AEFF-8354CE577818@bluecoat.com> To: Mark Day X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 02 Jul 2010 01:37:35.0534 (UTC) FILETIME=[25C814E0:01CB1987] Cc: "middisc@ietf.org" Subject: Re: [middisc] Poll re vendor ID format X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 01:37:30 -0000 --Apple-Mail-68--920255519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 30, 2010, at 11:23 AM, Mark Day wrote: > Yes, I guess so. Not exactly elegant conceptually, I admit.=20 > =20 > 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=92s the right solution.=20 While it's not ideal, I can live with it. So, to summarize, I think = we're proposing the following alternatives as supported: Case 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Opt kind=3DTBD | Opt len | Vendor =3D 0x00 | Std type code | +---------------+---------------+---------------+---------------+ | | | ... Optional standard payload data dependent on type code ... | | | +---------------+---------------+---------------+---------------+ Case 2: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Opt kind=3DTBD | Opt len | Vendor =3D 0xFF | Vend typecode | +---------------+---------------+---------------+---------------+ | Vendor OUI (3 bytes) | | +---------------+---------------+---------------+ | | | | ...Optional vendor payload data dependent on vend typecode... | | | +---------------+---------------+---------------+---------------+ Case 3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Opt kind=3DTBD | Opt len | Vendor=3DOther | | +---------------+---------------+---------------+ | | | | ...Optional vendor payload data dependent on vend typecode... | | | +---------------+---------------+---------------+---------------+ In case 3, the byte following the Vendor field SHOULD be a vendor type = code, as shown in case 2. However, vendors MAY encode option type = information in other ways for their specific vendor code. Is everyone ok with this? --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-68--920255519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 30, 2010, at 11:23 AM, Mark Day = wrote:
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=92s the right = solution. 

While it's not ideal, I can live with it. So, to summarize, I think = we're proposing the following alternatives as = supported:

Case = 1:

 0             =       1               =     2                 =   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
+---------------+---------------+---------------+---------------+
| = Opt kind=3DTBD  |    Opt len    | Vendor =3D = 0x00 | Std type code |
+---------------+---------------+---------------+---------------+
| =                     =                     =                     =   |
| ... Optional standard payload data dependent on = type code ... |
|             =                     =                     =           |
+---------------+---------------+---------------+---------------+

Case = 2:

 0             =       1               =     2                 =   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
+---------------+---------------+---------------+---------------+
| = Opt kind=3DTBD  |    Opt len    | Vendor =3D = 0xFF | Vend typecode |
+---------------+---------------+---------------+---------------+
| =              Vendor OUI (3 bytes) =             |         =       |
+---------------+---------------+---------------+ =               = |
|                   =                     =                     =     |
| ...Optional vendor payload data = dependent on vend typecode... |
| =                     =                     =                     =   |
+---------------+---------------+---------------+---------------+

Case = 3:

 0             =       1               =     2                 =   3
 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9+---------------+---------------+---------------+---------------+
| Opt kind=3DTBD =  |    Opt len    | Vendor=3DOther  | =               |
+---------------+---------------+---------------+ =               |
|             =                     =                     =           |
| ...Optional vendor payload data dependent on = vend typecode... |
+---------------+---------------+---------------+---------------+

In case 3, the byte following the Vendor field SHOULD be a = vendor type code, as shown in case 2. However, vendors MAY encode option = type information in other ways for their specific vendor code.

Is everyone ok with = this?
-- 
Ron Frederick
=

= --Apple-Mail-68--920255519--