RE: [802.1] Summary of the TGi OUI Discussion
I'd suggest 802.11 getting their own OUI for this and also using it for LLDP
attributes if they feel the need to define them someday. The ultimate code
space for both of these is small and doesn't require EUI-48 or EUI-64.
Paul
> -----Original Message-----
> From: owner-stds-802-1@majordomo.ieee.org
> [mailto:owner-stds-802-1@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: [802.1] 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.
>
>