I have confirmed with the IEEE Registration authority that an open source software project can purchase a CID. Hence, the scheme listed below would seem to work well -- our (logical) vendor ID can be an IEEE OUI or CID, because they hold the desired properties: - they are both 24 bits long - OUIs and CIDs are guaranteed to be unique (both within their respective classes and from each other) - hence, a single 24-bit parameter is suitable for holding either value - IEEE maintains a world-wide registry of both OUIs and CIDs - purchasing a CID is not cost-prohibitive - purchasing a CID for use in this case is appropriate for software vendors (including open source projects)

On Feb 2, 2017, at 10:59 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:

The more I look into this, the more it looks like we should use a CID and/or an OUI.

The CID and OUI are both 24-bit IEEE-maintained numbers.

CID = Company ID. Used for no particular purpose. OUI = Organization Unique ID. Used for Ethernet MAC address space reservation.

While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not. We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space.

It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space.

The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID. Hence:

- all OUIs are distinct from all CIDs, and vice versa - if you care, you can tell if a given 24 bit value is a CID or OUI

It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html

http://standards.ieee.org/develop/regauth/tut/eui.pdf

What I don't know yet is whether an open source software project can buy a CID or not. I have an email in to IEEE asking this question.

...

On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:

On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <[email protected]> wrote:

...

I did not want to mandate a specific length. The way I understand it is that the ID is an integer of some length, where parts can be masked and queried for information.

I think what I was trying to say (poorly) was that I am proposing a *logical* tuple. How long each item is in the tuple, and how we map that to C types are different questions.

Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value.

...

In my last mail, yes, but I do acknowledge that additional fields are necessary. I just asked about the vendor ID, as that is the one mostly regulated, right? The vendors are free to use the remaining bits as they see fit, right?

I would think so.

...

Yes, I read about the OUI. As far as I know, these are _bought_ from and controlled by IEEE. How would an MPI vendor obtain one of those to use for software events from inside the MPI?

Buy one.

-- Jeff Squyres [email protected]

-- Jeff Squyres [email protected]

_______________________________________________ mpiwg-tools mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-- Jeff Squyres [email protected]