From lars.eggert@nokia.com Tue Jun 1 02:22:16 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 A863D3A6959 for ; Tue, 1 Jun 2010 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.705 X-Spam-Level: X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 76G0IuhtBt1V for ; Tue, 1 Jun 2010 02:22:15 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6319F3A6950 for ; Tue, 1 Jun 2010 02:22:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o519LcWn002750; Tue, 1 Jun 2010 12:21:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 12:21:48 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 12:21:48 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o519LmL4018188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jun 2010 12:21:48 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: <4BFEF23D.5060005@bluecoat.com> Date: Tue, 1 Jun 2010 12:21:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com> References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <4BFEF23D.5060005@bluecoat.com> To: Andrew Knutsen X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 01 Jun 2010 12:21:42 +0300 (EEST) X-OriginalArrivalTime: 01 Jun 2010 09:21:48.0558 (UTC) FILETIME=[DCAC02E0:01CB016B] X-Nokia-AV: Clean Cc: "middisc@ietf.org" , Ron Frederick Subject: Re: [middisc] TCP middlebox option requirements 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: Tue, 01 Jun 2010 09:22:16 -0000 Hi, On 2010-5-28, at 1:29, Andrew Knutsen wrote: > What I was thinking is simply that there would be a stipulation = (in the option spec) that when an entity applied for a vendor code that = they'd use it for the specified purpose. Ie, not for some other = purpose, or just to sit on. Then, if the option was seen "in the wild" = being used inappropriately, the vendor would have an interest in not = doing that since they'd be publicly breaking their agreement. No police = (unless you count the vendor itself), just peer pressure, so to speak.=20= that seems like a reasonable approach. =46rom the IETF perspective, we'd = want to assign an option number for middlebox discovery techniques, with = enough flexibility in the description that the option could be shared by = and work with the techniques different vendors employ. But we wouldn't = want to allow arbitrary flexibility, so that the option could be used = for any vendor-specific purpose. Obviously, the IETF cannot police whether implementations/vendors will = comply. (We can't even police if folks are using option numbers without = proper assignment...) The best we can hope for is, as Andrew says, some = sort of community fingerpointing if a vendor disregards and goes beyond = the stated use case of the option (middlebox discovery). Lars= From andrew.knutsen@bluecoat.com Tue Jun 1 11:55:02 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 8DD423A699C for ; Tue, 1 Jun 2010 11:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 tZ8dxdshsbCk for ; Tue, 1 Jun 2010 11:55:01 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 8378C3A68E9 for ; Tue, 1 Jun 2010 11:54:57 -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 o51IsjJT023653; Tue, 1 Jun 2010 11:54:45 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 11:54:40 -0700 Message-ID: <4C055770.3050109@bluecoat.com> Date: Tue, 01 Jun 2010 11:54:40 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lars Eggert References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <4BFEF23D.5060005@bluecoat.com> <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com> In-Reply-To: <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com> Content-Type: multipart/alternative; boundary="------------080302040609050505050903" X-OriginalArrivalTime: 01 Jun 2010 18:54:40.0212 (UTC) FILETIME=[E3C63140:01CB01BB] Cc: "middisc@ietf.org" , Ron Frederick Subject: Re: [middisc] TCP middlebox option requirements 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: Tue, 01 Jun 2010 18:55:02 -0000 This is a multi-part message in MIME format. --------------080302040609050505050903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit What about the OUI option, which would bypass the vendor code assignment (although whoever used it could be assumed to be aware of the spec for the option kind)? Andrew Lars Eggert wrote: > Hi, > > On 2010-5-28, at 1:29, Andrew Knutsen wrote: > >> What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose. Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement. No police (unless you count the vendor itself), just peer pressure, so to speak. >> > > that seems like a reasonable approach. From the IETF perspective, we'd want to assign an option number for middlebox discovery techniques, with enough flexibility in the description that the option could be shared by and work with the techniques different vendors employ. But we wouldn't want to allow arbitrary flexibility, so that the option could be used for any vendor-specific purpose. > > Obviously, the IETF cannot police whether implementations/vendors will comply. (We can't even police if folks are using option numbers without proper assignment...) The best we can hope for is, as Andrew says, some sort of community fingerpointing if a vendor disregards and goes beyond the stated use case of the option (middlebox discovery). > > Lars --------------080302040609050505050903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    What about the OUI option, which would bypass the vendor code assignment (although whoever used it could be assumed to be aware of the spec for the option kind)?

Andrew

Lars Eggert wrote: 
Hi,

On 2010-5-28, at 1:29, Andrew Knutsen wrote:
  
    What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose.  Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement.  No police (unless you count the vendor itself), just peer pressure, so to speak. 
    

that seems like a reasonable approach. From the IETF perspective, we'd want to assign an option number for middlebox discovery techniques, with enough flexibility in the description that the option could be shared by and work with the techniques different vendors employ. But we wouldn't want to allow arbitrary flexibility, so that the option could be used for any vendor-specific purpose.

Obviously, the IETF cannot police whether implementations/vendors will comply. (We can't even police if folks are using option numbers without proper assignment...) The best we can hope for is, as Andrew says, some sort of community fingerpointing if a vendor disregards and goes beyond the stated use case of the option (middlebox discovery).

Lars

--------------080302040609050505050903-- From lars.eggert@nokia.com Mon Jun 7 10:04:56 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 E372F28C9E4 for ; Mon, 7 Jun 2010 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.425 X-Spam-Level: X-Spam-Status: No, score=-4.425 tagged_above=-999 required=5 tests=[AWL=2.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 y2KMNu0LTXIa for ; Mon, 7 Jun 2010 10:04:55 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AE6C23A6EBF for ; Mon, 7 Jun 2010 00:49:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o577lwmB003885; Mon, 7 Jun 2010 02:48:59 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 10:48:57 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 10:48:57 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o577moB7011431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2010 10:48:53 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-19--910502884; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 7 Jun 2010 10:48:44 +0300 Message-Id: References: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> To: Mark Day X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Mon, 07 Jun 2010 10:48:44 +0300 (EEST) X-OriginalArrivalTime: 07 Jun 2010 07:48:57.0363 (UTC) FILETIME=[E2759E30:01CB0615] X-Nokia-AV: Clean Cc: "middisc@ietf.org" Subject: Re: [middisc] currently used TCP option numbers 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: Mon, 07 Jun 2010 17:04:57 -0000 --Apple-Mail-19--910502884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-5-27, at 6:13, Mark Day wrote: > Riverbed currently uses options 76,77, and 78. thanks! Cisco and Bluecoat, would you mind sharing which number(s) your products = are using? Thanks, Lars= --Apple-Mail-19--910502884 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYwNzA3NDg0NFowIwYJKoZIhvcNAQkEMRYEFMYJaMRgzxpV/5P7nAinH7iS19v+MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCVFZTMs78bFrvBeSolgqSBLJXXUy2AVsFI2ZuyazGwCiU7L2rEEAwX/FGlDLZXE+gM0JDR HvZrObf8g9PuaDryYCHMeuKjRfAwgB+h06aFMCP62o9qIBdC4oRPS0k3UhhEsAfVsQux48/lICOu 9NkNE4tTvs5UUBk1opWlVB/lCqR/Bc2MM0JHqaWVB5exj7EvvkHjJxcqAsQN9RAwjwA+8PnYfPP6 E+xGBKUOyNmnSXHMFJaSo33zaGxH5iVVXmdQdNWNpx/u48MZsBEUmebNcZ3Y7eUWyAGL6e4bIDf1 APkkh69JpUCsqvN1nPGMEZ6kpqv3O1bwS8ByzJfPCjRxAAAAAAAA --Apple-Mail-19--910502884-- From ananth@cisco.com Mon Jun 7 11:27:06 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 BF0573A67CC for ; Mon, 7 Jun 2010 11:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mVknTtgpi770 for ; Mon, 7 Jun 2010 11:27:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D647E3A672E for ; Mon, 7 Jun 2010 11:27:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFvWDEyrR7Ht/2dsb2JhbACeIHGmL5ojhRcEg0o X-IronPort-AV: E=Sophos;i="4.53,379,1272844800"; d="scan'208";a="208395748" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2010 18:27:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o57IR5SR012629; Mon, 7 Jun 2010 18:27:06 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 11:27:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jun 2010 11:25:54 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809DC37D3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] currently used TCP option numbers Thread-Index: AcsGY5NpEkXBZQvJSAmyTrA2KYYzbQACwa+A References: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , "Mark Day" X-OriginalArrivalTime: 07 Jun 2010 18:27:05.0142 (UTC) FILETIME=[07C10D60:01CB066F] Cc: middisc@ietf.org Subject: Re: [middisc] currently used TCP option numbers 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: Mon, 07 Jun 2010 18:27:06 -0000 =20 > -----Original Message----- > From: middisc-bounces@ietf.org=20 > [mailto:middisc-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: Monday, June 07, 2010 12:49 AM > To: Mark Day > Cc: middisc@ietf.org > Subject: Re: [middisc] currently used TCP option numbers >=20 > Hi, >=20 > On 2010-5-27, at 6:13, Mark Day wrote: > > Riverbed currently uses options 76,77, and 78. >=20 > thanks! >=20 > Cisco and Bluecoat, would you mind sharing which number(s)=20 > your products are using? Cisco uses TCP option 33. Thanks, -Anantha >=20 > Thanks, > Lars >=20 From andrew.knutsen@bluecoat.com Tue Jun 8 14:17:41 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 F3C103A67D4 for ; Tue, 8 Jun 2010 14:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 CEuSBrm7aXoq for ; Tue, 8 Jun 2010 14:17:39 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 850633A67C0 for ; Tue, 8 Jun 2010 14:17:36 -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 o58LHbrn024455; Tue, 8 Jun 2010 14:17:37 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jun 2010 14:17:31 -0700 Message-ID: <4C0EB36B.3070607@bluecoat.com> Date: Tue, 08 Jun 2010 14:17:31 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lars Eggert References: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050603030709000508050002" X-OriginalArrivalTime: 08 Jun 2010 21:17:31.0888 (UTC) FILETIME=[01C86700:01CB0750] Cc: "middisc@ietf.org" Subject: Re: [middisc] currently used TCP option numbers 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: Tue, 08 Jun 2010 21:17:41 -0000 This is a multi-part message in MIME format. --------------050603030709000508050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We use experimental kind 0xFD, 253 decimal. Things seem pretty quiet here. I'll try modifying the RFC as I mentioned before, including the OUI option, and send it out in a bit. Andrew Lars Eggert wrote: > Hi, > > On 2010-5-27, at 6:13, Mark Day wrote: > >> Riverbed currently uses options 76,77, and 78. >> > > thanks! > > Cisco and Bluecoat, would you mind sharing which number(s) your products are using? > > Thanks, > Lars > ------------------------------------------------------------------------ > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > --------------050603030709000508050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    We use experimental kind 0xFD, 253 decimal.

    Things seem pretty quiet here.  I'll try modifying the RFC as I mentioned before, including the OUI option, and send it out in a bit.

Andrew

Lars Eggert wrote: 
Hi,

On 2010-5-27, at 6:13, Mark Day wrote:
  
Riverbed currently uses options 76,77, and 78.
    

thanks!

Cisco and Bluecoat, would you mind sharing which number(s) your products are using?

Thanks,
Lars

_______________________________________________
middisc mailing list
middisc@ietf.org
https://www.ietf.org/mailman/listinfo/middisc

--------------050603030709000508050002-- From ron.frederick@bluecoat.com Thu Jun 10 10:29:16 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 4379A28C0F0 for ; Thu, 10 Jun 2010 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 Zj-6XSBoK8Db for ; Thu, 10 Jun 2010 10:29:15 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 3C6553A6917 for ; Thu, 10 Jun 2010 10:29:15 -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 o5AHTH9Y026282; Thu, 10 Jun 2010 10:29:17 -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, 10 Jun 2010 10:29:11 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-7--616475499 From: Ron Frederick In-Reply-To: <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com> Date: Thu, 10 Jun 2010 10:29:11 -0700 Message-Id: References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <4BFEF23D.5060005@bluecoat.com> <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 10 Jun 2010 17:29:11.0750 (UTC) FILETIME=[70B0BE60:01CB08C2] Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements 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: Thu, 10 Jun 2010 17:29:16 -0000 --Apple-Mail-7--616475499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 1, 2010, at 2:21 AM, Lars Eggert wrote: > On 2010-5-28, at 1:29, Andrew Knutsen wrote: >> What I was thinking is simply that there would be a stipulation = (in the option spec) that when an entity applied for a vendor code that = they'd use it for the specified purpose. Ie, not for some other = purpose, or just to sit on. Then, if the option was seen "in the wild" = being used inappropriately, the vendor would have an interest in not = doing that since they'd be publicly breaking their agreement. No police = (unless you count the vendor itself), just peer pressure, so to speak.=20= >=20 > that seems like a reasonable approach. =46rom the IETF perspective, = we'd want to assign an option number for middlebox discovery techniques, = with enough flexibility in the description that the option could be = shared by and work with the techniques different vendors employ. But we = wouldn't want to allow arbitrary flexibility, so that the option could = be used for any vendor-specific purpose. >=20 > Obviously, the IETF cannot police whether implementations/vendors will = comply. (We can't even police if folks are using option numbers without = proper assignment...) The best we can hope for is, as Andrew says, some = sort of community fingerpointing if a vendor disregards and goes beyond = the stated use case of the option (middlebox discovery). I agree that we'd want some kind of accountability here, and I think the = OUI would give us that just as much accountability as some new IANA = registry of vendor codes for this option would. For me, it just comes = down to the question of how much space we think we can afford. In our original proposal, standard versions of this option would cost 2 = bytes for the type code and vendor-specific versions would cost 5 bytes. = While we could squeeze things down to a single byte type code and single = byte vendor ID to make both versions fit in 2 bytes, this severely = limits the amount of room we have to grow either of those spaces if the = option gets a lot of use. It all comes down to how many different = applications we think will eventually find value in this. --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-7--616475499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 2010-5-28, at 1:29, Andrew = Knutsen wrote:
   What I = was thinking is simply that there would be a stipulation (in the option = spec) that when an entity applied for a vendor code that they'd use it = for the specified purpose.  Ie, not for some other purpose, or just = to sit on. Then, if the option was seen "in the wild" being used = inappropriately, the vendor would have an interest in not doing that = since they'd be publicly breaking their agreement.  No police = (unless you count the vendor itself), just peer pressure, so to speak. =

that seems like a reasonable approach. =46rom the = IETF perspective, we'd want to assign an option number for middlebox = discovery techniques, with enough flexibility in the description that = the option could be shared by and work with the techniques different = vendors employ. But we wouldn't want to allow arbitrary flexibility, so = that the option could be used for any vendor-specific = purpose.

Obviously, the IETF cannot police whether = implementations/vendors will comply. (We can't even police if folks are = using option numbers without proper assignment...) The best we can hope = for is, as Andrew says, some sort of community fingerpointing if a = vendor disregards and goes beyond the stated use case of the option = (middlebox discovery).

I agree that = we'd want some kind of accountability here, and I think the OUI would = give us that just as much accountability as some new IANA registry of = vendor codes for this option would. For me, it just comes down to the = question of how much space we think we can = afford.

In our original proposal, standard = versions of this option would cost 2 bytes for the type code and = vendor-specific versions would cost 5 bytes. While we could squeeze = things down to a single byte type code and single byte vendor ID to make = both versions fit in 2 bytes, this severely limits the amount of room we = have to grow either of those spaces if the option gets a lot of use. It = all comes down to how many different applications we think will = eventually find value in this.
-- 
Ron = Frederick



= --Apple-Mail-7--616475499-- From ron.frederick@bluecoat.com Thu Jun 10 10:37:08 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 26D3B28C142 for ; Thu, 10 Jun 2010 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 vhSg6tDe99TB for ; Thu, 10 Jun 2010 10:37:07 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 013A928C138 for ; Thu, 10 Jun 2010 10:37:06 -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 o5AHb9nG027806; Thu, 10 Jun 2010 10:37:09 -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, 10 Jun 2010 10:37:03 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-8--616003211 From: Ron Frederick In-Reply-To: Date: Thu, 10 Jun 2010 10:37:03 -0700 Message-Id: <6F266BEA-ACD1-4E60-BA19-CC896126C11C@bluecoat.com> References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> To: Mark Day X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 10 Jun 2010 17:37:04.0032 (UTC) FILETIME=[8A314200:01CB08C3] Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements 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: Thu, 10 Jun 2010 17:37:08 -0000 --Apple-Mail-8--616003211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 28, 2010, at 9:17 AM, Mark Day wrote: > Regarding sending options in the middle of a stream, I must admit that = I'm still nervous about that, especially around how the middleboxes = doing this will handle retransmissions of data packets originally sent = with the option. However, I can see legitimate use cases for doing this, = and I can see how an implementation could work if the options were just = treated as essentially best-effort delivery with it being up to the = specific middlebox implementation to handle any reliability concerns = when sending such mid-stream options. > =20 > I may have inadvertently created this concern, and if so I=92d like to = clarify my position to see if we can get it off the table. > =20 > I objected to the requirement for restriction of options to headers = with the SYN bit set, since Riverbed products do use options in other = cases. However, I don=92t believe there is any case in which we start = adding options in the middle of a stream. Sometimes an option appears = only on a few packets at the start of a stream and is no longer used = after some number of exchanges; in other cases, an option is used for = the entire duration of a connection. I don=92t believe that we have any = need for an option to suddenly appear midstream on a flow that did not = previously use it. > =20 > As is correctly noted, it would not be reasonable to assume that a = packet with a newly-added option will still be able to reach the = destination, since something along the route may suppress it. If the = middlebox had added a new option and was not receiving acks from the = other side, it=92s not clear what the right behavior would be. When I = think it through a little, all of the choices seem problematic. It seems = like a whole can of worms that is best avoided. Thanks for the clarification, Mark. This makes perfect sense, and I see = no problem with continuing to allow the option to be sent for all data = packets on the connection. As for the case where the option is sent only for a few packets at the = start of a stream and no longer used after some number of exchanges, I = guess I can see how to make that work. In that case, it seems like each = side would need to keep retransmitting the option data it was sending to = the other side in all data packets until it received a positive = acknowledgement in the return option from the other side that the data = had been received. This would happen independently in each of the two = directions, if both sides wanted to send additional option data in = packets after the SYN/SYN-ACK. Once the acknowledgement was received in = either direction, that direction could stop retransmitting the = corresponding option data. --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-8--616003211 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 28, 2010, at 9:17 AM, Mark Day = wrote:
Regarding sending options in = the middle of a stream, I must admit that I'm still nervous about that, = especially around how the middleboxes doing this will handle = retransmissions of data packets originally sent with the option. = However, I can see legitimate use cases for doing this, and I can see = how an implementation could work if the options were just treated as = essentially best-effort delivery with it being up to the specific = middlebox implementation to handle any reliability concerns when sending = such mid-stream options.
I may = have inadvertently created this concern, and if so I=92d like to clarify = my position to see if we can get it off the = table.
I = objected to the requirement for restriction of options to headers with = the SYN bit set, since Riverbed products do use options in other = cases.  However, I don=92t believe there is any case in which we = start adding options in the middle of a stream.  Sometimes an = option appears only on a few packets at the start of a stream and is no = longer used after some number of exchanges; in other cases, an option is = used for the entire duration of a connection. I don=92t believe that we = have any need for an option to suddenly appear midstream on a flow that = did not previously use it.
As is = correctly noted, it would not be reasonable to assume that a packet with = a newly-added option will still be able to reach the destination, since = something along the route may suppress it. If the middlebox had added a = new option and was not receiving acks from the other side, it=92s not = clear what the right behavior would be. When I think it through a = little, all of the choices seem problematic. It seems like a whole can = of worms that is best = avoided.

Thanks= for the clarification, Mark. This makes perfect sense, and I see no = problem with continuing to allow the option to be sent for all data = packets on the connection.

As for the case = where the option is sent only for a few packets at the start of a stream = and no longer used after some number of exchanges, I guess I can see how = to make that work. In that case, it seems like each side would need to = keep retransmitting the option data it was sending to the other side in = all data packets until it received a positive acknowledgement in the = return option from the other side that the data had been received. This = would happen independently in each of the two directions, if both sides = wanted to send additional option data in packets after the SYN/SYN-ACK. = Once the acknowledgement was received in either direction, that = direction could stop retransmitting the corresponding option = data.
-- 
Ron = Frederick



= --Apple-Mail-8--616003211-- From andrew.knutsen@bluecoat.com Sun Jun 27 15:41:16 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 D9F0C3A687F for ; Sun, 27 Jun 2010 15:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001] 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 XLHeLifr5twD for ; Sun, 27 Jun 2010 15:41:15 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 8BA693A6A06 for ; Sun, 27 Jun 2010 15:41:12 -0700 (PDT) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o5RMfMv4009991 for ; Sun, 27 Jun 2010 15:41:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Jun 2010 15:41:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll re vendor ID format Thread-Index: AcsWSdmy7uMadGvPQkGWK8QVQPvkCg== From: "Knutsen, Andrew" To: Subject: [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: Sun, 27 Jun 2010 22:41:17 -0000 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. =20 2) As above, plus requiring a vendor specific type byte follow the = vendor ID. =20 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 =20 From Mark.Day@riverbed.com Sun Jun 27 18:07:09 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 B9EFF3A6A13 for ; Sun, 27 Jun 2010 18:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_ILLEGAL_IP=1.908] 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 vERlhZhT-0Yi for ; Sun, 27 Jun 2010 18:07:08 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by core3.amsl.com (Postfix) with ESMTP id AA7333A6881 for ; Sun, 27 Jun 2010 18:07:08 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 27 Jun 2010 18:07:18 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.205.165]) with mapi; Sun, 27 Jun 2010 18:07:19 -0700 From: Mark Day To: "Knutsen, Andrew" , "middisc@ietf.org" Date: Sun, 27 Jun 2010 18:07:15 -0700 Thread-Topic: Poll re vendor ID format Thread-Index: AcsWSdmy7uMadGvPQkGWK8QVQPvkCgAEbv0w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 28 Jun 2010 01:07:09 -0000 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 mean= s I don't much care between (1) and (3). =20 I think the numbers work out with 253 vendors in scheme 1 and 127 vendors i= n scheme 3. =20 Since in either case the OUI escape would allow a much larger number of ven= dors if really needed, and we expect that this scheme should only be a brid= ge to a true standard in the not-too-distant future, I have a hard time see= ing a strong reason for preferring one or the other. =20 In the absence of a clear and convincing argument that gains rough consensu= s, I'd recommend tossing a coin to decide between 1 and 3. =20 --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Knutsen, Andrew Sent: Sunday, June 27, 2010 6:41 PM To: middisc@ietf.org Subject: [middisc] Poll re vendor ID format 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 l= ooking like this is most of the spec for the new option (along with some re= strictions 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 stand= ard type or OUI. =20 2) As above, plus requiring a vendor specific type byte follow the vend= or ID. =20 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 standardiza= tion in this area before too many vendors enter the fray... Ie, sometime in= the next 20 years. Andrew =20 _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From ron.frederick@bluecoat.com Mon Jun 28 18:16:32 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 E4B6728C151 for ; Mon, 28 Jun 2010 18:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 TN18Jgz9porV for ; Mon, 28 Jun 2010 18:16:31 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id B133F28C13A for ; Mon, 28 Jun 2010 18:16: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 o5T1GdsA003761; Mon, 28 Jun 2010 18:16:39 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jun 2010 18:16:33 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-158-966766561 From: Ron Frederick In-Reply-To: Date: Mon, 28 Jun 2010 18:16:33 -0700 Message-Id: References: To: Mark Day X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 29 Jun 2010 01:16:33.0944 (UTC) FILETIME=[B6937980:01CB1728] 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: Tue, 29 Jun 2010 01:16:33 -0000 --Apple-Mail-158-966766561 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 27, 2010, at 6:07 PM, Mark Day wrote: > 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). =20 >=20 > I think the numbers work out with 253 vendors in scheme 1 and 127 = vendors in scheme 3. =20 > 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. =20 >=20 > 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 =3D 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... > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On = Behalf Of Knutsen, Andrew > Sent: Sunday, June 27, 2010 6:41 PM > To: middisc@ietf.org > Subject: [middisc] Poll re vendor ID format >=20 > 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). >=20 > I currently see three possibilities on the table: >=20 > 1) 8 bits of vendor ID, with special IDs reserved for a following = standard type or OUI. >=20 > 2) As above, plus requiring a vendor specific type byte follow the = vendor ID. >=20 > 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. >=20 > 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. >=20 > Of course if anyone has other ideas they're welcome. >=20 > 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. >=20 > Andrew --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-158-966766561 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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.

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 =3D 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...

-----Original Message-----
From: middisc-bounces@ietf.org = [mailto:middisc-bounces@ietf.org] On Behalf Of Knutsen, Andrew
Sent: = Sunday, June 27, 2010 6:41 PM
To: middisc@ietf.org
Subject: = [middisc] Poll re vendor ID format

  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
-- 
Ron Frederick
=

= --Apple-Mail-158-966766561-- From Mark.Day@riverbed.com Mon Jun 28 19:12:55 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 3537B3A68B7 for ; Mon, 28 Jun 2010 19:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] 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 jLb-JXZa1-On for ; Mon, 28 Jun 2010 19:12:54 -0700 (PDT) Received: from smtp2.riverbed.com (smtp.riverbed.com [208.70.196.44]) by core3.amsl.com (Postfix) with ESMTP id 295E93A6801 for ; Mon, 28 Jun 2010 19:12:54 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 28 Jun 2010 19:13:04 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.205.165]) with mapi; Mon, 28 Jun 2010 19:13:05 -0700 From: Mark Day To: Ron Frederick Date: Mon, 28 Jun 2010 19:13:02 -0700 Thread-Topic: [middisc] Poll re vendor ID format Thread-Index: AcsXKLwf3Zard68sRqOCtPv4IxctNAABwmVg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD4D50C3MAILBOXES2nbtte_" MIME-Version: 1.0 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: Tue, 29 Jun 2010 02:12:55 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD4D50C3MAILBOXES2nbtte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 foll= owed, it essentially becomes option 2, but it leaves open the door for vend= ors 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 byt= e. 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 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD4D50C3MAILBOXES2nbtte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 comforta= ble 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 sc= heme 1 and scheme 2.  Either way, as long as the second byte usage is suggest= ed rather than mandated. 

 

--Mark

 

--_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD4D50C3MAILBOXES2nbtte_-- From ron.frederick@bluecoat.com Wed Jun 30 09:19:03 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 471E23A6850 for ; Wed, 30 Jun 2010 09:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 Vo9WzFhiUvJx for ; Wed, 30 Jun 2010 09:19:01 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id E6CC43A6974 for ; Wed, 30 Jun 2010 09:19:01 -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 o5UGJCCs025834; Wed, 30 Jun 2010 09:19:12 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 09:19:07 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-4--1040163350 From: Ron Frederick In-Reply-To: Date: Wed, 30 Jun 2010 09:19:07 -0700 Message-Id: <4AD792A7-029D-4042-AEFF-8354CE577818@bluecoat.com> References: To: Mark Day X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 30 Jun 2010 16:19:07.0782 (UTC) FILETIME=[F7312260:01CB186F] 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: Wed, 30 Jun 2010 16:19:03 -0000 --Apple-Mail-4--1040163350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 28, 2010, at 7:13 PM, Mark Day wrote: > 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. > =20 > 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. 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? --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-4--1040163350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 28, 2010, at 7:13 PM, Mark Day = wrote:
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.

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
=

= --Apple-Mail-4--1040163350-- From Mark.Day@riverbed.com Wed Jun 30 11:23:02 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 BEBD23A6921 for ; Wed, 30 Jun 2010 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] 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 L5zOkI1M1+kh for ; Wed, 30 Jun 2010 11:23:00 -0700 (PDT) Received: from smtp1.riverbed.com (incomingmail.riverbed.com [208.70.196.45]) by core3.amsl.com (Postfix) with ESMTP id 4BDDD3A6AA4 for ; Wed, 30 Jun 2010 11:23:00 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 30 Jun 2010 11:23:11 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.205.165]) with mapi; Wed, 30 Jun 2010 11:23:11 -0700 From: Mark Day To: Ron Frederick Date: Wed, 30 Jun 2010 11:23:08 -0700 Thread-Topic: [middisc] Poll re vendor ID format Thread-Index: AcsYb/rVJsVg+W3MTRS+8/48OQMv+gAENv4Q Message-ID: References: <4AD792A7-029D-4042-AEFF-8354CE577818@bluecoat.com> In-Reply-To: <4AD792A7-029D-4042-AEFF-8354CE577818@bluecoat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD59A6ADMAILBOXES2nbtte_" MIME-Version: 1.0 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: Wed, 30 Jun 2010 18:23:02 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD59A6ADMAILBOXES2nbtte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 m= andatory overhead, I think it's the right solution. --Mark From: Ron Frederick [mailto:ronf@bluecoat.com] Sent: Wednesday, June 30, 2010 12:19 PM To: Mark Day Cc: middisc@ietf.org Subject: Re: [middisc] Poll re vendor ID format On Jun 28, 2010, at 7:13 PM, Mark Day wrote: 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 foll= owed, it essentially becomes option 2, but it leaves open the door for vend= ors 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 byt= e. 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. In this design, what are your thoughts on handing the OUI case? Would you r= equire the type byte in that case (just as we would for standard options wh= ere the vendor ID was 0x00) and put the OUI field after it? -- Ron Frederick ronf@bluecoat.com --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD59A6ADMAILBOXES2nbtte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I guess so.  Not exactly elegant conceptually, I a= dmit. 

 

But if the goal is to have the type byte in a predictable pl= ace across all standard, vendor-ID & OUI usages, while minimizing the numbe= r of bytes of mandatory overhead, I think it’s the right solution.  <= o:p>

 

--Mark

 

From: Ron Frederick [mailto:ronf@bluecoat.com]
Sent: Wednesday, June 30, 2010 12:19 PM
To: Mark Day
Cc: middisc@ietf.org
Subject: Re: [middisc] Poll re vendor ID format

 

On Jun 28, 2010, at 7:13 PM, Mark Day wrote:

If option 2 is unacceptable, I would argue to mak= e the presence of a vendor-specific type byte which immediately follows the vendo= r 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 sc= heme 1 and scheme 2.  Either way, as long as the second byte usage is sugge= sted rather than mandated.

 

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

 

--_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11BD59A6ADMAILBOXES2nbtte_--