idnits 2.17.1 draft-perkins-sum-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-26) 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 8 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 10196 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) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 SUM Pseudotype May 27, 1996 5 The SUM 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 SUM 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 "SUM" 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 bit strings 49 encoded as integers in SNMP MIBs. Existing MIBs can be easily converted 50 to use this new construct, and MIBs that use the new construct can be 51 converted to MIBs that are valid under the rules of the SMNPv2 SMI (and 52 SNMPv1 SMI[4][5].) (An example of an object definition using a bit 53 string encoded as an integer is "sysServices" found in RFCs 1213[6] and 54 1907[7].) 56 This memo proposes that the SUM pseudotype be integrated into a future 57 version of the SNMPv2 SMI. A definition of the pseudotype is given 58 using the ASN.1 macro notation. Also included in this memo is the 59 extended BNF notation describing the syntax for this construct, and the 60 guidelines for conversion between MIB modules in the SMIv2 format and 61 those using this new pseudotype. 63 This memo does not specify a standard for the Internet community. 65 Draft SUM Pseudotype May 27, 1996 67 3. The ASN.1 Macro for the SUM Pseudotype 69 SUM MACRO ::= 70 BEGIN 71 -- Note: ASN.1 macro notation is too limiting to specify all the 72 -- rules for usage. Additional rules are specified as comments. 74 TYPE NOTATION ::= 75 -- in SEQUENCES, cannot name any bits 76 -- (i.e. SEQUENCE { o1 SUM, o2 Integer32 }) 77 empty 78 -- in SYNTAX clause, must specify the bits 79 | "{" NamedBits "}" 81 -- The following is just to specify the syntax for values, 82 -- but does not "deliver" a useful value. (The identifier 83 -- must be a name of one of the named bits.) 84 VALUE NOTATION ::= 85 "{" NamedBitVal "}" 86 88 -- the names of bits in a value 89 NamedBitVal ::= 90 identifier 91 | NamedBitVal "," identifier 93 -- the names of bits in the type definition 94 NamedBits ::= 95 NamedBit 96 | NamedBits "," NamedBit 98 -- The bits are named and identified by their position in the 99 -- integer. Bit zero is the low order (or right-most) 100 -- bit in the integer. Bit 30 is the highest order allowed bit 101 -- in the integer. For an instance of a SUM macro, all named 102 -- bits for that instance must be unique and the names must start 103 -- with a lowercase letter. Also, all the positions for that 104 -- instance must be unique and range from zero to the last one 105 -- specified, which can be at most 30. The bits do not need to 106 -- be named in any order; however, all positions for bits must 107 -- be specified. The identifier must consist of one or more 108 -- letters or digits (no hyphens), up to a maximum of 64 109 -- characters, and the initial character must be a lower-case 110 -- letter. 111 NamedBit ::= identifier "(" number ")" 112 END 114 Draft SUM Pseudotype May 27, 1996 116 4. The extended BNF for the SUM Pseudotype 118 When used as a type, the SUM pseudotype is defined by production 119 . When used as a value, the SUM pseudotype is defined by 120 production . 122 = 123 "SUM" -- in a sequence 124 | "SUM" "{" [ "," ]... "}" 126 = identifier "(" number ")" 128 = "{" [ identifier ["," identifier]... ] "}" 130 Where: 131 identifier must consist of one or more letters or digits 132 (no hyphens), up to a maximum of 64 characters, and the 133 initial character must be a lower-case letter. 135 number is an unsigned integer less than or equal to 30. 137 5. Mapping of the SUM Pseudotype 139 The SUM pseudotype represents an enumeration of named bits encoded in an 140 integer. (The pseudotype looks like the ASN.1 type BIT STRING, but maps 141 to type INTEGER(0..2147483647).) Each collection of named bits is 142 assigned non-negative, contiguous values, starting at zero. However, 143 the bits do not need to be named in any order in the definition of the 144 collection as long as the resulting collection names all bits 145 contiguously. The maximum number of bits in a collection is 31 (i.e., 146 the highest identifiable bit is 30). 148 Finally, the identifier (also called a label) for a named bit must 149 consist of one or more letters or digits (no hyphens), up to a maximum 150 of 64 characters, and the initial character must be a lower-case letter. 151 (However, labels longer than 32 characters are not recommended.) 153 Values for the SUM pseudotype are encoded as values for the ASN.1 154 INTEGER type, with the bits (up to 31) packed into the value. Bits 155 are numbered by their position, starting at zero, in the integer. 156 Bit zero is the low order (or right-most) bit in the integer. Bit 30 157 is the highest order allowed bit in the integer. When a value is 158 encoded, unspecified bits, if any, must be set to zero. 160 Draft SUM Pseudotype May 27, 1996 162 6. Example usage 164 The SUM pseudotype can be used in the follow situations in MIB modules: 166 In an OBJECT-TYPE construct, for example: 168 o1 OBJECT-TYPE 169 SYNTAX SUM { blue(0), red(1), green(2) } 170 MAX-ACCESS read-create 171 STATUS current 172 DESCRIPTION "Example object" 173 DEFVAL { { blue, green } } 174 ::= { a1 1 } 176 In a TEXTUAL-CONVENTION construct, for example: 178 T1 TEXTUAL-CONVENTION 179 STATUS current 180 DESCRIPTION "Example textual convention" 181 SYNTAX SUM { fire(0), wind(1), rain(2) } 183 In a type assignment, for example: 185 T1 ::= SUM { smooth(0), flexible(1), warm(2) } 187 In a SEQUENCE definition, for example: 189 S1Entry ::= SEQUENCE { 190 o1 SUM, 191 o2 Integer32 } 193 In a MODULE-COMPLIANCE construct, for example: 195 mc1 MODULE-COMPLIANCE 196 STATUS current 197 DESCRIPTION "Example module compliance" 198 MODULE 199 MANDATORY-GROUPS { g1 } 200 OBJECT o1 201 SYNTAX SUM { fire(0), wind(1) } 202 WRITE-SYNTAX SUM { fire(0) } 203 DESCRIPTION "Example variation" 204 ::= { mc 1 } 206 Draft SUM Pseudotype May 27, 1996 208 In an AGENT-CAPABILITIES construct, for example: 210 ac1 AGENT-CAPABILITIES 211 PRODUCT-RELEASE "Example product" 212 STATUS current 213 DESCRIPTION "Example agent capabilities" 214 SUPPORTS M1 215 INCLUDES { g1 } 216 VARIATION o1 217 SYNTAX SUM { fire(0), wind(1) } 218 WRITE-SYNTAX SUM { fire(0) } 219 DEFVAL { { wind } } 220 ::= { ac 1 } 222 7. Conversion Between Current Usage and the SUM Pseudotype 224 In both SMIv1 and SMv2 MIB modules, the type notation for a bit string 225 encoded in an integer value is written as "INTEGER(0..n)" (or 226 "Integer32(0..n)"), where the value of "n" is 2 raised to the number of 227 bits in the bit string, minus 1. For example, if there are 3 bits in 228 the bit string, then the value of "n" is (2^3)-1, or 7. Conversion from 229 SNMPv2 or SNMPv1 MIB modules first requires a careful review of the 230 OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT-CAPABILITIES, TEXTUAL- 231 CONVENTION, and type assignment constructs to determine which are using 232 a bit string encoded as an integer. For each identified usage, all the 233 bits in the string must be assigned a label. Finally, the text of the 234 DESCRIPTION clause may need to be updated, typically to simplify. 236 The example below shows the definition of sysServices from RFC 1907, and 237 a modified version using the SUM pseudotype. 239 From RFC 1907: 241 sysServices OBJECT-TYPE 242 SYNTAX INTEGER (0..127) 243 MAX-ACCESS read-only 244 STATUS current 245 DESCRIPTION 246 "A value which indicates the set of services that this 247 entity may potentially offers. The value is a sum. This 248 sum initially takes the value zero, Then, for each layer, L, 249 in the range 1 through 7, that this node performs 250 transactions for, 2 raised to (L - 1) is added to the sum. 251 For example, a node which performs only routing functions 252 would have a value of 4 (2^(3-1)). In contrast, a node 253 which is a host offering application services would have a 254 value of 72 (2^(4-1) + 2^(7-1)). Note that in the context 255 of the Internet suite of protocols, values should be 257 Draft SUM Pseudotype May 27, 1996 259 calculated accordingly: 261 layer functionality 262 1 physical (e.g., repeaters) 263 2 datalink/subnetwork (e.g., bridges) 264 3 internet (e.g., supports the IP) 265 4 end-to-end (e.g., supports the TCP) 266 7 applications (e.g., supports the SMTP) 268 For systems including OSI protocols, layers 5 and 6 may also 269 be counted." 270 ::= { system 7 } 272 Modified version using the SUM pseudotype: 274 sysServices OBJECT-TYPE 275 SYNTAX SUM { physical(0), datalinkOrSubnetwork(1), 276 internet(2), endToEnd(3), session(4), 277 presentation(5), applications(6) } 278 MAX-ACCESS read-only 279 STATUS current 280 DESCRIPTION 281 "The set of services that this entity may potentially 282 offer. The members of this set are the protocol 'layers' 283 for which this node performs transactions. For example, 284 a node which performs only routing functions would have 285 a value of { internet }. In contrast, a node which is 286 a host offering application services would have a value 287 of { endToEnd, applications }. Note that in the 288 context of the Internet suite of protocols, the 289 bits should be interpreted accordingly: 291 layer functionality 292 1 physical(0) (e.g., repeaters) 293 2 datalinkOrSubnetwork(1) (e.g., bridges) 294 3 internet(2) (e.g., supports the IP) 295 4 endToEnd(3) (e.g., supports the TCP) 296 7 applications(6) (e.g., supports the SMTP) 298 For systems including OSI protocols, layers 5 and 6 299 should be interpreted normally." 300 ::= { system 7 } 302 Conversion of the SUM pseudotype back to an INTEGER (or Integer32) is 303 quite trivial. 305 Draft SUM Pseudotype May 27, 1996 307 8. Allowed Updates 309 An instance of an SUM pseudotype may not be changed. A modification 310 requires that a new instance of the construct in which it is used be 311 created. (Note that requirement is consistent with that specified in 312 section 10.2 of SMIv2.) 314 9. Acknowledgments 316 Thanks go to Bancroff Scott for his assistance on the BITS macro on 317 which the SUM macro is modeled. 319 10. References 321 [1] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of 322 Management Information for Version 2 of the Simple Network 323 Management Protocol (SNMPv2)", RFC 1902, 01/22/1996. 325 [2] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual 326 Conventions for Version 2 of the Simple Network Management Protocol 327 (SNMPv2)", RFC 1903, 01/22/1996. 329 [3] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance 330 Statements for Version 2 of the Simple Network Management Protocol 331 (SNMPv2)", RFC 1904, 01/22/1996. 333 [4] K. McCloghrie, M. Rose, "Structure and Identification of Management 334 Information for TCP/IP-based Internets", RFC 1155, 05/10/1990. 336 [5] K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212, 337 03/26/1991. 339 [6] K. McCloghrie, M. Rose, "Management Information Base for Network 340 Management of TCP/IP-based internets: MIB-II", 03/26/1991. 342 [7] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Management 343 Information Base for Version 2 of the Simple Network Management 344 Protocol (SNMPv2)", 01/22/1996