idnits 2.17.1 draft-perkins-enum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 1996) is 10195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '2') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '3') (Obsoleted by RFC 2580) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Expires November 1996 INTERNET-DRAFT 3 Draft ENUM Pseudotype May 27, 1996 5 The ENUM PseudoType 6 for SNMPv2 SMI 8 10 May 27, 1996 12 David T. Perkins 13 dperkins@scruznet.com 15 1. Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 "working draft" or "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Draft ENUM Pseudotype May 27, 1996 40 2. Introduction 42 This memo is experimental. It specifies a pseudotype for the SNMPv2 43 SMI[1][2][3] to ease the development and improve the understanding of 44 SNMP MIBs. This pseudotype is called "ENUM" and has the look, and 45 function of an ASN.1 type in the following constructs, allowed in SNMPv2 46 MIB modules: OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT- 47 CAPABILITIES, TEXTUAL-CONVENTION, and type assignments. This pseudotype 48 is meant to replace the current construct for specifying enumerated 49 integers in SNMP MIBs. Existing MIBs can be easily converted to use 50 this new construct, and MIBs that use the new construct can be converted 51 to MIBs that are valid under the rules of the SMNPv2 SMI (and SNMPv1 52 SMI[4][5].) 54 This memo proposes that the ENUM pseudotype be integrated into a future 55 version of the SNMPv2 SMI. A definition of the pseudotype is given 56 using the ASN.1 macro notation. Also included in this memo is the 57 extended BNF notation describing the syntax for this construct, and the 58 guidelines for conversion between MIB modules in the SMIv2 format and 59 those using this new pseudotype. 61 This memo does not specify a standard for the Internet community. 63 Draft ENUM Pseudotype May 27, 1996 65 3. The ASN.1 Macro for the ENUM Pseudotype 67 ENUM MACRO ::= 68 BEGIN 69 -- Note: ASN.1 macro notation is too limiting to specify all the 70 -- rules for usage. Additional rules are specified as comments. 72 TYPE NOTATION ::= 73 -- in SEQUENCES, cannot name any values 74 -- (i.e. SEQUENCE { o1 ENUM, o2 Integer32 }) 75 empty 76 -- in SYNTAX clause, must specify the named (enumerated) values 77 | "{" EnumValues "}" 79 -- The following is just to specify the syntax for values, 80 -- but does not "deliver" a useful value. (The identifier 81 -- must be a name of one of the an enumerated values.) 82 VALUE NOTATION ::= 83 identifier 84 86 -- the enumerated values (named values) in the type definition 87 EnumValues ::= 88 EnumValue 89 | EnumValues "," EnumValue 91 -- The enumerated (named) values can be any in the range 92 -- of -2147483648 to 2147483647. Each name must be unique 93 -- for the type definition. Only those named values may be 94 -- members of the range. Note that though it is recommended that 95 -- enumerated values start at 1 and be numbered contiguously, 96 -- any valid value for Integer32 is allowed for an enumerated 97 -- value and, further, enumerated values needn't be contiguously 98 -- assigned. 99 EnumValue ::= identifier "(" IntVal")" 101 IntVal ::= "-" number | number 102 END 104 Draft ENUM Pseudotype May 27, 1996 106 4. The extended BNF for the ENUM Pseudotype 108 When used as a type, the ENUM pseudotype is defined by production 109 . When used as a value, the ENUM pseudotype is defined by 110 production . 112 = 113 "ENUM" -- in a sequence 114 | "ENUM" "{" [ "," ]... "}" 116 = identifier "(" ")" 118 = "-" number | number 120 = identifier 122 Where: 123 identifier must consist of one or more letters or digits 124 (no hyphens), up to a maximum of 64 characters, and the 125 initial character must be a lower-case letter. 127 number is an unsigned integer less than or equal to 128 2^31 (2147483648) when preceded by a minus sign, otherwise 129 number must be less than 2^31 (2147483648). 131 5. Mapping of the ENUM Pseudotype 133 The ENUM pseudotype represents an enumeration of named values. (The 134 pseudotype looks like the ASN.1 type ENUMERATED, but maps to type 135 INTEGER(-2147483648..2147483647).) Only those named values from the 136 range of integer values may be present as a value. Note that although 137 it is recommended that enumerated values start at 1 and be numbered 138 contiguously, any valid value for Integer32 (a pseudonym for type 139 INTEGER(-2147483648..2147483647)) is allowed for an enumerated value 140 and, further, enumerated values needn't be contiguously assigned. 142 Finally, the identifier (also called a label) for an enumeration must 143 consist of one or more letters or digits (no hyphens), up to a maximum 144 of 64 characters, and the initial character must be a lower-case letter. 145 (However, labels longer than 32 characters are not recommended.) 147 Values for the ENUM pseudotype are encoded as values for the ASN.1 148 INTEGER type. 150 Draft ENUM Pseudotype May 27, 1996 152 6. Example Usage 154 The ENUM pseudotype can be used in the follow situations in MIB modules: 156 In an OBJECT-TYPE construct, for example: 158 o1 OBJECT-TYPE 159 SYNTAX ENUM { monday(1), tuesday(2), wednesday(3) } 160 MAX-ACCESS read-create 161 STATUS current 162 DESCRIPTION "Example object" 163 DEFVAL { wednesday } 164 ::= { a1 1 } 166 In a TEXTUAL-CONVENTION construct, for example: 168 T1 TEXTUAL-CONVENTION 169 STATUS current 170 DESCRIPTION "Example textual convention" 171 SYNTAX ENUM { north(10), east(20), 172 south(-10), west(-20) } 174 In a type assignment, for example: 176 T1 ::= ENUM { cool(0), warm(10), hot(17) } 178 In a SEQUENCE definition, for example: 180 S1Entry ::= SEQUENCE { 181 o1 ENUM, 182 o2 Integer32 } 184 In a MODULE-COMPLIANCE construct, for example: 186 mc1 MODULE-COMPLIANCE 187 STATUS current 188 DESCRIPTION "Example module compliance" 189 MODULE 190 MANDATORY-GROUPS { g1 } 191 OBJECT o1 192 SYNTAX ENUM { monday(1), tuesday(2) } 193 WRITE-SYNTAX ENUM { tuesday(2) } 194 DESCRIPTION "Example variation" 195 ::= { mc 1 } 197 Draft ENUM Pseudotype May 27, 1996 199 In an AGENT-CAPABILITIES construct, for example: 201 ac1 AGENT-CAPABILITIES 202 PRODUCT-RELEASE "Example product" 203 STATUS current 204 DESCRIPTION "Example agent capabilities" 205 SUPPORTS M1 206 INCLUDES { g1 } 207 VARIATION o1 208 SYNTAX ENUM { tuesday(2), wednesday(3) } 209 WRITE-SYNTAX ENUM { wednesday(3) } 210 DEFVAL { wednesday } 211 ::= { ac 1 } 213 7. Conversion Between Current Usage and the ENUM Pseudotype 215 In both SMIv1 and SMv2 MIB modules, the type notation for an enumerated 216 integer is written as "INTEGER { }". Conversion to and 217 from the ENUM pseudotype consists of using the word "INTEGER" or "ENUM" 218 in the appropriate places. This requires more that just a simple 219 "search and replace" algorithm when converting from "INTEGER" to "ENUM" 220 due to ambiguity in the SEQUENCE construct. (Note that this is not a 221 claim that the SMIv1 and SMv2 MIB module language is ambiguous. It is 222 only to point out that the syntax of objects specified in a SEQUENCE 223 construct must be known.) The algorithm converting "ENUM" to "INTEGER" 224 is a simple replacement of "ENUM" tokens with "INTEGER" tokens. Both 225 conversion algorithms need to also adjust the IMPORTS clause, since use 226 of the "INTEGER" construct requires no imports and the "ENUM" requires 227 an import from the SMI. 229 8. Allowed Updates 231 An instance of an ENUM pseudotype may have new enumerations added or 232 existing labels changed when a MIB module is updated. (Note that this 233 allowance is consistent with that specified in section 10.2 of SMIv2.) 235 9. Acknowledgments 237 Thanks go to Bancroff Scott for his assistance on the BITS macro on 238 which the ENUM macro is modeled. 240 Draft ENUM Pseudotype May 27, 1996 242 10. References 244 [1] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of 245 Management Information for Version 2 of the Simple Network 246 Management Protocol (SNMPv2)", RFC 1902, 01/22/1996. 248 [2] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual 249 Conventions for Version 2 of the Simple Network Management Protocol 250 (SNMPv2)", RFC 1903, 01/22/1996. 252 [3] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance 253 Statements for Version 2 of the Simple Network Management Protocol 254 (SNMPv2)", RFC 1904, 01/22/1996. 256 [4] K. McCloghrie, M. Rose, "Structure and Identification of Management 257 Information for TCP/IP-based Internets", RFC 1155, 05/10/1990. 259 [5] K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212, 260 03/26/1991.