Reference record for OID 1.3.6.1.4.1.10126.99


parent
1.3.6.1.4.1.10126 (10126)
node code
99
node name
99
dot oid
1.3.6.1.4.1.10126.99
asn1 oid
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 10126(10126) 99(99)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprises(1) 10126(10126) 99(99)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) 10126(10126) 99(99)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) 10126(10126) 99(99)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 10126(10126) 99(99)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprises(1) 10126(10126) 99(99)}
  • iri oid
  • /iso/identified-organization/dod/internet/private/enterprise/10126/99
  • /iso/identified-organization/dod/internet/private/enterprises/10126/99
  • /iso/org/dod/internet/private/enterprise/10126/99
  • /iso/org/dod/internet/private/enterprises/10126/99
  • /iso/iso-identified-organization/dod/internet/private/enterprise/10126/99
  • /iso/iso-identified-organization/dod/internet/private/enterprises/10126/99
  • iri by oid_info
    /ISO/Identified-Organization/6/1/4/1/10126/99

    Description by oid_info

    Test (WARNING: this subtree will be deleted in due course -- see below)
    View at oid-info.com

    Information by oid_info

    Email received from Peter Gietz on May 2, 2005 (Peter confirmed on Jan. 7, 2008, that this information was still valid):
    -----
    In our experimental LDAP Schema Registry Service we collected all LDAP-Schema elements published in IETF RFCs.
    In some cases, the correct OIDs hadn't been found in the RFCs (although, as I now rechecked, they could have been found). In these cases our programmer used the OID tree in question:
    {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 10126 99}
    because the design of the registry demanded that every element has an OID. We are currently revisiting the problem and will try to find all missing OIDs so we can delete all references to that .99-Tree.
    Thus we are talking about a work around, around a mistake in the data of an experimental service. I doubt that it would be a good idea to really register that tree in your service. But on the other side it is a valid oid, registered by us for a specific purpose. A more interesting subtree below our enterprise.10126-tree is the subtree enterprise.10126.1, where we register the oids for LDAP schema that we have defined, at least one of them will be included into our schema registry, since it is published as Internet Draft at IETF and will be published as informational RFC.
    To summarize: Although I don't think the .99 Subtree of enterprise.10126 is useful to register at your service, I wouldn't mind to have it kept until we excluded all references to the .99-Subtree in our service.
    -----

    First Registration Authority (recovered by parent 1.3.6.1.4.1.10126)

    Peter Gietz

    Children (3)

    OIDNameSub childrenSub Nodes TotalDescription
    1.3.6.1.4.1.10126.99.0 0 1 63 ???
    1.3.6.1.4.1.10126.99.3 3 6 6 ???
    1.3.6.1.4.1.10126.99.4 4 2 2 ???