本主題說明在 SNMP v1 和 v2 中定義的數種類型。
您可以尋找下列區段中說明的物件資訊，方法是選取「MIB 模組」視圖中的模組，然後在「OID 樹狀結構」視圖的搜尋欄位中搜尋 ifIndex。在「OID 樹狀結構」階層中按一下 ifIndex 物件，以查看「詳細資料」視圖中的物件資訊與文字使用慣例資訊。
OBJECT IDENTIFIER 是由 SNMP v1 定義，並且是 MIB 樹狀結構的主要建置區塊。 物件 ID 類似於書籍中的章節標題，不包含自己的真實資料，但會向您提供其後代傳達的內容種類相關概念。
OBJECT TYPE 由 SNMP v1 定義，且用來作為儲存器以儲存受管理裝置或裝置上某個測量值的相關資訊。
TEXTUAL-CONVENTION (TC) 是物件類型定義，而非實際物件。在「MIB 模組」 視圖中，您可以從視圖清單選取文字使用慣例，來查看顯示在 MIB 樹狀結構中的已剖析文字使用慣例。在 MIB 樹狀結構中選取 TC 名稱以在「詳細資料」視圖中顯示其定義。
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1ENTERPRISE 區段定義哪個物件是設陷的母項。然而，MIB 樹狀結構物件可使用 bgp 定義成母項，並定義成編號為 1 的子項。實際上，在 RFC1269-MIB 模組中，bgpVersion 是定義為 { bgp1}。因此，無法使用 ENTERPRISE 作為母項，將 v1 設陷新增至 MIB 樹狀結構作為葉節點。
SNMP v2 會將 TRAP-TYPE 的定義變更為 NOTIFICATION-TYPE，並指定這個新的 v2 設陷會像其他 MIB 物件那樣定義，使用母項及子項號碼讓它成為 v1 設陷的唯一問題。RFC1155 4.1 節定義使用零 (0) 作為子項號碼是無效的，會保留供將來使用。SNMP v2 會利用該零，方式是容許供應商將其 v1 設陷新增至 v2 MIB、將零新增至企業名稱，然後在零後面新增設陷號碼。因此，若為 v2，合適的做法是將具有零的物件 ID 定義為企業的子項，然後將 v1 設陷新增為該零的子項。
這個使用慣例已導致 MIB 作者犯的其他一般錯誤。RFC1155 第 4 節陳述下列內容：
"An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } 使用 v1 設陷或 v2 通知傳送的物件稱為 varbind。varbind 包含已報告事件的其他相關資訊。在 v1 設陷中，varbind 是在 VARIABLES 區段中進行項目化，而在 v2 通知中，varbind 列在 OBJECTS 區段。在所有版本的 SNMP 中，它們的用途都相同。varbind 出現在清單中的順序很重要，因為 PDU（SNMP 封包）會以 varbind 列在 MIB 中的相同順序來編碼關聯的值。
例如，在 OBJECTS 區段中，已指定下列三個 varbind：ifIndex、ifAdminStatus 和 ifOperStatus。因此，ifIndex 是第一個要編碼的 varbind，ifAdminStatus 是第二個，而 ifOperStatus 是第三個要編碼的 varbind。檢查 IF-MIB 可以發現 ifIndex 物件類型定義為 InterfaceIndex。因為這不是 SNMP 的有效初始 ASN.1 類型，它必須是文字使用慣例。搜尋文字使用慣例可以發現 InterfaceIndex 實際上會解析為 Integer32（32 位元整數）。因此，當 PDU 到達 MIB Manager 時，第一個 varbind 將會是整數。若要確定該整數的意思，MIB Manager 必須參照 IF-MIB 模組、查閱 ifIndex 並讀取關聯的物件資訊。檢查第二個 varbind 可以發現列舉的整數類型：
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }當 varbind 從 SNMP 封包解碼時，其值將為整數，必須根據此列舉清單中的項目來解譯其值。當使用 MIB Manager 來建立規則檔時，它將會建立一個參考表，以自動將列舉的整數與其文字呈現鏈結在一起。第三個 varbind 同樣是具有相同值的列舉類型。因此，如果 ifAdminStatus 是 1（開啟），而 ifOperStatus 是 2（關閉），則可以知道事件產生的原因，並且可以繼續嘗試確定此中斷的原因。
Varbind 在規則檔中向使用者呈現為 $1、$2、$3，以此類推，每個號碼代表一個 varbind 號碼。MIB Manager 根據 varbind 元素來建立元素，並使用這些元素來在詳細資料表格中設定變數。例如，詳細資料表格中使用的元素可能為 $ifIndex = $1（這將是一個整數）、$ifAdminStatus = $2（這將為上標 (1) 之類的內容）和 $ifOperStatus = $3（這將為下標 (3) 之類的內容）。透過使用「Netcool 知識庫 (NCKL)」設定的使用慣例，將對物件設定的所有變更自動設定在規則檔中。
Table 代表具有資料列和資料欄之多維度陣列的對等項目。Table 物件定義為 Entry 物件的 SEQUENCE。Entry 物件隨後定義為 OBJECT-TYPE 物件的 SEQUENCE。供應商偶爾會設計不常用系統，例如 Cisco 10k 路由器。 這個裝置會維護警示狀況的內部表格，並在表格變更時產生設陷或通知。您必須隨後在表格內容上發出 SNMP GET 要求，來判定裝置上作用中警示的現行狀態。這會讓 SNMP 管理程式不易取得警示，但是並非不可能（如果管理者具有符合的工具的話）。
八位元組是包含 8 個位元（通常稱為一個位元組）的資料結構。OCTET STRING 是位元組陣列（或位元組字串）。OCTET STRING 術語並未暗示字串中的所有位元組都是英數。它們還可以是二進位字元，並用來作為位元遮罩。