Node-Red configuration
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

rfc2578.txt 88KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061206220632064206520662067206820692070207120722073207420752076207720782079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112211321142115211621172118211921202121212221232124212521262127212821292130213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172217321742175217621772178217921802181218221832184218521862187218821892190219121922193219421952196219721982199220022012202220322042205220622072208220922102211221222132214221522162217221822192220222122222223222422252226222722282229223022312232223322342235223622372238223922402241224222432244224522462247224822492250225122522253225422552256225722582259226022612262226322642265226622672268226922702271227222732274227522762277227822792280228122822283228422852286228722882289229022912292229322942295229622972298229923002301230223032304230523062307230823092310231123122313231423152316231723182319232023212322232323242325232623272328232923302331233223332334233523362337233823392340234123422343234423452346234723482349235023512352235323542355235623572358235923602361236223632364236523662367236823692370237123722373237423752376237723782379238023812382238323842385238623872388238923902391239223932394239523962397239823992400240124022403240424052406240724082409241024112412241324142415241624172418241924202421242224232424242524262427242824292430243124322433243424352436243724382439244024412442244324442445244624472448244924502451245224532454245524562457245824592460246124622463246424652466246724682469247024712472247324742475247624772478247924802481248224832484248524862487248824892490249124922493249424952496249724982499250025012502250325042505250625072508250925102511251225132514251525162517251825192520252125222523252425252526252725282529253025312532253325342535253625372538253925402541
  1. Network Working Group Editors of this version:
  2. Request for Comments: 2578 K. McCloghrie
  3. STD: 58 Cisco Systems
  4. Obsoletes: 1902 D. Perkins
  5. Category: Standards Track SNMPinfo
  6. J. Schoenwaelder
  7. TU Braunschweig
  8. Authors of previous version:
  9. J. Case
  10. SNMP Research
  11. K. McCloghrie
  12. Cisco Systems
  13. M. Rose
  14. First Virtual Holdings
  15. S. Waldbusser
  16. International Network Services
  17. April 1999
  18. Structure of Management Information Version 2 (SMIv2)
  19. Status of this Memo
  20. This document specifies an Internet standards track protocol for the
  21. Internet community, and requests discussion and suggestions for
  22. improvements. Please refer to the current edition of the "Internet
  23. Official Protocol Standards" (STD 1) for the standardization state
  24. and status of this protocol. Distribution of this memo is unlimited.
  25. Copyright Notice
  26. Copyright (C) The Internet Society (1999). All Rights Reserved.
  27. Table of Contents
  28. 1 Introduction .................................................3
  29. 1.1 A Note on Terminology ......................................4
  30. 2 Definitions ..................................................4
  31. 2.1 The MODULE-IDENTITY macro ..................................5
  32. 2.2 Object Names and Syntaxes ..................................5
  33. 2.3 The OBJECT-TYPE macro ......................................8
  34. 2.5 The NOTIFICATION-TYPE macro ...............................10
  35. 2.6 Administrative Identifiers ................................11
  36. 3 Information Modules .........................................11
  37. 3.1 Macro Invocation ..........................................12
  38. 3.1.1 Textual Values and Strings ..............................13
  39. McCloghrie, et al. Standards Track [Page 1]
  40. RFC 2578 SMIv2 April 1999
  41. 3.2 IMPORTing Symbols .........................................14
  42. 3.3 Exporting Symbols .........................................14
  43. 3.4 ASN.1 Comments ............................................14
  44. 3.5 OBJECT IDENTIFIER values ..................................15
  45. 3.6 OBJECT IDENTIFIER usage ...................................15
  46. 3.7 Reserved Keywords .........................................16
  47. 4 Naming Hierarchy ............................................16
  48. 5 Mapping of the MODULE-IDENTITY macro ........................17
  49. 5.1 Mapping of the LAST-UPDATED clause ........................17
  50. 5.2 Mapping of the ORGANIZATION clause ........................17
  51. 5.3 Mapping of the CONTACT-INFO clause ........................18
  52. 5.4 Mapping of the DESCRIPTION clause .........................18
  53. 5.5 Mapping of the REVISION clause ............................18
  54. 5.5.1 Mapping of the DESCRIPTION sub-clause ...................18
  55. 5.6 Mapping of the MODULE-IDENTITY value ......................18
  56. 5.7 Usage Example .............................................18
  57. 6 Mapping of the OBJECT-IDENTITY macro ........................19
  58. 6.1 Mapping of the STATUS clause ..............................19
  59. 6.2 Mapping of the DESCRIPTION clause .........................20
  60. 6.3 Mapping of the REFERENCE clause ...........................20
  61. 6.4 Mapping of the OBJECT-IDENTITY value ......................20
  62. 6.5 Usage Example .............................................20
  63. 7 Mapping of the OBJECT-TYPE macro ............................20
  64. 7.1 Mapping of the SYNTAX clause ..............................21
  65. 7.1.1 Integer32 and INTEGER ...................................21
  66. 7.1.2 OCTET STRING ............................................21
  67. 7.1.3 OBJECT IDENTIFIER .......................................22
  68. 7.1.4 The BITS construct ......................................22
  69. 7.1.5 IpAddress ...............................................22
  70. 7.1.6 Counter32 ...............................................23
  71. 7.1.7 Gauge32 .................................................23
  72. 7.1.8 TimeTicks ...............................................24
  73. 7.1.9 Opaque ..................................................24
  74. 7.1.10 Counter64 ..............................................24
  75. 7.1.11 Unsigned32 .............................................25
  76. 7.1.12 Conceptual Tables ......................................25
  77. 7.1.12.1 Creation and Deletion of Conceptual Rows .............26
  78. 7.2 Mapping of the UNITS clause ...............................26
  79. 7.3 Mapping of the MAX-ACCESS clause ..........................26
  80. 7.4 Mapping of the STATUS clause ..............................27
  81. 7.5 Mapping of the DESCRIPTION clause .........................27
  82. 7.6 Mapping of the REFERENCE clause ...........................27
  83. 7.7 Mapping of the INDEX clause ...............................27
  84. 7.8 Mapping of the AUGMENTS clause ............................29
  85. 7.8.1 Relation between INDEX and AUGMENTS clauses .............30
  86. 7.9 Mapping of the DEFVAL clause ..............................30
  87. 7.10 Mapping of the OBJECT-TYPE value .........................31
  88. 7.11 Usage Example ............................................32
  89. McCloghrie, et al. Standards Track [Page 2]
  90. RFC 2578 SMIv2 April 1999
  91. 8 Mapping of the NOTIFICATION-TYPE macro ......................34
  92. 8.1 Mapping of the OBJECTS clause .............................34
  93. 8.2 Mapping of the STATUS clause ..............................34
  94. 8.3 Mapping of the DESCRIPTION clause .........................35
  95. 8.4 Mapping of the REFERENCE clause ...........................35
  96. 8.5 Mapping of the NOTIFICATION-TYPE value ....................35
  97. 8.6 Usage Example .............................................35
  98. 9 Refined Syntax ..............................................36
  99. 10 Extending an Information Module ............................37
  100. 10.1 Object Assignments .......................................37
  101. 10.2 Object Definitions .......................................38
  102. 10.3 Notification Definitions .................................39
  103. 11 Appendix A: Detailed Sub-typing Rules ......................40
  104. 11.1 Syntax Rules .............................................40
  105. 11.2 Examples .................................................41
  106. 12 Security Considerations ....................................41
  107. 13 Editors' Addresses .........................................41
  108. 14 References .................................................42
  109. 15 Full Copyright Statement ...................................43
  110. 1. Introduction
  111. Management information is viewed as a collection of managed objects,
  112. residing in a virtual information store, termed the Management
  113. Information Base (MIB). Collections of related objects are defined
  114. in MIB modules. These modules are written using an adapted subset of
  115. OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the
  116. purpose of this document, the Structure of Management Information
  117. (SMI), to define that adapted subset, and to assign a set of
  118. associated administrative values.
  119. The SMI is divided into three parts: module definitions, object
  120. definitions, and, notification definitions.
  121. (1) Module definitions are used when describing information modules.
  122. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the
  123. semantics of an information module.
  124. (2) Object definitions are used when describing managed objects. An
  125. ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax
  126. and semantics of a managed object.
  127. (3) Notification definitions are used when describing unsolicited
  128. transmissions of management information. An ASN.1 macro,
  129. NOTIFICATION-TYPE, is used to concisely convey the syntax and
  130. semantics of a notification.
  131. McCloghrie, et al. Standards Track [Page 3]
  132. RFC 2578 SMIv2 April 1999
  133. 1.1. A Note on Terminology
  134. For the purpose of exposition, the original Structure of Management
  135. Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and
  136. RFC 1215, is termed the SMI version 1 (SMIv1). The current version
  137. of the Structure of Management Information is termed SMI version 2
  138. (SMIv2).
  139. 2. Definitions
  140. SNMPv2-SMI DEFINITIONS ::= BEGIN
  141. -- the path to the root
  142. org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1
  143. dod OBJECT IDENTIFIER ::= { org 6 }
  144. internet OBJECT IDENTIFIER ::= { dod 1 }
  145. directory OBJECT IDENTIFIER ::= { internet 1 }
  146. mgmt OBJECT IDENTIFIER ::= { internet 2 }
  147. mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
  148. transmission OBJECT IDENTIFIER ::= { mib-2 10 }
  149. experimental OBJECT IDENTIFIER ::= { internet 3 }
  150. private OBJECT IDENTIFIER ::= { internet 4 }
  151. enterprises OBJECT IDENTIFIER ::= { private 1 }
  152. security OBJECT IDENTIFIER ::= { internet 5 }
  153. snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
  154. -- transport domains
  155. snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }
  156. -- transport proxies
  157. snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }
  158. -- module identities
  159. snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }
  160. -- Extended UTCTime, to allow dates with four-digit years
  161. -- (Note that this definition of ExtUTCTime is not to be IMPORTed
  162. -- by MIB modules.)
  163. ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
  164. -- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ
  165. McCloghrie, et al. Standards Track [Page 4]
  166. RFC 2578 SMIv2 April 1999
  167. -- where: YY - last two digits of year (only years
  168. -- between 1900-1999)
  169. -- YYYY - last four digits of the year (any year)
  170. -- MM - month (01 through 12)
  171. -- DD - day of month (01 through 31)
  172. -- HH - hours (00 through 23)
  173. -- MM - minutes (00 through 59)
  174. -- Z - denotes GMT (the ASCII character Z)
  175. --
  176. -- For example, "9502192015Z" and "199502192015Z" represent
  177. -- 8:15pm GMT on 19 February 1995. Years after 1999 must use
  178. -- the four digit year format. Years 1900-1999 may use the
  179. -- two or four digit format.
  180. -- definitions for information modules
  181. MODULE-IDENTITY MACRO ::=
  182. BEGIN
  183. TYPE NOTATION ::=
  184. "LAST-UPDATED" value(Update ExtUTCTime)
  185. "ORGANIZATION" Text
  186. "CONTACT-INFO" Text
  187. "DESCRIPTION" Text
  188. RevisionPart
  189. VALUE NOTATION ::=
  190. value(VALUE OBJECT IDENTIFIER)
  191. RevisionPart ::=
  192. Revisions
  193. | empty
  194. Revisions ::=
  195. Revision
  196. | Revisions Revision
  197. Revision ::=
  198. "REVISION" value(Update ExtUTCTime)
  199. "DESCRIPTION" Text
  200. -- a character string as defined in section 3.1.1
  201. Text ::= value(IA5String)
  202. END
  203. OBJECT-IDENTITY MACRO ::=
  204. BEGIN
  205. TYPE NOTATION ::=
  206. "STATUS" Status
  207. "DESCRIPTION" Text
  208. McCloghrie, et al. Standards Track [Page 5]
  209. RFC 2578 SMIv2 April 1999
  210. ReferPart
  211. VALUE NOTATION ::=
  212. value(VALUE OBJECT IDENTIFIER)
  213. Status ::=
  214. "current"
  215. | "deprecated"
  216. | "obsolete"
  217. ReferPart ::=
  218. "REFERENCE" Text
  219. | empty
  220. -- a character string as defined in section 3.1.1
  221. Text ::= value(IA5String)
  222. END
  223. -- names of objects
  224. -- (Note that these definitions of ObjectName and NotificationName
  225. -- are not to be IMPORTed by MIB modules.)
  226. ObjectName ::=
  227. OBJECT IDENTIFIER
  228. NotificationName ::=
  229. OBJECT IDENTIFIER
  230. -- syntax of objects
  231. -- the "base types" defined here are:
  232. -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
  233. -- 8 application-defined types: Integer32, IpAddress, Counter32,
  234. -- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64
  235. ObjectSyntax ::=
  236. CHOICE {
  237. simple
  238. SimpleSyntax,
  239. -- note that SEQUENCEs for conceptual tables and
  240. -- rows are not mentioned here...
  241. application-wide
  242. ApplicationSyntax
  243. }
  244. McCloghrie, et al. Standards Track [Page 6]
  245. RFC 2578 SMIv2 April 1999
  246. -- built-in ASN.1 types
  247. SimpleSyntax ::=
  248. CHOICE {
  249. -- INTEGERs with a more restrictive range
  250. -- may also be used
  251. integer-value -- includes Integer32
  252. INTEGER (-2147483648..2147483647),
  253. -- OCTET STRINGs with a more restrictive size
  254. -- may also be used
  255. string-value
  256. OCTET STRING (SIZE (0..65535)),
  257. objectID-value
  258. OBJECT IDENTIFIER
  259. }
  260. -- indistinguishable from INTEGER, but never needs more than
  261. -- 32-bits for a two's complement representation
  262. Integer32 ::=
  263. INTEGER (-2147483648..2147483647)
  264. -- application-wide types
  265. ApplicationSyntax ::=
  266. CHOICE {
  267. ipAddress-value
  268. IpAddress,
  269. counter-value
  270. Counter32,
  271. timeticks-value
  272. TimeTicks,
  273. arbitrary-value
  274. Opaque,
  275. big-counter-value
  276. Counter64,
  277. unsigned-integer-value -- includes Gauge32
  278. Unsigned32
  279. }
  280. -- in network-byte order
  281. McCloghrie, et al. Standards Track [Page 7]
  282. RFC 2578 SMIv2 April 1999
  283. -- (this is a tagged type for historical reasons)
  284. IpAddress ::=
  285. [APPLICATION 0]
  286. IMPLICIT OCTET STRING (SIZE (4))
  287. -- this wraps
  288. Counter32 ::=
  289. [APPLICATION 1]
  290. IMPLICIT INTEGER (0..4294967295)
  291. -- this doesn't wrap
  292. Gauge32 ::=
  293. [APPLICATION 2]
  294. IMPLICIT INTEGER (0..4294967295)
  295. -- an unsigned 32-bit quantity
  296. -- indistinguishable from Gauge32
  297. Unsigned32 ::=
  298. [APPLICATION 2]
  299. IMPLICIT INTEGER (0..4294967295)
  300. -- hundredths of seconds since an epoch
  301. TimeTicks ::=
  302. [APPLICATION 3]
  303. IMPLICIT INTEGER (0..4294967295)
  304. -- for backward-compatibility only
  305. Opaque ::=
  306. [APPLICATION 4]
  307. IMPLICIT OCTET STRING
  308. -- for counters that wrap in less than one hour with only 32 bits
  309. Counter64 ::=
  310. [APPLICATION 6]
  311. IMPLICIT INTEGER (0..18446744073709551615)
  312. -- definition for objects
  313. OBJECT-TYPE MACRO ::=
  314. BEGIN
  315. TYPE NOTATION ::=
  316. "SYNTAX" Syntax
  317. UnitsPart
  318. "MAX-ACCESS" Access
  319. "STATUS" Status
  320. "DESCRIPTION" Text
  321. ReferPart
  322. McCloghrie, et al. Standards Track [Page 8]
  323. RFC 2578 SMIv2 April 1999
  324. IndexPart
  325. DefValPart
  326. VALUE NOTATION ::=
  327. value(VALUE ObjectName)
  328. Syntax ::= -- Must be one of the following:
  329. -- a base type (or its refinement),
  330. -- a textual convention (or its refinement), or
  331. -- a BITS pseudo-type
  332. type
  333. | "BITS" "{" NamedBits "}"
  334. NamedBits ::= NamedBit
  335. | NamedBits "," NamedBit
  336. NamedBit ::= identifier "(" number ")" -- number is nonnegative
  337. UnitsPart ::=
  338. "UNITS" Text
  339. | empty
  340. Access ::=
  341. "not-accessible"
  342. | "accessible-for-notify"
  343. | "read-only"
  344. | "read-write"
  345. | "read-create"
  346. Status ::=
  347. "current"
  348. | "deprecated"
  349. | "obsolete"
  350. ReferPart ::=
  351. "REFERENCE" Text
  352. | empty
  353. IndexPart ::=
  354. "INDEX" "{" IndexTypes "}"
  355. | "AUGMENTS" "{" Entry "}"
  356. | empty
  357. IndexTypes ::=
  358. IndexType
  359. | IndexTypes "," IndexType
  360. IndexType ::=
  361. "IMPLIED" Index
  362. | Index
  363. McCloghrie, et al. Standards Track [Page 9]
  364. RFC 2578 SMIv2 April 1999
  365. Index ::=
  366. -- use the SYNTAX value of the
  367. -- correspondent OBJECT-TYPE invocation
  368. value(ObjectName)
  369. Entry ::=
  370. -- use the INDEX value of the
  371. -- correspondent OBJECT-TYPE invocation
  372. value(ObjectName)
  373. DefValPart ::= "DEFVAL" "{" Defvalue "}"
  374. | empty
  375. Defvalue ::= -- must be valid for the type specified in
  376. -- SYNTAX clause of same OBJECT-TYPE macro
  377. value(ObjectSyntax)
  378. | "{" BitsValue "}"
  379. BitsValue ::= BitNames
  380. | empty
  381. BitNames ::= BitName
  382. | BitNames "," BitName
  383. BitName ::= identifier
  384. -- a character string as defined in section 3.1.1
  385. Text ::= value(IA5String)
  386. END
  387. -- definitions for notifications
  388. NOTIFICATION-TYPE MACRO ::=
  389. BEGIN
  390. TYPE NOTATION ::=
  391. ObjectsPart
  392. "STATUS" Status
  393. "DESCRIPTION" Text
  394. ReferPart
  395. VALUE NOTATION ::=
  396. value(VALUE NotificationName)
  397. ObjectsPart ::=
  398. "OBJECTS" "{" Objects "}"
  399. | empty
  400. Objects ::=
  401. Object
  402. McCloghrie, et al. Standards Track [Page 10]
  403. RFC 2578 SMIv2 April 1999
  404. | Objects "," Object
  405. Object ::=
  406. value(ObjectName)
  407. Status ::=
  408. "current"
  409. | "deprecated"
  410. | "obsolete"
  411. ReferPart ::=
  412. "REFERENCE" Text
  413. | empty
  414. -- a character string as defined in section 3.1.1
  415. Text ::= value(IA5String)
  416. END
  417. -- definitions of administrative identifiers
  418. zeroDotZero OBJECT-IDENTITY
  419. STATUS current
  420. DESCRIPTION
  421. "A value used for null identifiers."
  422. ::= { 0 0 }
  423. END
  424. 3. Information Modules
  425. An "information module" is an ASN.1 module defining information
  426. relating to network management.
  427. The SMI describes how to use an adapted subset of ASN.1 (1988) to
  428. define an information module. Further, additional restrictions are
  429. placed on "standard" information modules. It is strongly recommended
  430. that "enterprise-specific" information modules also adhere to these
  431. restrictions.
  432. Typically, there are three kinds of information modules:
  433. (1) MIB modules, which contain definitions of inter-related managed
  434. objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros;
  435. (2) compliance statements for MIB modules, which make use of the
  436. MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and,
  437. (3) capability statements for agent implementations which make use of
  438. the AGENT-CAPABILITIES macros [2].
  439. McCloghrie, et al. Standards Track [Page 11]
  440. RFC 2578 SMIv2 April 1999
  441. This classification scheme does not imply a rigid taxonomy. For
  442. example, a "standard" information module will normally include
  443. definitions of managed objects and a compliance statement.
  444. Similarly, an "enterprise-specific" information module might include
  445. definitions of managed objects and a capability statement. Of
  446. course, a "standard" information module may not contain capability
  447. statements.
  448. The constructs of ASN.1 allowed in SMIv2 information modules include:
  449. the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type
  450. definitions for SEQUENCEs (with restrictions), ASN.1 type assignments
  451. of the restricted ASN.1 types allowed in SMIv2, and instances of
  452. ASN.1 macros defined in this document and its companion documents [2,
  453. 3]. Additional ASN.1 macros must not be defined in SMIv2 information
  454. modules. SMIv1 macros must not be used in SMIv2 information modules.
  455. The names of all standard information modules must be unique (but
  456. different versions of the same information module should have the
  457. same name). Developers of enterprise information modules are
  458. encouraged to choose names for their information modules that will
  459. have a low probability of colliding with standard or other enterprise
  460. information modules. An information module may not use the ASN.1
  461. construct of placing an object identifier value between the module
  462. name and the "DEFINITIONS" keyword. For the purposes of this
  463. specification, an ASN.1 module name begins with an upper-case letter
  464. and continues with zero or more letters, digits, or hyphens, except
  465. that a hyphen can not be the last character, nor can there be two
  466. consecutive hyphens.
  467. All information modules start with exactly one invocation of the
  468. MODULE-IDENTITY macro, which provides contact information as well as
  469. revision history to distinguish between versions of the same
  470. information module. This invocation must appear immediately after
  471. any IMPORTs statements.
  472. 3.1. Macro Invocation
  473. Within an information module, each macro invocation appears as:
  474. <descriptor> <macro> <clauses> ::= <value>
  475. where <descriptor> corresponds to an ASN.1 identifier, <macro> names
  476. the macro being invoked, and <clauses> and <value> depend on the
  477. definition of the macro. (Note that this definition of a descriptor
  478. applies to all macros defined in this memo and in [2].)
  479. McCloghrie, et al. Standards Track [Page 12]
  480. RFC 2578 SMIv2 April 1999
  481. For the purposes of this specification, an ASN.1 identifier consists
  482. of one or more letters or digits, and its initial character must be a
  483. lower-case letter. Note that hyphens are not allowed by this
  484. specification (except for use by information modules converted from
  485. SMIv1 which did allow hyphens).
  486. For all descriptors appearing in an information module, the
  487. descriptor shall be unique and mnemonic, and shall not exceed 64
  488. characters in length. (However, descriptors longer than 32
  489. characters are not recommended.) This promotes a common language for
  490. humans to use when discussing the information module and also
  491. facilitates simple table mappings for user-interfaces.
  492. The set of descriptors defined in all "standard" information modules
  493. shall be unique.
  494. Finally, by convention, if the descriptor refers to an object with a
  495. SYNTAX clause value of either Counter32 or Counter64, then the
  496. descriptor used for the object should denote plurality.
  497. 3.1.1. Textual Values and Strings
  498. Some clauses in a macro invocation may take a character string as a
  499. textual value (e.g., the DESCRIPTION clause). Other clauses take
  500. binary or hexadecimal strings (in any position where a non-negative
  501. number is allowed).
  502. A character string is preceded and followed by the quote character
  503. ("), and consists of an arbitrary number (possibly zero) of:
  504. - any 7-bit displayable ASCII characters except quote ("),
  505. - tab characters,
  506. - spaces, and
  507. - line terminator characters (\n or \r\n).
  508. The value of a character string is interpreted as ASCII.
  509. A binary string consists of a number (possibly zero) of zeros and
  510. ones preceded by a single (') and followed by either the pair ('B) or
  511. ('b), where the number is a multiple of eight.
  512. A hexadecimal string consists of an even number (possibly zero) of
  513. hexadecimal digits, preceded by a single (') and followed by either
  514. the pair ('H) or ('h). Digits specified via letters can be in upper
  515. or lower case.
  516. Note that ASN.1 comments can not be enclosed inside any of these
  517. types of strings.
  518. McCloghrie, et al. Standards Track [Page 13]
  519. RFC 2578 SMIv2 April 1999
  520. 3.2. IMPORTing Symbols
  521. To reference an external object, the IMPORTS statement must be used
  522. to identify both the descriptor and the module in which the
  523. descriptor is defined, where the module is identified by its ASN.1
  524. module name.
  525. Note that when symbols from "enterprise-specific" information modules
  526. are referenced (e.g., a descriptor), there is the possibility of
  527. collision. As such, if different objects with the same descriptor
  528. are IMPORTed, then this ambiguity is resolved by prefixing the
  529. descriptor with the name of the information module and a dot ("."),
  530. i.e.,
  531. "module.descriptor"
  532. (All descriptors must be unique within any information module.)
  533. Of course, this notation can be used to refer to objects even when
  534. there is no collision when IMPORTing symbols.
  535. Finally, if any of the ASN.1 named types and macros defined in this
  536. document, specifically:
  537. Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE-
  538. IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-
  539. IDENTITY, TimeTicks, Unsigned32,
  540. or any of those defined in [2] or [3], are used in an information
  541. module, then they must be imported using the IMPORTS statement.
  542. However, the following must not be included in an IMPORTS statement:
  543. - named types defined by ASN.1 itself, specifically: INTEGER,
  544. OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
  545. - the BITS construct.
  546. 3.3. Exporting Symbols
  547. The ASN.1 EXPORTS statement is not allowed in SMIv2 information
  548. modules. All items defined in an information module are
  549. automatically exported.
  550. 3.4. ASN.1 Comments
  551. ASN.1 comments can be included in an information module. However, it
  552. is recommended that all substantive descriptions be placed within an
  553. appropriate DESCRIPTION clause.
  554. McCloghrie, et al. Standards Track [Page 14]
  555. RFC 2578 SMIv2 April 1999
  556. ASN.1 comments commence with a pair of adjacent hyphens and end with
  557. the next pair of adjacent hyphens or at the end of the line,
  558. whichever occurs first. Comments ended by a pair of hyphens have the
  559. effect of a single space character.
  560. 3.5. OBJECT IDENTIFIER values
  561. An OBJECT IDENTIFIER value is an ordered list of non-negative
  562. numbers. For the SMIv2, each number in the list is referred to as a
  563. sub-identifier, there are at most 128 sub-identifiers in a value, and
  564. each sub-identifier has a maximum value of 2^32-1 (4294967295
  565. decimal).
  566. All OBJECT IDENTIFIER values have at least two sub-identifiers, where
  567. the value of the first sub-identifier is one of the following well-
  568. known names:
  569. Value Name
  570. 0 ccitt
  571. 1 iso
  572. 2 joint-iso-ccitt
  573. (Note that this SMI does not recognize "new" well-known names, e.g.,
  574. as defined when the CCITT became the ITU.)
  575. 3.6. OBJECT IDENTIFIER usage
  576. OBJECT IDENTIFIERs are used in information modules in two ways:
  577. (1) registration: the definition of a particular item is registered as
  578. a particular OBJECT IDENTIFIER value, and associated with a
  579. particular descriptor. After such a registration, the semantics
  580. thereby associated with the value are not allowed to change, the
  581. OBJECT IDENTIFIER can not be used for any other registration, and
  582. the descriptor can not be changed nor associated with any other
  583. registration. The following macros result in a registration:
  584. OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
  585. OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
  586. AGENT-CAPABILITIES.
  587. (2) assignment: a descriptor can be assigned to a particular OBJECT
  588. IDENTIFIER value. For this usage, the semantics associated with
  589. the OBJECT IDENTIFIER value is not allowed to change, and a
  590. descriptor assigned to a particular OBJECT IDENTIFIER value cannot
  591. subsequently be assigned to another. However, multiple descriptors
  592. can be assigned to the same OBJECT IDENTIFIER value. Such
  593. assignments are specified in the following manner:
  594. McCloghrie, et al. Standards Track [Page 15]
  595. RFC 2578 SMIv2 April 1999
  596. mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156
  597. mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213
  598. fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
  599. barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }
  600. Note while the above examples are legal, the following is not:
  601. dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }
  602. A descriptor is allowed to be associated with both a registration and
  603. an assignment, providing both are associated with the same OBJECT
  604. IDENTIFIER value and semantics.
  605. 3.7. Reserved Keywords
  606. The following are reserved keywords which must not be used as
  607. descriptors or module names:
  608. ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN
  609. BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO
  610. CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED
  611. DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED
  612. ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32
  613. IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER
  614. Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS
  615. MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE-
  616. IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL
  617. OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF
  618. OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE
  619. PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS
  620. STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE
  621. TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH
  622. WRITE-SYNTAX
  623. 4. Naming Hierarchy
  624. The root of the subtree administered by the Internet Assigned Numbers
  625. Authority (IANA) for the Internet is:
  626. internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
  627. That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
  628. prefix:
  629. 1.3.6.1.
  630. Several branches underneath this subtree are used for network
  631. management:
  632. McCloghrie, et al. Standards Track [Page 16]
  633. RFC 2578 SMIv2 April 1999
  634. mgmt OBJECT IDENTIFIER ::= { internet 2 }
  635. experimental OBJECT IDENTIFIER ::= { internet 3 }
  636. private OBJECT IDENTIFIER ::= { internet 4 }
  637. enterprises OBJECT IDENTIFIER ::= { private 1 }
  638. However, the SMI does not prohibit the definition of objects in other
  639. portions of the object tree.
  640. The mgmt(2) subtree is used to identify "standard" objects.
  641. The experimental(3) subtree is used to identify objects being
  642. designed by working groups of the IETF. If an information module
  643. produced by a working group becomes a "standard" information module,
  644. then at the very beginning of its entry onto the Internet standards
  645. track, the objects are moved under the mgmt(2) subtree.
  646. The private(4) subtree is used to identify objects defined
  647. unilaterally. The enterprises(1) subtree beneath private is used,
  648. among other things, to permit providers of networking subsystems to
  649. register models of their products.
  650. 5. Mapping of the MODULE-IDENTITY macro
  651. The MODULE-IDENTITY macro is used to provide contact and revision
  652. history for each information module. It must appear exactly once in
  653. every information module. It should be noted that the expansion of
  654. the MODULE-IDENTITY macro is something which conceptually happens
  655. during implementation and not during run-time.
  656. Note that reference in an IMPORTS clause or in clauses of SMIv2
  657. macros to an information module is NOT through the use of the
  658. 'descriptor' of a MODULE-IDENTITY macro; rather, an information
  659. module is referenced through specifying its module name.
  660. 5.1. Mapping of the LAST-UPDATED clause
  661. The LAST-UPDATED clause, which must be present, contains the date and
  662. time that this information module was last edited.
  663. 5.2. Mapping of the ORGANIZATION clause
  664. The ORGANIZATION clause, which must be present, contains a textual
  665. description of the organization under whose auspices this information
  666. module was developed.
  667. McCloghrie, et al. Standards Track [Page 17]
  668. RFC 2578 SMIv2 April 1999
  669. 5.3. Mapping of the CONTACT-INFO clause
  670. The CONTACT-INFO clause, which must be present, contains the name,
  671. postal address, telephone number, and electronic mail address of the
  672. person to whom technical queries concerning this information module
  673. should be sent.
  674. 5.4. Mapping of the DESCRIPTION clause
  675. The DESCRIPTION clause, which must be present, contains a high-level
  676. textual description of the contents of this information module.
  677. 5.5. Mapping of the REVISION clause
  678. The REVISION clause, which need not be present, is repeatedly used to
  679. describe the revisions (including the initial version) made to this
  680. information module, in reverse chronological order (i.e., most recent
  681. first). Each instance of this clause contains the date and time of
  682. the revision.
  683. 5.5.1. Mapping of the DESCRIPTION sub-clause
  684. The DESCRIPTION sub-clause, which must be present for each REVISION
  685. clause, contains a high-level textual description of the revision
  686. identified in that REVISION clause.
  687. 5.6. Mapping of the MODULE-IDENTITY value
  688. The value of an invocation of the MODULE-IDENTITY macro is an OBJECT
  689. IDENTIFIER. As such, this value may be authoritatively used when
  690. specifying an OBJECT IDENTIFIER value to refer to the information
  691. module containing the invocation.
  692. Note that it is a common practice to use the value of the MODULE-
  693. IDENTITY macro as a subtree under which other OBJECT IDENTIFIER
  694. values assigned within the module are defined. However, it is legal
  695. (and occasionally necessary) for the other OBJECT IDENTIFIER values
  696. assigned within the module to be unrelated to the OBJECT IDENTIFIER
  697. value of the MODULE-IDENTITY macro.
  698. 5.7. Usage Example
  699. Consider how a skeletal MIB module might be constructed: e.g.,
  700. FIZBIN-MIB DEFINITIONS ::= BEGIN
  701. IMPORTS
  702. MODULE-IDENTITY, OBJECT-TYPE, experimental
  703. McCloghrie, et al. Standards Track [Page 18]
  704. RFC 2578 SMIv2 April 1999
  705. FROM SNMPv2-SMI;
  706. fizbin MODULE-IDENTITY
  707. LAST-UPDATED "199505241811Z"
  708. ORGANIZATION "IETF SNMPv2 Working Group"
  709. CONTACT-INFO
  710. " Marshall T. Rose
  711. Postal: Dover Beach Consulting, Inc.
  712. 420 Whisman Court
  713. Mountain View, CA 94043-2186
  714. US
  715. Tel: +1 415 968 1052
  716. Fax: +1 415 968 2510
  717. E-mail: mrose@dbc.mtview.ca.us"
  718. DESCRIPTION
  719. "The MIB module for entities implementing the xxxx
  720. protocol."
  721. REVISION "9505241811Z"
  722. DESCRIPTION
  723. "The latest version of this MIB module."
  724. REVISION "9210070433Z"
  725. DESCRIPTION
  726. "The initial version of this MIB module, published in
  727. RFC yyyy."
  728. -- contact IANA for actual number
  729. ::= { experimental xx }
  730. END
  731. 6. Mapping of the OBJECT-IDENTITY macro
  732. The OBJECT-IDENTITY macro is used to define information about an
  733. OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER
  734. assignments which define a type identification value (see
  735. AutonomousType, a textual convention defined in [3]) should be
  736. defined via the OBJECT-IDENTITY macro. It should be noted that the
  737. expansion of the OBJECT-IDENTITY macro is something which
  738. conceptually happens during implementation and not during run-time.
  739. 6.1. Mapping of the STATUS clause
  740. The STATUS clause, which must be present, indicates whether this
  741. definition is current or historic.
  742. McCloghrie, et al. Standards Track [Page 19]
  743. RFC 2578 SMIv2 April 1999
  744. The value "current" means that the definition is current and valid.
  745. The value "obsolete" means the definition is obsolete and should not
  746. be implemented and/or can be removed if previously implemented.
  747. While the value "deprecated" also indicates an obsolete definition,
  748. it permits new/continued implementation in order to foster
  749. interoperability with older/existing implementations.
  750. 6.2. Mapping of the DESCRIPTION clause
  751. The DESCRIPTION clause, which must be present, contains a textual
  752. description of the object assignment.
  753. 6.3. Mapping of the REFERENCE clause
  754. The REFERENCE clause, which need not be present, contains a textual
  755. cross-reference to some other document, either another information
  756. module which defines a related assignment, or some other document
  757. which provides additional information relevant to this definition.
  758. 6.4. Mapping of the OBJECT-IDENTITY value
  759. The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT
  760. IDENTIFIER.
  761. 6.5. Usage Example
  762. Consider how an OBJECT IDENTIFIER assignment might be made: e.g.,
  763. fizbin69 OBJECT-IDENTITY
  764. STATUS current
  765. DESCRIPTION
  766. "The authoritative identity of the Fizbin 69 chipset."
  767. ::= { fizbinChipSets 1 }
  768. 7. Mapping of the OBJECT-TYPE macro
  769. The OBJECT-TYPE macro is used to define a type of managed object. It
  770. should be noted that the expansion of the OBJECT-TYPE macro is
  771. something which conceptually happens during implementation and not
  772. during run-time.
  773. For leaf objects which are not columnar objects (i.e., not contained
  774. within a conceptual table), instances of the object are identified by
  775. appending a sub-identifier of zero to the name of that object.
  776. Otherwise, the INDEX clause of the conceptual row object superior to
  777. a columnar object defines instance identification information.
  778. McCloghrie, et al. Standards Track [Page 20]
  779. RFC 2578 SMIv2 April 1999
  780. 7.1. Mapping of the SYNTAX clause
  781. The SYNTAX clause, which must be present, defines the abstract data
  782. structure corresponding to that object. The data structure must be
  783. one of the following: a base type, the BITS construct, or a textual
  784. convention. (SEQUENCE OF and SEQUENCE are also possible for
  785. conceptual tables, see section 7.1.12). The base types are those
  786. defined in the ObjectSyntax CHOICE. A textual convention is a
  787. newly-defined type defined as a sub-type of a base type [3].
  788. An extended subset of the full capabilities of ASN.1 (1988) sub-
  789. typing is allowed, as appropriate to the underlying ASN.1 type. Any
  790. such restriction on size, range or enumerations specified in this
  791. clause represents the maximal level of support which makes "protocol
  792. sense". Restrictions on sub-typing are specified in detail in
  793. Section 9 and Appendix A of this memo.
  794. The semantics of ObjectSyntax are now described.
  795. 7.1.1. Integer32 and INTEGER
  796. The Integer32 type represents integer-valued information between
  797. -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This
  798. type is indistinguishable from the INTEGER type. Both the INTEGER
  799. and Integer32 types may be sub-typed to be more constrained than the
  800. Integer32 type.
  801. The INTEGER type (but not the Integer32 type) may also be used to
  802. represent integer-valued information as named-number enumerations.
  803. In this case, only those named-numbers so enumerated may be present
  804. as a value. Note that although it is recommended that enumerated
  805. values start at 1 and be numbered contiguously, any valid value for
  806. Integer32 is allowed for an enumerated value and, further, enumerated
  807. values needn't be contiguously assigned.
  808. Finally, a label for a named-number enumeration must consist of one
  809. or more letters or digits, up to a maximum of 64 characters, and the
  810. initial character must be a lower-case letter. (However, labels
  811. longer than 32 characters are not recommended.) Note that hyphens
  812. are not allowed by this specification (except for use by information
  813. modules converted from SMIv1 which did allow hyphens).
  814. 7.1.2. OCTET STRING
  815. The OCTET STRING type represents arbitrary binary or textual data.
  816. Although the SMI-specified size limitation for this type is 65535
  817. octets, MIB designers should realize that there may be implementation
  818. and interoperability limitations for sizes in excess of 255 octets.
  819. McCloghrie, et al. Standards Track [Page 21]
  820. RFC 2578 SMIv2 April 1999
  821. 7.1.3. OBJECT IDENTIFIER
  822. The OBJECT IDENTIFIER type represents administratively assigned
  823. names. Any instance of this type may have at most 128 sub-
  824. identifiers. Further, each sub-identifier must not exceed the value
  825. 2^32-1 (4294967295 decimal).
  826. 7.1.4. The BITS construct
  827. The BITS construct represents an enumeration of named bits. This
  828. collection is assigned non-negative, contiguous (but see below)
  829. values, starting at zero. Only those named-bits so enumerated may be
  830. present in a value. (Thus, enumerations must be assigned to
  831. consecutive bits; however, see Section 9 for refinements of an object
  832. with this syntax.)
  833. As part of updating an information module, for an object defined
  834. using the BITS construct, new enumerations can be added or existing
  835. enumerations can have new labels assigned to them. After an
  836. enumeration is added, it might not be possible to distinguish between
  837. an implementation of the updated object for which the new enumeration
  838. is not asserted, and an implementation of the object prior to the
  839. addition. Depending on the circumstances, such an ambiguity could
  840. either be desirable or could be undesirable. The means to avoid such
  841. an ambiguity is dependent on the encoding of values on the wire;
  842. however, one possibility is to define new enumerations starting at
  843. the next multiple of eight bits. (Of course, this can also result in
  844. the enumerations no longer being contiguous.)
  845. Although there is no SMI-specified limitation on the number of
  846. enumerations (and therefore on the length of a value), except as may
  847. be imposed by the limit on the length of an OCTET STRING, MIB
  848. designers should realize that there may be implementation and
  849. interoperability limitations for sizes in excess of 128 bits.
  850. Finally, a label for a named-number enumeration must consist of one
  851. or more letters or digits, up to a maximum of 64 characters, and the
  852. initial character must be a lower-case letter. (However, labels
  853. longer than 32 characters are not recommended.) Note that hyphens
  854. are not allowed by this specification.
  855. 7.1.5. IpAddress
  856. The IpAddress type represents a 32-bit internet address. It is
  857. represented as an OCTET STRING of length 4, in network byte-order.
  858. McCloghrie, et al. Standards Track [Page 22]
  859. RFC 2578 SMIv2 April 1999
  860. Note that the IpAddress type is a tagged type for historical reasons.
  861. Network addresses should be represented using an invocation of the
  862. TEXTUAL-CONVENTION macro [3].
  863. 7.1.6. Counter32
  864. The Counter32 type represents a non-negative integer which
  865. monotonically increases until it reaches a maximum value of 2^32-1
  866. (4294967295 decimal), when it wraps around and starts increasing
  867. again from zero.
  868. Counters have no defined "initial" value, and thus, a single value of
  869. a Counter has (in general) no information content. Discontinuities
  870. in the monotonically increasing value normally occur at re-
  871. initialization of the management system, and at other times as
  872. specified in the description of an object-type using this ASN.1 type.
  873. If such other times can occur, for example, the creation of an object
  874. instance at times other than re-initialization, then a corresponding
  875. object should be defined, with an appropriate SYNTAX clause, to
  876. indicate the last discontinuity. Examples of appropriate SYNTAX
  877. clause include: TimeStamp (a textual convention defined in [3]),
  878. DateAndTime (another textual convention from [3]) or TimeTicks.
  879. The value of the MAX-ACCESS clause for objects with a SYNTAX clause
  880. value of Counter32 is either "read-only" or "accessible-for-notify".
  881. A DEFVAL clause is not allowed for objects with a SYNTAX clause value
  882. of Counter32.
  883. 7.1.7. Gauge32
  884. The Gauge32 type represents a non-negative integer, which may
  885. increase or decrease, but shall never exceed a maximum value, nor
  886. fall below a minimum value. The maximum value can not be greater
  887. than 2^32-1 (4294967295 decimal), and the minimum value can not be
  888. smaller than 0. The value of a Gauge32 has its maximum value
  889. whenever the information being modeled is greater than or equal to
  890. its maximum value, and has its minimum value whenever the information
  891. being modeled is smaller than or equal to its minimum value. If the
  892. information being modeled subsequently decreases below (increases
  893. above) the maximum (minimum) value, the Gauge32 also decreases
  894. (increases). (Note that despite of the use of the term "latched" in
  895. the original definition of this type, it does not become "stuck" at
  896. its maximum or minimum value.)
  897. McCloghrie, et al. Standards Track [Page 23]
  898. RFC 2578 SMIv2 April 1999
  899. 7.1.8. TimeTicks
  900. The TimeTicks type represents a non-negative integer which represents
  901. the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
  902. between two epochs. When objects are defined which use this ASN.1
  903. type, the description of the object identifies both of the reference
  904. epochs.
  905. For example, [3] defines the TimeStamp textual convention which is
  906. based on the TimeTicks type. With a TimeStamp, the first reference
  907. epoch is defined as the time when sysUpTime [5] was zero, and the
  908. second reference epoch is defined as the current value of sysUpTime.
  909. The TimeTicks type may not be sub-typed.
  910. 7.1.9. Opaque
  911. The Opaque type is provided solely for backward-compatibility, and
  912. shall not be used for newly-defined object types.
  913. The Opaque type supports the capability to pass arbitrary ASN.1
  914. syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4]
  915. into a string of octets. This, in turn, is encoded as an OCTET
  916. STRING, in effect "double-wrapping" the original ASN.1 value.
  917. Note that a conforming implementation need only be able to accept and
  918. recognize opaquely-encoded data. It need not be able to unwrap the
  919. data and then interpret its contents.
  920. A requirement on "standard" MIB modules is that no object may have a
  921. SYNTAX clause value of Opaque.
  922. 7.1.10. Counter64
  923. The Counter64 type represents a non-negative integer which
  924. monotonically increases until it reaches a maximum value of 2^64-1
  925. (18446744073709551615 decimal), when it wraps around and starts
  926. increasing again from zero.
  927. Counters have no defined "initial" value, and thus, a single value of
  928. a Counter has (in general) no information content. Discontinuities
  929. in the monotonically increasing value normally occur at re-
  930. initialization of the management system, and at other times as
  931. specified in the description of an object-type using this ASN.1 type.
  932. If such other times can occur, for example, the creation of an object
  933. instance at times other than re-initialization, then a corresponding
  934. object should be defined, with an appropriate SYNTAX clause, to
  935. indicate the last discontinuity. Examples of appropriate SYNTAX
  936. McCloghrie, et al. Standards Track [Page 24]
  937. RFC 2578 SMIv2 April 1999
  938. clause are: TimeStamp (a textual convention defined in [3]),
  939. DateAndTime (another textual convention from [3]) or TimeTicks.
  940. The value of the MAX-ACCESS clause for objects with a SYNTAX clause
  941. value of Counter64 is either "read-only" or "accessible-for-notify".
  942. A requirement on "standard" MIB modules is that the Counter64 type
  943. may be used only if the information being modeled would wrap in less
  944. than one hour if the Counter32 type was used instead.
  945. A DEFVAL clause is not allowed for objects with a SYNTAX clause value
  946. of Counter64.
  947. 7.1.11. Unsigned32
  948. The Unsigned32 type represents integer-valued information between 0
  949. and 2^32-1 inclusive (0 to 4294967295 decimal).
  950. 7.1.12. Conceptual Tables
  951. Management operations apply exclusively to scalar objects. However,
  952. it is sometimes convenient for developers of management applications
  953. to impose an imaginary, tabular structure on an ordered collection of
  954. objects within the MIB. Each such conceptual table contains zero or
  955. more rows, and each row may contain one or more scalar objects,
  956. termed columnar objects. This conceptualization is formalized by
  957. using the OBJECT-TYPE macro to define both an object which
  958. corresponds to a table and an object which corresponds to a row in
  959. that table. A conceptual table has SYNTAX of the form:
  960. SEQUENCE OF <EntryType>
  961. where <EntryType> refers to the SEQUENCE type of its subordinate
  962. conceptual row. A conceptual row has SYNTAX of the form:
  963. <EntryType>
  964. where <EntryType> is a SEQUENCE type defined as follows:
  965. <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
  966. where there is one <type> for each subordinate object, and each
  967. <type> is of the form:
  968. <descriptor> <syntax>
  969. where <descriptor> is the descriptor naming a subordinate object, and
  970. <syntax> has the value of that subordinate object's SYNTAX clause,
  971. McCloghrie, et al. Standards Track [Page 25]
  972. RFC 2578 SMIv2 April 1999
  973. except that both sub-typing information and the named values for
  974. enumerated integers or the named bits for the BITS construct, are
  975. omitted from <syntax>.
  976. Further, a <type> is always present for every subordinate object.
  977. (The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the
  978. SEQUENCE definition.) The MAX-ACCESS clause for conceptual tables
  979. and rows is "not-accessible".
  980. 7.1.12.1. Creation and Deletion of Conceptual Rows
  981. For newly-defined conceptual rows which allow the creation of new
  982. object instances and/or the deletion of existing object instances,
  983. there should be one columnar object with a SYNTAX clause value of
  984. RowStatus (a textual convention defined in [3]) and a MAX-ACCESS
  985. clause value of read-create. By convention, this is termed the
  986. status column for the conceptual row.
  987. 7.2. Mapping of the UNITS clause
  988. This UNITS clause, which need not be present, contains a textual
  989. definition of the units associated with that object.
  990. 7.3. Mapping of the MAX-ACCESS clause
  991. The MAX-ACCESS clause, which must be present, defines whether it
  992. makes "protocol sense" to read, write and/or create an instance of
  993. the object, or to include its value in a notification. This is the
  994. maximal level of access for the object. (This maximal level of
  995. access is independent of any administrative authorization policy.)
  996. The value "read-write" indicates that read and write access make
  997. "protocol sense", but create does not. The value "read-create"
  998. indicates that read, write and create access make "protocol sense".
  999. The value "not-accessible" indicates an auxiliary object (see Section
  1000. 7.7). The value "accessible-for-notify" indicates an object which is
  1001. accessible only via a notification (e.g., snmpTrapOID [5]).
  1002. These values are ordered, from least to greatest: "not-accessible",
  1003. "accessible-for-notify", "read-only", "read-write", "read-create".
  1004. If any columnar object in a conceptual row has "read-create" as its
  1005. maximal level of access, then no other columnar object of the same
  1006. conceptual row may have a maximal access of "read-write". (Note that
  1007. "read-create" is a superset of "read-write".)
  1008. McCloghrie, et al. Standards Track [Page 26]
  1009. RFC 2578 SMIv2 April 1999
  1010. 7.4. Mapping of the STATUS clause
  1011. The STATUS clause, which must be present, indicates whether this
  1012. definition is current or historic.
  1013. The value "current" means that the definition is current and valid.
  1014. The value "obsolete" means the definition is obsolete and should not
  1015. be implemented and/or can be removed if previously implemented.
  1016. While the value "deprecated" also indicates an obsolete definition,
  1017. it permits new/continued implementation in order to foster
  1018. interoperability with older/existing implementations.
  1019. 7.5. Mapping of the DESCRIPTION clause
  1020. The DESCRIPTION clause, which must be present, contains a textual
  1021. definition of that object which provides all semantic definitions
  1022. necessary for implementation, and should embody any information which
  1023. would otherwise be communicated in any ASN.1 commentary annotations
  1024. associated with the object.
  1025. 7.6. Mapping of the REFERENCE clause
  1026. The REFERENCE clause, which need not be present, contains a textual
  1027. cross-reference to some other document, either another information
  1028. module which defines a related assignment, or some other document
  1029. which provides additional information relevant to this definition.
  1030. 7.7. Mapping of the INDEX clause
  1031. The INDEX clause, which must be present if that object corresponds to
  1032. a conceptual row (unless an AUGMENTS clause is present instead), and
  1033. must be absent otherwise, defines instance identification information
  1034. for the columnar objects subordinate to that object.
  1035. The instance identification information in an INDEX clause must
  1036. specify object(s) such that value(s) of those object(s) will
  1037. unambiguously distinguish a conceptual row. The objects can be
  1038. columnar objects from the same and/or another conceptual table, but
  1039. must not be scalar objects. Multiple occurrences of the same object
  1040. in a single INDEX clause is strongly discouraged.
  1041. The syntax of the objects in the INDEX clause indicate how to form
  1042. the instance-identifier:
  1043. (1) integer-valued (i.e., having INTEGER as its underlying primitive
  1044. type): a single sub-identifier taking the integer value (this
  1045. works only for non-negative integers);
  1046. McCloghrie, et al. Standards Track [Page 27]
  1047. RFC 2578 SMIv2 April 1999
  1048. (2) string-valued, fixed-length strings (or variable-length preceded by
  1049. the IMPLIED keyword): `n' sub-identifiers, where `n' is the length
  1050. of the string (each octet of the string is encoded in a separate
  1051. sub-identifier);
  1052. (3) string-valued, variable-length strings (not preceded by the IMPLIED
  1053. keyword): `n+1' sub-identifiers, where `n' is the length of the
  1054. string (the first sub-identifier is `n' itself, following this,
  1055. each octet of the string is encoded in a separate sub-identifier);
  1056. (4) object identifier-valued (when preceded by the IMPLIED keyword):
  1057. `n' sub-identifiers, where `n' is the number of sub-identifiers in
  1058. the value (each sub-identifier of the value is copied into a
  1059. separate sub-identifier);
  1060. (5) object identifier-valued (when not preceded by the IMPLIED
  1061. keyword): `n+1' sub-identifiers, where `n' is the number of sub-
  1062. identifiers in the value (the first sub-identifier is `n' itself,
  1063. following this, each sub-identifier in the value is copied);
  1064. (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d
  1065. notation.
  1066. Note that the IMPLIED keyword can only be present for an object
  1067. having a variable-length syntax (e.g., variable-length strings or
  1068. object identifier-valued objects), Further, the IMPLIED keyword can
  1069. only be associated with the last object in the INDEX clause.
  1070. Finally, the IMPLIED keyword may not be used on a variable-length
  1071. string object if that string might have a value of zero-length.
  1072. Since a single value of a Counter has (in general) no information
  1073. content (see section 7.1.6 and 7.1.10), objects defined using the
  1074. syntax, Counter32 or Counter64, must not be specified in an INDEX
  1075. clause. If an object defined using the BITS construct is used in an
  1076. INDEX clause, it is considered a variable-length string.
  1077. Instances identified by use of integer-valued objects should be
  1078. numbered starting from one (i.e., not from zero). The use of zero as
  1079. a value for an integer-valued index object should be avoided, except
  1080. in special cases.
  1081. Objects which are both specified in the INDEX clause of a conceptual
  1082. row and also columnar objects of the same conceptual row are termed
  1083. auxiliary objects. The MAX-ACCESS clause for auxiliary objects is
  1084. "not-accessible", except in the following circumstances:
  1085. McCloghrie, et al. Standards Track [Page 28]
  1086. RFC 2578 SMIv2 April 1999
  1087. (1) within a MIB module originally written to conform to SMIv1, and
  1088. later converted to conform to SMIv2; or
  1089. (2) a conceptual row must contain at least one columnar object which is
  1090. not an auxiliary object. In the event that all of a conceptual
  1091. row's columnar objects are also specified in its INDEX clause, then
  1092. one of them must be accessible, i.e., have a MAX-ACCESS clause of
  1093. "read-only". (Note that this situation does not arise for a
  1094. conceptual row allowing create access, since such a row will have a
  1095. status column which will not be an auxiliary object.)
  1096. Note that objects specified in a conceptual row's INDEX clause need
  1097. not be columnar objects of that conceptual row. In this situation,
  1098. the DESCRIPTION clause of the conceptual row must include a textual
  1099. explanation of how the objects which are included in the INDEX clause
  1100. but not columnar objects of that conceptual row, are used in uniquely
  1101. identifying instances of the conceptual row's columnar objects.
  1102. 7.8. Mapping of the AUGMENTS clause
  1103. The AUGMENTS clause, which must not be present unless the object
  1104. corresponds to a conceptual row, is an alternative to the INDEX
  1105. clause. Every object corresponding to a conceptual row has either an
  1106. INDEX clause or an AUGMENTS clause.
  1107. If an object corresponding to a conceptual row has an INDEX clause,
  1108. that row is termed a base conceptual row; alternatively, if the
  1109. object has an AUGMENTS clause, the row is said to be a conceptual row
  1110. augmentation, where the AUGMENTS clause names the object
  1111. corresponding to the base conceptual row which is augmented by this
  1112. conceptual row augmentation. (Thus, a conceptual row augmentation
  1113. cannot itself be augmented.) Instances of subordinate columnar
  1114. objects of a conceptual row augmentation are identified according to
  1115. the INDEX clause of the base conceptual row corresponding to the
  1116. object named in the AUGMENTS clause. Further, instances of
  1117. subordinate columnar objects of a conceptual row augmentation exist
  1118. according to the same semantics as instances of subordinate columnar
  1119. objects of the base conceptual row being augmented. As such, note
  1120. that creation of a base conceptual row implies the correspondent
  1121. creation of any conceptual row augmentations.
  1122. For example, a MIB designer might wish to define additional columns
  1123. in an "enterprise-specific" MIB which logically extend a conceptual
  1124. row in a "standard" MIB. The "standard" MIB definition of the
  1125. conceptual row would include the INDEX clause and the "enterprise-
  1126. specific" MIB would contain the definition of a conceptual row using
  1127. the AUGMENTS clause. On the other hand, it would be incorrect to use
  1128. the AUGMENTS clause for the relationship between RFC 2233's ifTable
  1129. McCloghrie, et al. Standards Track [Page 29]
  1130. RFC 2578 SMIv2 April 1999
  1131. and the many media-specific MIBs which extend it for specific media
  1132. (e.g., the dot3Table in RFC 2358), since not all interfaces are of
  1133. the same media.
  1134. Note that a base conceptual row may be augmented by multiple
  1135. conceptual row augmentations.
  1136. 7.8.1. Relation between INDEX and AUGMENTS clauses
  1137. When defining instance identification information for a conceptual
  1138. table:
  1139. (1) If there is a one-to-one correspondence between the conceptual rows
  1140. of this table and an existing table, then the AUGMENTS clause
  1141. should be used.
  1142. (2) Otherwise, if there is a sparse relationship between the conceptual
  1143. rows of this table and an existing table, then an INDEX clause
  1144. should be used which is identical to that in the existing table.
  1145. For example, the relationship between RFC 2233's ifTable and a
  1146. media-specific MIB which extends the ifTable for a specific media
  1147. (e.g., the dot3Table in RFC 2358), is a sparse relationship.
  1148. (3) Otherwise, if no existing objects have the required syntax and
  1149. semantics, then auxiliary objects should be defined within the
  1150. conceptual row for the new table, and those objects should be used
  1151. within the INDEX clause for the conceptual row.
  1152. 7.9. Mapping of the DEFVAL clause
  1153. The DEFVAL clause, which need not be present, defines an acceptable
  1154. default value which may be used at the discretion of an agent when an
  1155. object instance is created. That is, the value is a "hint" to
  1156. implementors.
  1157. During conceptual row creation, if an instance of a columnar object
  1158. is not present as one of the operands in the correspondent management
  1159. protocol set operation, then the value of the DEFVAL clause, if
  1160. present, indicates an acceptable default value that an agent might
  1161. use (especially for a read-only object).
  1162. Note that with this definition of the DEFVAL clause, it is
  1163. appropriate to use it for any columnar object of a read-create table.
  1164. It is also permitted to use it for scalar objects dynamically created
  1165. by an agent, or for columnar objects of a read-write table
  1166. dynamically created by an agent.
  1167. McCloghrie, et al. Standards Track [Page 30]
  1168. RFC 2578 SMIv2 April 1999
  1169. The value of the DEFVAL clause must, of course, correspond to the
  1170. SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER,
  1171. then it must be expressed as a single ASN.1 identifier, and not as a
  1172. collection of sub-identifiers.
  1173. Note that if an operand to the management protocol set operation is
  1174. an instance of a read-only object, then the error `notWritable' [6]
  1175. will be returned. As such, the DEFVAL clause can be used to provide
  1176. an acceptable default value that an agent might use.
  1177. By way of example, consider the following possible DEFVAL clauses:
  1178. ObjectSyntax DEFVAL clause
  1179. ---------------- ------------
  1180. Integer32 DEFVAL { 1 }
  1181. -- same for Gauge32, TimeTicks, Unsigned32
  1182. INTEGER DEFVAL { valid } -- enumerated value
  1183. OCTET STRING DEFVAL { 'ffffffffffff'H }
  1184. DisplayString DEFVAL { "SNMP agent" }
  1185. IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21
  1186. OBJECT IDENTIFIER DEFVAL { sysDescr }
  1187. BITS DEFVAL { { primary, secondary } }
  1188. -- enumerated values that are set
  1189. BITS DEFVAL { { } }
  1190. -- no enumerated values are set
  1191. A binary string used in a DEFVAL clause for an OCTET STRING must be
  1192. either an integral multiple of eight or zero bits in length;
  1193. similarly, a hexadecimal string must be an even number of hexadecimal
  1194. digits. The value of a character string used in a DEFVAL clause must
  1195. not contain tab characters or line terminator characters.
  1196. Object types with SYNTAX of Counter32 and Counter64 may not have
  1197. DEFVAL clauses, since they do not have defined initial values.
  1198. However, it is recommended that they be initialized to zero.
  1199. 7.10. Mapping of the OBJECT-TYPE value
  1200. The value of an invocation of the OBJECT-TYPE macro is the name of
  1201. the object, which is an OBJECT IDENTIFIER, an administratively
  1202. assigned name.
  1203. When an OBJECT IDENTIFIER is assigned to an object:
  1204. (1) If the object corresponds to a conceptual table, then only a single
  1205. assignment, that for a conceptual row, is present immediately
  1206. beneath that object. The administratively assigned name for the
  1207. conceptual row object is derived by appending a sub-identifier of
  1208. McCloghrie, et al. Standards Track [Page 31]
  1209. RFC 2578 SMIv2 April 1999
  1210. "1" to the administratively assigned name for the conceptual table.
  1211. (2) If the object corresponds to a conceptual row, then at least one
  1212. assignment, one for each column in the conceptual row, is present
  1213. beneath that object. The administratively assigned name for each
  1214. column is derived by appending a unique, positive sub-identifier to
  1215. the administratively assigned name for the conceptual row.
  1216. (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
  1217. object may be assigned.
  1218. Note that the final sub-identifier of any administratively assigned
  1219. name for an object shall be positive. A zero-valued final sub-
  1220. identifier is reserved for future use.
  1221. 7.11. Usage Example
  1222. Consider how one might define a conceptual table and its
  1223. subordinates. (This example uses the RowStatus textual convention
  1224. defined in [3].)
  1225. evalSlot OBJECT-TYPE
  1226. SYNTAX Integer32 (0..2147483647)
  1227. MAX-ACCESS read-only
  1228. STATUS current
  1229. DESCRIPTION
  1230. "The index number of the first unassigned entry in the
  1231. evaluation table, or the value of zero indicating that
  1232. all entries are assigned.
  1233. A management station should create new entries in the
  1234. evaluation table using this algorithm: first, issue a
  1235. management protocol retrieval operation to determine the
  1236. value of evalSlot; and, second, issue a management
  1237. protocol set operation to create an instance of the
  1238. evalStatus object setting its value to createAndGo(4) or
  1239. createAndWait(5). If this latter operation succeeds,
  1240. then the management station may continue modifying the
  1241. instances corresponding to the newly created conceptual
  1242. row, without fear of collision with other management
  1243. stations."
  1244. ::= { eval 1 }
  1245. evalTable OBJECT-TYPE
  1246. SYNTAX SEQUENCE OF EvalEntry
  1247. MAX-ACCESS not-accessible
  1248. STATUS current
  1249. DESCRIPTION
  1250. McCloghrie, et al. Standards Track [Page 32]
  1251. RFC 2578 SMIv2 April 1999
  1252. "The (conceptual) evaluation table."
  1253. ::= { eval 2 }
  1254. evalEntry OBJECT-TYPE
  1255. SYNTAX EvalEntry
  1256. MAX-ACCESS not-accessible
  1257. STATUS current
  1258. DESCRIPTION
  1259. "An entry (conceptual row) in the evaluation table."
  1260. INDEX { evalIndex }
  1261. ::= { evalTable 1 }
  1262. EvalEntry ::=
  1263. SEQUENCE {
  1264. evalIndex Integer32,
  1265. evalString DisplayString,
  1266. evalValue Integer32,
  1267. evalStatus RowStatus
  1268. }
  1269. evalIndex OBJECT-TYPE
  1270. SYNTAX Integer32 (1..2147483647)
  1271. MAX-ACCESS not-accessible
  1272. STATUS current
  1273. DESCRIPTION
  1274. "The auxiliary variable used for identifying instances of
  1275. the columnar objects in the evaluation table."
  1276. ::= { evalEntry 1 }
  1277. evalString OBJECT-TYPE
  1278. SYNTAX DisplayString
  1279. MAX-ACCESS read-create
  1280. STATUS current
  1281. DESCRIPTION
  1282. "The string to evaluate."
  1283. ::= { evalEntry 2 }
  1284. evalValue OBJECT-TYPE
  1285. SYNTAX Integer32
  1286. MAX-ACCESS read-only
  1287. STATUS current
  1288. DESCRIPTION
  1289. "The value when evalString was last evaluated, or zero if
  1290. no such value is available."
  1291. DEFVAL { 0 }
  1292. ::= { evalEntry 3 }
  1293. evalStatus OBJECT-TYPE
  1294. McCloghrie, et al. Standards Track [Page 33]
  1295. RFC 2578 SMIv2 April 1999
  1296. SYNTAX RowStatus
  1297. MAX-ACCESS read-create
  1298. STATUS current
  1299. DESCRIPTION
  1300. "The status column used for creating, modifying, and
  1301. deleting instances of the columnar objects in the
  1302. evaluation table."
  1303. DEFVAL { active }
  1304. ::= { evalEntry 4 }
  1305. 8. Mapping of the NOTIFICATION-TYPE macro
  1306. The NOTIFICATION-TYPE macro is used to define the information
  1307. contained within an unsolicited transmission of management
  1308. information (i.e., within either a SNMPv2-Trap-PDU or InformRequest-
  1309. PDU). It should be noted that the expansion of the NOTIFICATION-TYPE
  1310. macro is something which conceptually happens during implementation
  1311. and not during run-time.
  1312. 8.1. Mapping of the OBJECTS clause
  1313. The OBJECTS clause, which need not be present, defines an ordered
  1314. sequence of MIB object types. One and only one object instance for
  1315. each occurrence of each object type must be present, and in the
  1316. specified order, in every instance of the notification. If the same
  1317. object type occurs multiple times in a notification's ordered
  1318. sequence, then an object instance is present for each of them. An
  1319. object type specified in this clause must not have an MAX-ACCESS
  1320. clause of "not-accessible". The notification's DESCRIPTION clause
  1321. must specify the information/meaning conveyed by each occurrence of
  1322. each object type in the sequence. The DESCRIPTION clause must also
  1323. specify which object instance is present for each object type in the
  1324. notification.
  1325. Note that an agent is allowed, at its own discretion, to append as
  1326. many additional objects as it considers useful to the end of the
  1327. notification (i.e., after the objects defined by the OBJECTS clause).
  1328. 8.2. Mapping of the STATUS clause
  1329. The STATUS clause, which must be present, indicates whether this
  1330. definition is current or historic.
  1331. The value "current" means that the definition is current and valid.
  1332. The value "obsolete" means the definition is obsolete and should not
  1333. be implemented and/or can be removed if previously implemented.
  1334. While the value "deprecated" also indicates an obsolete definition,
  1335. it permits new/continued implementation in order to foster
  1336. McCloghrie, et al. Standards Track [Page 34]
  1337. RFC 2578 SMIv2 April 1999
  1338. interoperability with older/existing implementations.
  1339. 8.3. Mapping of the DESCRIPTION clause
  1340. The DESCRIPTION clause, which must be present, contains a textual
  1341. definition of the notification which provides all semantic
  1342. definitions necessary for implementation, and should embody any
  1343. information which would otherwise be communicated in any ASN.1
  1344. commentary annotations associated with the notification. In
  1345. particular, the DESCRIPTION clause should document which instances of
  1346. the objects mentioned in the OBJECTS clause should be contained
  1347. within notifications of this type.
  1348. 8.4. Mapping of the REFERENCE clause
  1349. The REFERENCE clause, which need not be present, contains a textual
  1350. cross-reference to some other document, either another information
  1351. module which defines a related assignment, or some other document
  1352. which provides additional information relevant to this definition.
  1353. 8.5. Mapping of the NOTIFICATION-TYPE value
  1354. The value of an invocation of the NOTIFICATION-TYPE macro is the name
  1355. of the notification, which is an OBJECT IDENTIFIER, an
  1356. administratively assigned name. In order to achieve compatibility
  1357. with SNMPv1 traps, both when converting SMIv1 information modules
  1358. to/from this SMI, and in the procedures employed by multi-lingual
  1359. systems and proxy forwarding applications, the next to last sub-
  1360. identifier in the name of any newly-defined notification must have
  1361. the value zero.
  1362. Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE
  1363. macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU,
  1364. respectively.
  1365. 8.6. Usage Example
  1366. Consider how a configuration change notification might be described:
  1367. entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
  1368. entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }
  1369. entConfigChange NOTIFICATION-TYPE
  1370. STATUS current
  1371. DESCRIPTION
  1372. "An entConfigChange trap is sent when the value of
  1373. entLastChangeTime changes. It can be utilized by an NMS to
  1374. trigger logical/physical entity table maintenance polls.
  1375. McCloghrie, et al. Standards Track [Page 35]
  1376. RFC 2578 SMIv2 April 1999
  1377. An agent must not generate more than one entConfigChange
  1378. 'trap-event' in a five second period, where a 'trap-event'
  1379. is the transmission of a single trap PDU to a list of
  1380. trap destinations. If additional configuration changes
  1381. occur within the five second 'throttling' period, then
  1382. these trap-events should be suppressed by the agent. An
  1383. NMS should periodically check the value of
  1384. entLastChangeTime to detect any missed entConfigChange
  1385. trap-events, e.g. due to throttling or transmission loss."
  1386. ::= { entityMIBTrapPrefix 1 }
  1387. According to this invocation, the notification authoritatively
  1388. identified as
  1389. { entityMIBTrapPrefix 1 }
  1390. is used to report a particular type of configuration change.
  1391. 9. Refined Syntax
  1392. Some macros have clauses which allows syntax to be refined,
  1393. specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the
  1394. SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT-
  1395. CAPABILITIES macros [2]. However, not all refinements of syntax are
  1396. appropriate. In particular, the object's primitive or application
  1397. type must not be changed.
  1398. Further, the following restrictions apply:
  1399. Restrictions to Refinement of
  1400. object syntax range enumeration size
  1401. ----------------- ----- ----------- ----
  1402. INTEGER (1) (2) -
  1403. Integer32 (1) - -
  1404. Unsigned32 (1) - -
  1405. OCTET STRING - - (3)
  1406. OBJECT IDENTIFIER - - -
  1407. BITS - (2) -
  1408. IpAddress - - -
  1409. Counter32 - - -
  1410. Counter64 - - -
  1411. Gauge32 (1) - -
  1412. TimeTicks - - -
  1413. where:
  1414. McCloghrie, et al. Standards Track [Page 36]
  1415. RFC 2578 SMIv2 April 1999
  1416. (1) the range of permitted values may be refined by raising the lower-
  1417. bounds, by reducing the upper-bounds, and/or by reducing the
  1418. alternative value/range choices;
  1419. (2) the enumeration of named-values may be refined by removing one or
  1420. more named-values (note that for BITS, a refinement may cause the
  1421. enumerations to no longer be contiguous); or,
  1422. (3) the size in octets of the value may be refined by raising the
  1423. lower-bounds, by reducing the upper-bounds, and/or by reducing the
  1424. alternative size choices.
  1425. No other types of refinements can be specified in the SYNTAX clause.
  1426. However, the DESCRIPTION clause is available to specify additional
  1427. restrictions which can not be expressed in the SYNTAX clause.
  1428. Further details on (and examples of) sub-typing are provided in
  1429. Appendix A.
  1430. 10. Extending an Information Module
  1431. As experience is gained with an information module, it may be
  1432. desirable to revise that information module. However, changes are
  1433. not allowed if they have any potential to cause interoperability
  1434. problems "over the wire" between an implementation using an original
  1435. specification and an implementation using an updated
  1436. specification(s).
  1437. For any change, the invocation of the MODULE-IDENTITY macro must be
  1438. updated to include information about the revision: specifically,
  1439. updating the LAST-UPDATED clause, adding a pair of REVISION and
  1440. DESCRIPTION clauses (see section 5.5), and making any necessary
  1441. changes to existing clauses, including the ORGANIZATION and CONTACT-
  1442. INFO clauses.
  1443. Note that any definition contained in an information module is
  1444. available to be IMPORT-ed by any other information module, and is
  1445. referenced in an IMPORTS clause via the module name. Thus, a module
  1446. name should not be changed. Specifically, the module name (e.g.,
  1447. "FIZBIN-MIB" in the example of Section 5.7) should not be changed
  1448. when revising an information module (except to correct typographical
  1449. errors), and definitions should not be moved from one information
  1450. module to another.
  1451. Also note that obsolete definitions must not be removed from MIB
  1452. modules since their descriptors may still be referenced by other
  1453. information modules, and the OBJECT IDENTIFIERs used to name them
  1454. must never be re-assigned.
  1455. McCloghrie, et al. Standards Track [Page 37]
  1456. RFC 2578 SMIv2 April 1999
  1457. 10.1. Object Assignments
  1458. If any non-editorial change is made to any clause of a object
  1459. assignment, then the OBJECT IDENTIFIER value associated with that
  1460. object assignment must also be changed, along with its associated
  1461. descriptor.
  1462. 10.2. Object Definitions
  1463. An object definition may be revised in any of the following ways:
  1464. (1) A SYNTAX clause containing an enumerated INTEGER may have new
  1465. enumerations added or existing labels changed. Similarly, named
  1466. bits may be added or existing labels changed for the BITS
  1467. construct.
  1468. (2) The value of a SYNTAX clause may be replaced by a textual
  1469. convention, providing the textual convention is defined to use the
  1470. same primitive ASN.1 type, has the same set of values, and has
  1471. identical semantics.
  1472. (3) A STATUS clause value of "current" may be revised as "deprecated"
  1473. or "obsolete". Similarly, a STATUS clause value of "deprecated"
  1474. may be revised as "obsolete". When making such a change, the
  1475. DESCRIPTION clause should be updated to explain the rationale.
  1476. (4) A DEFVAL clause may be added or updated.
  1477. (5) A REFERENCE clause may be added or updated.
  1478. (6) A UNITS clause may be added.
  1479. (7) A conceptual row may be augmented by adding new columnar objects at
  1480. the end of the row, and making the corresponding update to the
  1481. SEQUENCE definition.
  1482. (8) Clarifications and additional information may be included in the
  1483. DESCRIPTION clause.
  1484. (9) Entirely new objects may be defined, named with previously
  1485. unassigned OBJECT IDENTIFIER values.
  1486. Otherwise, if the semantics of any previously defined object are
  1487. changed (i.e., if a non-editorial change is made to any clause other
  1488. than those specifically allowed above), then the OBJECT IDENTIFIER
  1489. value associated with that object must also be changed.
  1490. McCloghrie, et al. Standards Track [Page 38]
  1491. RFC 2578 SMIv2 April 1999
  1492. Note that changing the descriptor associated with an existing object
  1493. is considered a semantic change, as these strings may be used in an
  1494. IMPORTS statement.
  1495. 10.3. Notification Definitions
  1496. A notification definition may be revised in any of the following
  1497. ways:
  1498. (1) A REFERENCE clause may be added or updated.
  1499. (2) A STATUS clause value of "current" may be revised as "deprecated"
  1500. or "obsolete". Similarly, a STATUS clause value of "deprecated"
  1501. may be revised as "obsolete". When making such a change, the
  1502. DESCRIPTION clause should be updated to explain the rationale.
  1503. (3) A DESCRIPTION clause may be clarified.
  1504. Otherwise, if the semantics of any previously defined notification
  1505. are changed (i.e., if a non-editorial change is made to any clause
  1506. other those specifically allowed above), then the OBJECT IDENTIFIER
  1507. value associated with that notification must also be changed.
  1508. Note that changing the descriptor associated with an existing
  1509. notification is considered a semantic change, as these strings may be
  1510. used in an IMPORTS statement.
  1511. McCloghrie, et al. Standards Track [Page 39]
  1512. RFC 2578 SMIv2 April 1999
  1513. 11. Appendix A: Detailed Sub-typing Rules
  1514. 11.1. Syntax Rules
  1515. The syntax rules for sub-typing are given below. Note that while
  1516. this syntax is based on ASN.1, it includes some extensions beyond
  1517. what is allowed in ASN.1, and a number of ASN.1 constructs are not
  1518. allowed by this syntax.
  1519. <integerSubType>
  1520. ::= <empty>
  1521. | "(" <range> ["|" <range>]... ")"
  1522. <octetStringSubType>
  1523. ::= <empty>
  1524. | "(" "SIZE" "(" <range> ["|" <range>]... ")" ")"
  1525. <range>
  1526. ::= <value>
  1527. | <value> ".." <value>
  1528. <value>
  1529. ::= "-" <number>
  1530. | <number>
  1531. | <hexString>
  1532. | <binString>
  1533. where:
  1534. <empty> is the empty string
  1535. <number> is a non-negative integer
  1536. <hexString> is a hexadecimal string (e.g., '0F0F'H)
  1537. <binString> is a binary string (e.g, '1010'B)
  1538. <range> is further restricted as follows:
  1539. - any <value> used in a SIZE clause must be non-negative.
  1540. - when a pair of values is specified, the first value
  1541. must be less than the second value.
  1542. - when multiple ranges are specified, the ranges may
  1543. not overlap but may touch. For example, (1..4 | 4..9)
  1544. is invalid, and (1..4 | 5..9) is valid.
  1545. - the ranges must be a subset of the maximum range of the
  1546. base type.
  1547. McCloghrie, et al. Standards Track [Page 40]
  1548. RFC 2578 SMIv2 April 1999
  1549. 11.2. Examples
  1550. Some examples of legal sub-typing:
  1551. Integer32 (-20..100)
  1552. Integer32 (0..100 | 300..500)
  1553. Integer32 (300..500 | 0..100)
  1554. Integer32 (0 | 2 | 4 | 6 | 8 | 10)
  1555. OCTET STRING (SIZE(0..100))
  1556. OCTET STRING (SIZE(0..100 | 300..500))
  1557. OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10))
  1558. SYNTAX TimeInterval (0..100)
  1559. SYNTAX DisplayString (SIZE(0..32))
  1560. (Note the last two examples above are not valid in a TEXTUAL
  1561. CONVENTION, see [3].)
  1562. Some examples of illegal sub-typing:
  1563. Integer32 (150..100) -- first greater than second
  1564. Integer32 (0..100 | 50..500) -- ranges overlap
  1565. Integer32 (0 | 2 | 0 ) -- value duplicated
  1566. Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed
  1567. Integer32 (SIZE (0..34)) -- must not use SIZE
  1568. OCTET STRING (0..100) -- must use SIZE
  1569. OCTET STRING (SIZE(-10..100)) -- negative SIZE
  1570. 12. Security Considerations
  1571. This document defines a language with which to write and read
  1572. descriptions of management information. The language itself has no
  1573. security impact on the Internet.
  1574. 13. Editors' Addresses
  1575. Keith McCloghrie
  1576. Cisco Systems, Inc.
  1577. 170 West Tasman Drive
  1578. San Jose, CA 95134-1706
  1579. USA
  1580. Phone: +1 408 526 5260
  1581. EMail: kzm@cisco.com
  1582. McCloghrie, et al. Standards Track [Page 41]
  1583. RFC 2578 SMIv2 April 1999
  1584. David Perkins
  1585. SNMPinfo
  1586. 3763 Benton Street
  1587. Santa Clara, CA 95051
  1588. USA
  1589. Phone: +1 408 221-8702
  1590. EMail: dperkins@snmpinfo.com
  1591. Juergen Schoenwaelder
  1592. TU Braunschweig
  1593. Bueltenweg 74/75
  1594. 38106 Braunschweig
  1595. Germany
  1596. Phone: +49 531 391-3283
  1597. EMail: schoenw@ibr.cs.tu-bs.de
  1598. 14. References
  1599. [1] Information processing systems - Open Systems Interconnection -
  1600. Specification of Abstract Syntax Notation One (ASN.1),
  1601. International Organization for Standardization. International
  1602. Standard 8824, (December, 1987).
  1603. [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
  1604. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58,
  1605. RFC 2580, April 1999.
  1606. [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
  1607. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
  1608. RFC 2579, April 1999.
  1609. [4] Information processing systems - Open Systems Interconnection -
  1610. Specification of Basic Encoding Rules for Abstract Syntax Notation
  1611. One (ASN.1), International Organization for Standardization.
  1612. International Standard 8825, (December, 1987).
  1613. [5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
  1614. S. Waldbusser, "Management Information Base for Version 2 of the
  1615. Simple Network Management Protocol (SNMPv2)", RFC 1907, January
  1616. 1996.
  1617. [6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
  1618. S. Waldbusser, "Protocol Operations for Version 2 of the Simple
  1619. Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
  1620. McCloghrie, et al. Standards Track [Page 42]
  1621. RFC 2578 SMIv2 April 1999
  1622. 15. Full Copyright Statement
  1623. Copyright (C) The Internet Society (1999). All Rights Reserved.
  1624. This document and translations of it may be copied and furnished to
  1625. others, and derivative works that comment on or otherwise explain it
  1626. or assist in its implementation may be prepared, copied, published
  1627. and distributed, in whole or in part, without restriction of any
  1628. kind, provided that the above copyright notice and this paragraph are
  1629. included on all such copies and derivative works. However, this
  1630. document itself may not be modified in any way, such as by removing
  1631. the copyright notice or references to the Internet Society or other
  1632. Internet organizations, except as needed for the purpose of
  1633. developing Internet standards in which case the procedures for
  1634. copyrights defined in the Internet Standards process must be
  1635. followed, or as required to translate it into languages other than
  1636. English.
  1637. The limited permissions granted above are perpetual and will not be
  1638. revoked by the Internet Society or its successors or assigns.
  1639. This document and the information contained herein is provided on an
  1640. "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1641. TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1642. BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1643. HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1644. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  1645. McCloghrie, et al. Standards Track [Page 43]