Re: [e2md] Problem statement, Requirements and Use Cases

[Tony Rutkowski <[e-mail]>]

Hi Ken,

Just to clarify.
> 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree.  IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated.
>    

This has recently been done for some other namespaces, e.g,
for object tags (2.27), telebiometrics (2.42), cybersecurity
(2.48), and alerting (2.29).  You can peruse the tree at
http://www.oid-info.com/cgi-bin/display?tree=2

The flip side is that a lot of carriers and enterprises exist
in the arcs 0.3 and 1.3.6.1.4 and there are a couple decades
of extensive OID uses, e.g., for SNMP and PKI certs, and
any structured ontology for a new arc would likely include
at least a geographic layer using a 3 number country code
which gets pretty close to the existing Enterprise Number
number count.

> A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number).  But it is not clear to me whether in

What is called an OCN in the North America is known as
an ITU Carrier Code worldwide, and created pursuant to ITU-T Rec.
M.1400.  It's a six character alphanumeric code.  See Annex E.
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.1400-200607-I!!PDF-E&type=items


Another advantage of OIDs includes their widespread
inclusion in X.509 digital certificates.

--tony