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