RE: [802.1] Summary of the TGi OUI Discussion
Paul,
I'd be much more comfortable with 802.1 offering the use of the 802.1 OUI
for this purpose and both 802.11 and 802.1 approaching the RAC to see if the
IEEE RA could publish any values that have to be assigned after the TGi
standard is done. Just having 802.11 with its own OUI doesn't solve the
problem unless all the derived values that it requires can be determined
prior to sponsor ballot and written in the sponsor ballot standard, and any
addition to the list waits for a revision of the 802.11 standard. Otherwise
there is an ongoing registration authority problem - there have to be
criteria for assignments, a public process, it has to be demonstratively
fair etc. etc. The whole registration authority list. Just having the
capability of an individual organization being able to allocate its own code
doesn't get over the fact that items in the standard list may be viewed as
superior and hence be subject to dispute as to what goes on the list.
Getting this right isn't a completely black art, but the problem is that it
tends to be forgotten as people move, as committees finish work etc., and
then some apparanetly reasonable but different criteria get applied and
disputes become very troublesome. In its allocation of standard group MAC
addresses, 802.1 has a relationship with the RA that ensures that the RA
(not the RAC, but the actual IEEE RA staff, who are permanent employees of
the IEEE not temporary volunteers) fields requests and ensures publication,
and .1 evaluates the standard criteria. This happens often enough that
neither .1 or the RA forgets what is occuring.
Another solution might be not to have a standard standard list at all, but
for an organization (any organization) to donate some starter values that
are acceptable to 802.11. I don't see why they couldn't get written into the
standard, at least as an informative annex. If this works, i.e. does not
trigger any warning bells with those who have registration authority
history, then it might avoid the whole undesirable issue of a new public
registration function. Everyone in .11 would have to be happy with the
likelihood of new "well known" values created by some organization being
sufficiently well known.
Of course, as I said above, if there is no reason to change the list in the
standard except at standard revision time (important, this means no working
group judgments on values between revisions) then any value would do. I
think 802.1 would help, if asked.
Mick
-----Original Message-----
From: owner-stds-rac@majordomo.ieee.org
[mailto:owner-stds-rac@majordomo.ieee.org]On Behalf Of CONGDON,PAUL
(HP-Roseville,ex1)
Sent: Tuesday, October 07, 2003 8:34 AM
To: 'Mike Moreton'; stds-802-11@ieee.org; IEEE 802.1; stds-rac@ieee.org;
stds-802-sec@ieee.org
Subject: 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.
>
>