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

RE: [802.1] TGi use of OUI 00-00-00




David,

I don't think that assigning an OUI to "the body that standardises the
protocol in which the OUI is used" means that the IEEE/RAC needs to
understand the different contexts.  That's up to the body that does each
standardisation.

For example, 802.11 know that they are the only people who define the
cipher suite selector field in the 802.11i RSN information element, so
it's reasonable for them to make use of this value for pre-defined
values of that field.  It wouldn't be reasonable for any other body to
make use of that value in that field, but it would be reasonable for
them to make use of it in a field they defined in one of their own
messages.

However, if people prefer unique to be really unique then fine.  I was
just pointing out that it wasn't theoretically necessary.

What I was saying about the TGi use is that in practice the OUI can be
followed by an almost arbitrary length byte stream (I'm glossing over
the detail) in a format defined by the owner of the OUI.  That means
that if an OUI owner wants to have a sub-structure of identifiers within
the byte stream, then it's up to them.  But equally, if another OUI
owner wants no sub-structure, and just a single byte, that will work as
well.

The mechanism is inefficient for the unusual case where a sub-structure
is required, but efficient for the common case where no sub-structure is
needed.  I think that's quite a desirable characteristic.

Mike Moreton
Synad Technologies Ltd.
 

-----Original Message-----
From: David V James [mailto:dvj@alum.mit.edu] 
Sent: 06 October 2003 16:10
To: Mike Moreton; CONGDON,PAUL (HP-Roseville,ex1); Geoff Thompson
Cc: Tony Jeffree; Johnston, Dj; David Halasz; stds-802-11@ieee.org; IEEE
802.1; stds-rac@ieee.org; stds-802-sec@ieee.org;
millardo@dominetsystems.com
Subject: RE: [802.1] TGi use of OUI 00-00-00

Mike,

A couple of refinements:


>> (1) I don't think that 802 need to be allocated an OUI.  All that
needs
>> happen is that an OUI be allocated for use by "the body that
>> standardises the protocol in which the OUI is used".  So in this
case,
>> TGi could make use of the OUI, as the field in question is in a TGI
>> defined message, while the IETF could use exactly the same value in a
>> message that they defined.  The context means that there is no chance
of
>> confusion.

Unique numbers should be unique, period. Reuse of the same number,
in a different context, would require the IEEE/RAC and requesters
to become experts at defining distinct "context". Such expertist is not
necessary if all unique numbers are unique, despite the context.
The applicable IEEE/RAC policy statement is online:

http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html
However, duplication within each of these spaces is forbidden.
For example, the EUI-48 values that specify I/O driver software
interfaces,
language codes, and hardware model numbers shall never overlap.
This no-overlap strategy is expected to reduce unintentional duplication
of EUI-48 values, by elimination of subjective application-class
judgments,
although a few more EUI-48 values may be consumed.



>> (2) With the TGi format it is possible for an organisation to use an
>> (almost) arbitrarily long internal structure that is not limited to
one
>> byte, or even five.  It's not obvious, and it's not terribly
efficient,
>> but I would say that's a reasonable trade-off if it makes all the
most
>> likely uses more efficient.

Relying on the organisation to define the proper subassignment
authorities is a risky business and has already resulted in several
failures. The applicable IEEE/RAC policy statement is online:

http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html
The 24-bit OUI/company_id value is intended to identify the
organization that administers the remaining bits in
EUI-48 and EUI-64 values. The OUI/company_id value should not
be used (in isolation) to identify a vendor or the format of
vendor-dependent information. When necessary to identify the
vendor of a hardware device, an EUI-48 identifier should be used.
This allows large organizations to assign distinct EUI-48
identifiers, so that each division can be identified as a
distinct "vendor". Alternatively, small groups within an SDO
(standards development organization) could be identified by
distinct EUI-48 identifiers administered by their sponsoring body.


Also, please note that the OUI of an EUI-48 or EUI-64 is not
necessarily the OUI of the company that build the product.
Its simply the OUI of the company that assigned the remaining
dependent bits. Thus, your original statement that the IEEE 802
group doesn't need an OUI to define standards is true: a standard
only needs to find an OUI-assigned group willing to assign one
of their EUI-48 identifiers for this purpose. 


Respectfully,
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: Mike Moreton [mailto:Mike.Moreton@synad.com]
>> Sent: Monday, October 06, 2003 2:35 AM
>> To: David V James; CONGDON,PAUL (HP-Roseville,ex1); Geoff Thompson
>> Cc: Tony Jeffree; Johnston, Dj; David Halasz; stds-802-11@ieee.org;
IEEE
>> 802.1; stds-rac@ieee.org; stds-802-sec@ieee.org;
>> millardo@dominetsystems.com
>> Subject: RE: [802.1] TGi use of OUI 00-00-00
>> 
>> 
>> David,
>> 
>> A couple of comments on your points:
>> 
>> (1) I don't think that 802 need to be allocated an OUI.  All that
needs
>> happen is that an OUI be allocated for use by "the body that
>> standardises the protocol in which the OUI is used".  So in this
case,
>> TGi could make use of the OUI, as the field in question is in a TGI
>> defined message, while the IETF could use exactly the same value in a
>> message that they defined.  The context means that there is no chance
of
>> confusion.
>> 
>> (2) With the TGi format it is possible for an organisation to use an
>> (almost) arbitrarily long internal structure that is not limited to
one
>> byte, or even five.  It's not obvious, and it's not terribly
efficient,
>> but I would say that's a reasonable trade-off if it makes all the
most
>> likely uses more efficient.
>> 
>> Mike Moreton
>> Synad Technologies Ltd.
>>  
>> 
>> -----Original Message-----
>> From: David V James [mailto:dvj@alum.mit.edu] 
>> Sent: 06 October 2003 06:26
>> To: CONGDON,PAUL (HP-Roseville,ex1); 'Geoff Thompson'; Mike Moreton
>> Cc: Tony Jeffree; Johnston, Dj; David Halasz; stds-802-11@ieee.org;
IEEE
>> 802.1; stds-rac@ieee.org; stds-802-sec@ieee.org;
>> millardo@dominetsystems.com
>> Subject: RE: [802.1] TGi use of OUI 00-00-00
>> 
>> Paul,
>> 
>> There are sort-of two questions here, I think.
>> 
>> 1) Can an organization/standard get an OUI?
>>    Yes. One should be sufficient for all of 802.
>>    I know the MSC has one, I suspect that 802
>>    already has one.
>> 
>> 2) Is a single OUI sufficient to identify the
>>    format and function of organizationally-specific data?
>>    (if this happens to be applicable).
>>    No. An EUI-48 or EUI-64 serves this need.
>>    See extact below.
>> 
>> http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html
>> The 24-bit OUI/company_id value is intended to identify the
>> organization that administers the remaining bits in
>> EUI-48 and EUI-64 values. The OUI/company_id value should not
>> be used (in isolation) to identify a vendor or the format
>> of vendor-dependent information. When necessary to identify
>> the vendor of a hardware device, an EUI-48 identifier
>> should be used. This allows large organizations to assign
>> distinct EUI-48 identifiers, so that each division can be
>> identified as a distinct "vendor". Alternatively, small groups
>> within an SDO (standards development organization) could be
>> identified by distinct EUI-48 identifiers administered by
>> their sponsoring body.
>> 
>> DVJ
>> IEEE/RAC member
>> 
>> 
>> 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
CONGDON,PAUL
>> >> (HP-Roseville,ex1)
>> >> Sent: Sunday, October 05, 2003 10:07 PM
>> >> To: 'Geoff Thompson'; Mike Moreton
>> >> Cc: Tony Jeffree; Johnston, Dj; David Halasz;
stds-802-11@ieee.org;
>> IEEE
>> >> 802.1; stds-rac@ieee.org; stds-802-sec@ieee.org;
>> >> millardo@dominetsystems.com
>> >> Subject: RE: [802.1] TGi use of OUI 00-00-00
>> >>
>> >>
>> >>
>> >>
>> >> Throughout this discussion, there has been suggestion of
allocating a
>> >> 'no-vendor' OUI?  Why is this necessary?  Why doesn't OUI imply
>> >> 'Organizational Unique Identifier' such as 802.11 or 802.1 or
802.3?
>> Why
>> >> can't these 'Organizations' have an OUI?   I keep hearing words
about
>> >> commercial entities (aka businesses) having to be responsible
>> >> for OUIs.   It
>> >> would seem to make sense to me for 802.11 to ask for an OUI that
>> >> they could
>> >> use to identify cipher suites (and other things) that they define.
>> >>
>> >> Paul
>> >>
>> 
>>