ISO and the ITU agreed a system of OIDs (Object Identifiers). Such identifiers are needed in various systems which want some way to uniquely identify arbitrary things in a hierarchy, such as the fields in the X.509 certificates for your HTTPS servers, nodes in your SNMP system, and DICOM medical image data.
To mint new OIDs you need a parent OID from which you can just branch off children. So for example if you owned 5.6.7.8 then you're entitled to make 5.6.7.8.9 but also 5.6.7.8.1, 5.6.7.8.2, 5.6.7.8.4261 and so on, and they in turn can have children of their own, maybe 5.6.7.8.4261.8302048.1.384823.5 ends up existing. But how can you get such an arc in the first place? ISO and ITU issued themselves initial numbers 0, 1 and 2 and they in turn issued some prominent international entities their own arcs, to e.g. the US Department of Defence.
The IETF understandably wanted to issue OIDs, but in the early days it wasn't obvious who should issue an arc to them. So, some authors wrote an RFC which just "presumes" the US Department of Defence (owners of the 1.3.6 arc) will issue 1.3.6.1 to the IETF. No such formal issuance occurred, but too late, there's an IETF RFC which says the DoD is going to give the IETF the 1.3.6.1 arc so everybody writing RFCs which need OIDs just uses ones from the 1.3.6.1 hierarchy. A successful namespace hijacking is about numbers. If most people who have an opinion think you own 1.3.6.1 then you do, if not, you don't.
Even if today the US DoD actually said "No, we decided you can't have it" that wouldn't be effective, way more people care what the IETF thinks about this.
probably it would be better to use 48 bits of a sha-256 of a specification document to identify a namespace within which your oids are defined, then serial numbers plus a pointer to that namespace identifier for the individual oids. in the usual case where you have less than 15 oid namespaces in an snmp packet or whatever the fuck, the namespace identifier in a particular oid eats just four bits
48 bits is short enough that intentional collisions are eminently feasible but long enough that unintentional collisions are vanishingly unlikely, and as you point out, the whole way the space works depends on everyone trying to avoid collisions anyway
ISO and the ITU agreed a system of OIDs (Object Identifiers). Such identifiers are needed in various systems which want some way to uniquely identify arbitrary things in a hierarchy, such as the fields in the X.509 certificates for your HTTPS servers, nodes in your SNMP system, and DICOM medical image data.
To mint new OIDs you need a parent OID from which you can just branch off children. So for example if you owned 5.6.7.8 then you're entitled to make 5.6.7.8.9 but also 5.6.7.8.1, 5.6.7.8.2, 5.6.7.8.4261 and so on, and they in turn can have children of their own, maybe 5.6.7.8.4261.8302048.1.384823.5 ends up existing. But how can you get such an arc in the first place? ISO and ITU issued themselves initial numbers 0, 1 and 2 and they in turn issued some prominent international entities their own arcs, to e.g. the US Department of Defence.
The IETF understandably wanted to issue OIDs, but in the early days it wasn't obvious who should issue an arc to them. So, some authors wrote an RFC which just "presumes" the US Department of Defence (owners of the 1.3.6 arc) will issue 1.3.6.1 to the IETF. No such formal issuance occurred, but too late, there's an IETF RFC which says the DoD is going to give the IETF the 1.3.6.1 arc so everybody writing RFCs which need OIDs just uses ones from the 1.3.6.1 hierarchy. A successful namespace hijacking is about numbers. If most people who have an opinion think you own 1.3.6.1 then you do, if not, you don't.
Even if today the US DoD actually said "No, we decided you can't have it" that wouldn't be effective, way more people care what the IETF thinks about this.