RE: Summary of the TGi OUI Discussion
David,
Personally I think the "byte and escape" mechanism could be used in this
case, but I'd like to hear other opinions.
It would mean less shared code between 802.11 and WPA implementations,
which means more bugs, which is a real cost to users.
Whether the (small?) benefit outweighs that (small) cost is something I
don't have a strong opinion on.
Mike Moreton
Synad Technologies Ltd.
-----Original Message-----
From: David V James [mailto:dvj@alum.mit.edu]
Sent: 07 October 2003 09:39
To: Mike Moreton
Cc: stds-802-11@ieee.org; IEEE 802.1; stds-rac@ieee.org;
stds-802-sec@ieee.org
Subject: RE: Summary of the TGi OUI Discussion
Mike,
A couple of observations that might be helpful.
>> On the second issue, I think the (possibly unstated) concern is that
use
>> of EUI-64 will significantly increase the length of the already
>> over-long 802.11 beacon.
1) I haven't seen anyone argue that an EUI-48 couldn't be used in
this application of low-usage protocol identifiers.
2) Some other standards have avoided this overhead by using standard
specific codes (something between 1 nibble and 2 bytes) for assigned
standard-specific identifiers, using one of these codes as an
escape that allows identification of longer vendor-dependent codes.
Could that be applicable in your instance?
(I don't know the details well enought to know).
Anyway, a few thoughts that might be helpful.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-rac@majordomo.ieee.org
>> [mailto:owner-stds-rac@majordomo.ieee.org]On Behalf Of Mike Moreton
>> Sent: Tuesday, October 07, 2003 1:12 AM
>> To: stds-802-11@ieee.org; IEEE 802.1; stds-rac@ieee.org;
>> stds-802-sec@ieee.org
>> Subject: Summary of the TGi OUI Discussion
>>
>>
>>
>> I'm going to attempt to summarise the discussion, and the open
>> questions.
>>
>> It seems there are two major issues here.
>>
>> (1) TGi's use of 0-0-0 as a special value to identify suite selectors
>> assigned by them in the standard itself. Leaving aside the rights
and
>> wrongs of this, it is clear that there are individuals who feel very
>> strongly that this is the wrong thing to do and that it must be
fixed.
>>
>> (2) The use of a four byte cipher selector including a three byte
OUI.
>> The opinion has been expressed that an EUI should be used instead.
EUIs
>> (according to the tutorial) give a much larger "address space" for
>> company allocated values.
>>
>> On the first issue, given the strength of feeling, does anyone
actually
>> object to changing this value? And if no-one objects to that, does
>> anyone object to TGi simply asking the RAC to tell them which value
to
>> use?
>>
>> On the second issue, I think the (possibly unstated) concern is that
use
>> of EUI-64 will significantly increase the length of the already
>> over-long 802.11 beacon. It's also arguable that the last thing we
want
>> to do as a standards body is to encourage the use of huge numbers of
>> different (and incompatible) cipher suites. While we have to be
>> realistic and accept the need for vendor defined suites, we shouldn't
>> necessarily go out of our way to make it easy for them to be added.
>> What do people think?
>>
>>
>> Mike Moreton
>> Synad Technologies Ltd.
>>
>>