The private subtree is used to identify object types defined unilaterally. NEMA assigns nodes to enterprises for purposes such as defining enterprise-specific MIB modules. A request for a node assignment can be sent to the NTCIP Coordinator at ntcip@nema.org. When a sub-node is assigned, the responsibility for managing that sub-node is transferred to the enterprise making the request. Upon receiving a node, the enterprise may, for example, define new MIB modules and object types under this node. In addition, it is strongly recommended that the enterprise also register its transportation devices under this subtree, to provide an unambiguous identification mechanism for use in management protocols. For example, if the 'ABC, Inc.' enterprise produced transportation devices, then it could request a node under the nemaPrivate node from NEMA. Such a node might be numbered: 1.3.6.1.4.1.1206.3.99 The 'ABC, Inc.' enterprise might then register their 'Widget Controller' under the name of 1.3.6.1.4.1.1206.3.99.1, ensuring a unique identification. Thereafter, each enterprise is responsible for ensuring unique identification of information objects within their subtree. NEMA delegates the role of assigning numbers under each nemaPrivate node to those to which they are assigned, except of course for the initial enterprise number.
OID reference
nemaPrivate
1.3.6.1.4.1.1206.3
Description
The private subtree is used to identify object types defined unilaterally. NEMA assigns nodes to enterprises for purposes such as defining enterprise-specific MIB modules. A request for a node assignment can be sent to the NTCIP Coordinator at ntcip@nema.org. When a sub-node is assigned, the responsibility for managin…
Identification
Identifier and names
- Parent
- 1.3.6.1.4.1.1206 (1206, nema)
- Node code
- 3
- Node name
- nemaPrivate
- Numeric OID
- 1.3.6.1.4.1.1206.3
- URN notation
- urn:oid:1.3.6.1.4.1.1206.3
ASN.1, OID-IRI and named path variants
- ASN.1 notation
-
{1 3 6 1 4 1 1206 3}
- {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprises(1) nema(1206) nemaPrivate(3)}
- {iso(1) identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) nema(1206) nemaPrivate(3)}
- {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) nema(1206) nemaPrivate(3)}
- {iso(1) org(3) dod(6) internet(1) private(4) ldap-enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) org(3) dod(6) internet(1) private(4) vendor-objects(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprises(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprises(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) nema(1206) nemaPrivate(3)}
- {iso(1) iso-organization(3) dod(6) internet(1) private(4) vendor-objects(1) nema(1206) nemaPrivate(3)}
- OID-IRI notation
- /1/3/6/1/4/1/1206/3
- /ISO/Identified-Organization/6/1/4/1/1206/3
- /ISO/3/6/1/4/1/1206/3
- Named path variants
- /iso/identified-organization/dod/internet/private/enterprise/1206/nemaPrivate
- /iso/identified-organization/dod/internet/private/enterprise/nema/nemaPrivate
- /iso/identified-organization/dod/internet/private/enterprises/1206/nemaPrivate
- /iso/identified-organization/dod/internet/private/enterprises/nema/nemaPrivate
- /iso/identified-organization/dod/internet/private/ldap-enterprise/1206/nemaPrivate
- /iso/identified-organization/dod/internet/private/ldap-enterprise/nema/nemaPrivate
- /iso/identified-organization/dod/internet/private/vendor-objects/1206/nemaPrivate
- /iso/identified-organization/dod/internet/private/vendor-objects/nema/nemaPrivate
- /iso/org/dod/internet/private/enterprise/1206/nemaPrivate
- /iso/org/dod/internet/private/enterprise/nema/nemaPrivate
- /iso/org/dod/internet/private/enterprises/1206/nemaPrivate
- /iso/org/dod/internet/private/enterprises/nema/nemaPrivate
- /iso/org/dod/internet/private/ldap-enterprise/1206/nemaPrivate
- /iso/org/dod/internet/private/ldap-enterprise/nema/nemaPrivate
- /iso/org/dod/internet/private/vendor-objects/1206/nemaPrivate
- /iso/org/dod/internet/private/vendor-objects/nema/nemaPrivate
- Additional combinations skipped.
Published definitions
Available source records contain 2 distinct definitions; some records may not include a definition.
Show 2 published definitions
nemaPrivate · current
nemaPrivate OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The private subtree is used to identify object types defined unilaterally.
NEMA assigns nodes to enterprises for purposes such as defining
enterprise-specific MIB modules. A request for a node assignment can be
sent to the NTCIP Coordinator at ntcip@nema.org. When a sub-node is
assigned, the responsibility for managing that sub-node is transferred to
the enterprise making the request.
Upon receiving a node, the enterprise may, for example, define new MIB
modules and object types under this node. In addition, it is strongly
recommended that the enterprise also register its transportation devices
under this subtree, to provide an unambiguous identification mechanism for
use in management protocols. For example, if the 'ABC, Inc.' enterprise
produced transportation devices, then it could request a node under the
nemaPrivate node from NEMA. Such a node might be numbered:
1.3.6.1.4.1.1206.3.99
The 'ABC, Inc.' enterprise might then register their 'Widget Controller'
under the name of 1.3.6.1.4.1.1206.3.99.1, ensuring a unique
identification. Thereafter, each enterprise is responsible for ensuring
unique identification of information objects within their subtree. NEMA
delegates the role of assigning numbers under each nemaPrivate node to
those to which they are assigned, except of course for the initial
enterprise number."
::= { nema 3 }nemaPrivate · unspecified
nemaPrivate OBJECT IDENTIFIER ::= { nema 3 }
Meaning
Descriptions
Identical descriptions are grouped. Different wording and device-specific notes are retained.
Evidence
Source records
Matching descriptions are grouped; open a group to compare definitions and supporting files.
Records for description 1ITE public NTCIP working repository MIBs
nemaPrivate · currentITE public NTCIP working repository MIBs
Status in source: current.
Names: nemaPrivate
Technical details
{
"smi_kind": "OBJECT-IDENTITY",
"definition": [
"nemaPrivate",
"OBJECT-IDENTITY",
"STATUS",
"current",
"DESCRIPTION",
"\"The private subtree is used to identify object types defined unilaterally. NEMA assigns nodes to enterprises for purposes such as defining enterprise-specific MIB modules. A request for a node assignment can be sent to the NTCIP Coordinator at ntcip@nema.org. When a sub-node is assigned, the responsibility for managing that sub-node is transferred to the enterprise making the request. Upon receiving a node, the enterprise may, for example, define new MIB modules and object types under this node. In addition, it is strongly recommended that the enterprise also register its transportation devices under this subtree, to provide an unambiguous identification mechanism for use in management protocols. For example, if the 'ABC, Inc.' enterprise produced transportation devices, then it could request a node under the nemaPrivate node from NEMA. Such a node might be numbered: 1.3.6.1.4.1.1206.3.99 The 'ABC, Inc.' enterprise might then register their 'Widget Controller' under the name of 1.3.6.1.4.1.1206.3.99.1, ensuring a unique identification. Thereafter, each enterprise is responsible for ensuring unique identification of information objects within their subtree. NEMA delegates the role of assigning numbers under each nemaPrivate node to those to which they are assigned, except of course for the initial enterprise number.\"",
"::=",
"{",
"nema",
"3",
"}"
],
"syntax_tree": [
[
"Status",
"current"
],
[
"DESCRIPTION",
"The private subtree is used to identify object types defined unilaterally. NEMA assigns nodes to enterprises for purposes such as defining enterprise-specific MIB modules. A request for a node assignment can be sent to the NTCIP Coordinator at ntcip@nema.org. When a sub-node is assigned, the responsibility for managing that sub-node is transferred to the enterprise making the request. Upon receiving a node, the enterprise may, for example, define new MIB modules and object types under this node. In addition, it is strongly recommended that the enterprise also register its transportation devices under this subtree, to provide an unambiguous identification mechanism for use in management protocols. For example, if the 'ABC, Inc.' enterprise produced transportation devices, then it could request a node under the nemaPrivate node from NEMA. Such a node might be numbered: 1.3.6.1.4.1.1206.3.99 The 'ABC, Inc.' enterprise might then register their 'Widget Controller' under the name of 1.3.6.1.4.1.1206.3.99.1, ensuring a unique identification. Thereafter, each enterprise is responsible for ensuring unique identification of information objects within their subtree. NEMA delegates the role of assigning numbers under each nemaPrivate node to those to which they are assigned, except of course for the initial enterprise number."
],
null
]
}- ITE public NTCIP working repository MIBs
· Publisher's source file: NTCIP-8004 — docs/mibs/NTCIP8004-NEMA.mib
Module: NTCIP8004-NEMA
See published definition above
Module imports
{'SNMPv2-SMI': ['MODULE-IDENTITY', 'OBJECT-IDENTITY', 'enterprises']}Source data warning: This original is published in an ITE NTCIP working repository. Repository publication does not establish that this particular revision is an adopted standard. Consult its native revision history and the NTCIP published standards catalog before implementation. Copyright and distribution notices are retained in the downloadable original.
· Download NTCIP-8004 — docs/mibs/NTCIP8004-NEMA.mib
Definitions without a descriptionNTCIP published standard MIB annexes (reviewed modules)
nemaPrivate · unspecifiedNTCIP published standard MIB annexes (reviewed modules)
Status in source: unspecified.
Names: nemaPrivate
Technical details
{
"smi_kind": "OBJECT IDENTIFIER",
"definition": [
"nemaPrivate",
"OBJECT",
"IDENTIFIER",
"::=",
"{",
"nema",
"3",
"}"
]
}- NTCIP published standard MIB annexes (reviewed modules)
· Publisher's source file: NTCIP 8004 v02, Structure and Identification of Management Information (SMI) Published June 2010 — original PDF
· Official record
Module: NTCIP8004v02
See published definition above
Module imports
{'RFC1155-SMI': ['enterprise'], 'RFC1213-MIB': ['DisplayString']}Source data warning: This record is transcribed from a published NTCIP MIB annex. The downloadable text is a derived transcription with page furniture and section headings masked; the unmodified original PDF is authoritative. Native definitions, DESCRIPTION and STATUS are retained. A published object definition does not establish support by any particular device.
Source data warning: The normative Annex A.2 comments the DEFINITIONS header while printing explicit OBJECT IDENTIFIER assignments below it. Activate only that parser header in a same-length derived copy; no OID expression or numeric arc is changed. Literal source definitions and the complete PDF remain available.
Source data warning: Potentially inaccurate interpretation of historical NTCIP namespace references: RFC1155-SMI, missing or unreadable imports of protocols. These exact source files require the reviewed bindings shown below. The numeric roots used here are the explicit assignments in normative Annex A.2 of published NTCIP 8004 v02 (2010), physical pages 43–44. This does not establish that every historical module revision is identical. The annex also prints enterprise instead of RFC 1155 enterprises and declares Protocols while referencing protocols; those spelling interpretations are disclosed. The original IMPORTS, numeric suffixes and definitions remain unchanged. Verify both originals before implementation.
· Download NTCIP8004v0217r.pdf — NTCIP8004v02 (MIB transcription)Related source files and packages:
- NTCIP 8004 v02, Structure and Identification of Management Information (SMI) Published June 2010 — original PDF
- RFC 1155 — original SMI enterprise namespace
- NTCIP8004-NEMA.mib — ITE namespace dependency
Show more related files and packages
- NTCIP published standard MIB annexes (reviewed modules)
· Publisher's source file: NTCIP 1101:1996, Simple Transportation Management Framework Published December 2001 (Rescinded) — original PDF
· Official record
Module: NEMA_SMI
Same published definition (formatting differs; exact original is in the source file)
Source data warning: Recovered from a file whose complete MIB does not parse. The original assignment and definition are preserved. Registration and implementation details may be inaccurate; consult the original file. Other damaged or unresolved declarations are not established registrations.
Source data warning: This record is transcribed from a published NTCIP MIB annex. The downloadable text is a derived transcription with page furniture and section headings masked; the unmodified original PDF is authoritative. Native definitions, DESCRIPTION and STATUS are retained. A published object definition does not establish support by any particular device.
Source data warning: Potentially inaccurate interpretation of historical NTCIP namespace references: missing or unreadable imports of enterprises. These exact source files require the reviewed bindings shown below. The numeric roots used here are the explicit assignments in normative Annex A.2 of published NTCIP 8004 v02 (2010), physical pages 43–44. This does not establish that every historical module revision is identical. The annex also prints enterprise instead of RFC 1155 enterprises and declares Protocols while referencing protocols; those spelling interpretations are disclosed. The original IMPORTS, numeric suffixes and definitions remain unchanged. Verify both originals before implementation.
· Download NTCIP1101Rescinded-2006.pdf — NEMA_SMI (MIB transcription) - NTCIP published standard MIB annexes (reviewed modules)
· Publisher's source file: NTCIP 8004 v01, Structure and Identification of Management Information (SMI) Published May 2008 (superceded by NTCIP 8004 v02) — original PDF
· Official record
Module: NTCIP8004-v01-2008
Module imports
{'RFC1155-SMI': ['enterprises'], 'RFC1213-MIB': ['DisplayString']}Source data warning: This record is transcribed from a published NTCIP MIB annex. The downloadable text is a derived transcription with page furniture and section headings masked; the unmodified original PDF is authoritative. Native definitions, DESCRIPTION and STATUS are retained. A published object definition does not establish support by any particular device.
Source data warning: The normative namespace annex prints a module label with a space. Use an equal-length internal parsing label only; all explicit OBJECT IDENTIFIER assignments, numbers and the literal original PDF remain unchanged. This internal label is not an OID registration.
· Download NTCIP8004v0138r.pdf — NTCIP8004-v01-2008 (MIB transcription)
Registration
Registration authorities
First Registration Authority (inferred from ancestor 1.3.6.1.4.1.1206)
Siblings (3)
| OID | Name | Direct children | Descendants | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.1206.1 | nemaMgmt | 0 | 0 | |
| 1.3.6.1.4.1.1206.2 | nemaExperimental | 2 | 28 | |
| 1.3.6.1.4.1.1206.4 | transportation | 5 | 4282 |