Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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