idnits 2.17.1 draft-irtf-nmrg-snmp-ops-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 340 has weird spacing: '...for the purpo...' -- 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 (October 1999) is 8958 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) -- Looks like a reference, but probably isn't: '42' on line 173 -- Looks like a reference, but probably isn't: '43' on line 175 -- Looks like a reference, but probably isn't: '44' on line 177 -- Looks like a reference, but probably isn't: '45' on line 179 == Unused Reference: 'ASN1' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 321, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIv2OPS' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Schoenwaelder 2 Internet-Draft TU Braunschweig 3 Expires April 2000 22. October 1999 5 SNMP Protocol Operations for Invoking Operations 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this document is unlimited. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This document defines additional protocol operations for the Simple 37 Network Management Protocol (SNMP) that support more efficient 38 configuration management via SNMP. The CallRequest and CallResponse 39 PDUs add an RPC style operation invocation mechanism to SNMP. The 40 CompoundRequest and CompoundResponse PDUs add a mechanism to send 41 multiple SNMP operations in a single SNMP message. 43 Warning 45 This document has not been written in order to specify a solution. 46 Instead, this document has been written to stimulate (controversial) 47 discussions within the NMRG (and elsewhere). 49 Table of Contents 51 1 Introduction ................................................. 3 52 2 Definitions .................................................. 4 53 3 PDU Processing ............................................... 7 54 4 Usage Examples ............................................... 7 55 5 Open Issues .................................................. 7 56 6 Security Considerations ...................................... 7 57 7 Authors' Address ............................................. 8 58 8 References ................................................... 8 59 9 Full Copyright Statement ..................................... 9 61 1. Introduction 63 The Simple Network Management Protocol (SNMP) is successfully used 64 for tasks such as statistics gathering, status monitoring, topology 65 discovery or event generation/distribution. All these application 66 areas have in common that they mainly require read access to network 67 elements. SNMP has been less successful as a network control protocol 68 that is actually used to configure and exercise control over network 69 elements. 71 One often cited reason for the limited usage as a network 72 configuration or control protocol is the lack of security mechanism 73 in the widely deployed SNMP protocol version 1 (SNMPv1). Recent work 74 on SNMP version 3 (SNMPv3) adds strong message security and access 75 control mechanisms to SNMP. Work on SNMPv3 also adds remote 76 administration MIBs that allow to configure the configuration 77 parameters associated with an SNMP engine. 79 Another reason for the limited success of SNMP as a network 80 configuration or control protocol are the properties of the SNMP 81 SetRequest protocol operation: 83 (1) The SetRequest operation allows a command generator to build 84 arbitrary complex operations that are hard to handle correctly 85 on a command responder. 87 (2) The SetRequest operation does not impose an ordering in the 88 varbind list nor does it impose an ordering in the processing of 89 the varbind list. 91 (3) The SetRequest operation does not return result values upon 92 successful completion of the operation. 94 (4) The SetRequest operation does not return set request specific 95 error codes. 97 (5) It is generally hard to implement and complex operations as side 98 effects on write operations to simple types variables. 100 (6) The message size constraints results of the underlying 101 transports for SNMP messages have lead to MIBs where complex 102 write operations may be realized by a sequence of less complex 103 write operations (dribble mode). 105 (7) The dribble mode add complexity since SNMP allows concurrent 106 access to a command responder from multiple SNMP command 107 generators. This leads to additional complexity (e.g. spin 108 locks) in order to serialize concurrent attempts to perform 109 complex write operations. 111 This document defines two new protocol operations (CallRequest and 112 CallResponse) that add an RPC style operation invocation mechanism to 113 SNMP. Operations are formally defined using an SMIv2 extension and 114 identified by an object identifier [SMIv2OPS]. Operations take a 115 sequence of arguments and return either a sequence of results, an 116 operation specific error code or a generic protocol error code. 118 Two additional protocol operations (CompoundRequest and 119 CompoundResponse) can be used to bind multiple SNMP operations 120 together and to process them in a single SNMP message. This can be 121 used to bind several related operations into a single transaction and 122 reduces the overall message and security processing overhead. 124 2. Definitions 126 SNMP-OPS-PDU DEFINITIONS ::= BEGIN 128 IMPORTS 129 ObjectSyntax 130 FROM SNMPv2-SMI 132 GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, 133 Response-PDU, SetRequest-PDU, InformRequest-PDU, 134 SNMPv2-Trap-PDU, Report-PDU, max-bindings 135 FROM SNMPv2-PDU; 137 max-pdus 138 INTEGER ::= 2147483647 140 PDUs ::= CHOICE { 142 get-request 143 GetRequest-PDU, 145 get-next-request 146 GetNextRequest-PDU, 148 get-bulk-request 149 GetBulkRequest-PDU, 151 response 152 Response-PDU, 154 set-request 155 SetRequest-PDU, 157 inform-request 158 InformRequest-PDU, 160 snmpV2-trap 161 SNMPv2-Trap-PDU, 163 report 164 Report-PDU, 166 call-request 167 CallRequest-PDU, 169 call-response 170 CallResponse-PDU 171 } 173 CallRequest-PDU ::= [42] IMPLICIT OPS-PDU 175 CallResponse-PDU ::= [43] IMPLICIT OPS-PDU 177 CompoundRequest-PDU ::= [44] IMPLICIT COMP-PDU 179 CompoundResponse-PDU ::= [45] IMPLICIT COMP-PDU 181 OPS-PDU ::= SEQUENCE { 183 request-id 184 INTEGER (-2147483648..2147483647), 186 error-status 187 INTEGER { 188 noError(0), 189 tooBig(1), 190 noSuchName(2), -- for proxy compatibility 191 badValue(3), -- for proxy compatibility 192 readOnly(4), -- for proxy compatibility 193 genErr(5), 194 noAccess(6), 195 wrongType(7), 196 wrongLength(8), 197 wrongEncoding(9), 198 wrongValue(10), 199 noCreation(11), 200 inconsistentValue(12), 201 resourceUnavailable(13), 202 commitFailed(14), 203 undoFailed(15), 204 authorizationError(16), 205 notWritable(17), 206 inconsistentName(18), 207 noErrorMoreFollows(19) 208 }, 210 error-index 211 INTEGER (0..max-bindings), -- or sequence number 213 values 214 ValueList 215 } 217 ValueList ::= SEQUENCE (SIZE (0..max-bindings)) OF ObjectSyntax 219 COMP-PDU ::= SEQUENCE { 221 request-id 222 INTEGER (-2147483648..2147483647), 224 error-status 225 INTEGER { 226 noError(0), 227 tooBig(1), 228 noSuchName(2), -- for proxy compatibility 229 badValue(3), -- for proxy compatibility 230 readOnly(4), -- for proxy compatibility 231 genErr(5), 232 noAccess(6), 233 wrongType(7), 234 wrongLength(8), 235 wrongEncoding(9), 236 wrongValue(10), 237 noCreation(11), 238 inconsistentValue(12), 239 resourceUnavailable(13), 240 commitFailed(14), 241 undoFailed(15), 242 authorizationError(16), 243 notWritable(17), 244 inconsistentName(18), 245 noErrorMoreFollows(19) 246 }, 248 error-index 249 INTEGER (0..max-pdus), -- or sequence number 251 pdus 252 PduList 253 } 255 PduList ::= SEQUENCE (SIZE (0..max-pdus)) OF PDUs 257 END 258 3. PDU Processing 260 TBD 262 4. Usage Examples 264 5. Open Issues 266 1. need to support linked Return-PDUs, similar to linked Response- 267 PDUs: where to allocate the missing bit? 269 2. error-status indicates whether values in response contains 270 results, exceptions or arguments 272 3. error-status and error-index are most likely not used in a 273 COMP-PDU (other than having a sequence number in there). 275 4. where to encode the operation name (OID)? 277 5. what to do about access control? for which objects do you call 278 isAccessAllowed()? 280 6. allow a compound PDU within a compound PDU? 282 7. what about a GetConfig-PDU? 284 6. Security Considerations 286 This document defines new SNMP protocol operations to invoke 287 operations on collections of MIB objects and to combine multiple SNMP 288 operations into a single SNMP message. 290 Message security is not affected by these new protocol operations. 291 Message security therefore depends on the security model used by the 292 message format. 294 Compound SNMP operations are processed as if they were send in a 295 sequence of separate messages. Thus, access control is still subject 296 of the access control processing of the protocol operations contained 297 in a compound SNMP operation. 299 Operations that invoke operations on collections of MIB objects rely 300 on the access control for the MIB objects. (TBD) 302 7. Authors' Address 304 Juergen Schoenwaelder 305 TU Braunschweig 306 Bueltenweg 74/75 307 38106 Braunschweig 308 Germany 310 Phone: +49 531 391-3283 311 EMail: schoenw@ibr.cs.tu-bs.de 313 8. References 315 [ASN1] Information processing systems - Open Systems 316 Interconnection - Specification of Abstract Syntax 317 Notation One (ASN.1), International Organization for 318 Standardization. International Standard 8824, December, 319 1987 321 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 322 "Protocol Operations for Version 2 of the Simple Network 323 Management Protocol (SNMPv2)", RFC 1905, January 1996 325 [SMIv2OPS] J. Schoenwaelder, "Operation-Types for SMIv2", , October 1999 328 9. Full Copyright Statement 330 Copyright (C) The Internet Society (1999). All Rights Reserved. 332 This document and translations of it may be copied and furnished to 333 others, and derivative works that comment on or otherwise explain it 334 or assist in its implementation may be prepared, copied, published 335 and distributed, in whole or in part, without restriction of any 336 kind, provided that the above copyright notice and this paragraph are 337 included on all such copies and derivative works. However, this 338 document itself may not be modified in any way, such as by removing 339 the copyright notice or references to the Internet Society or other 340 Internet organizations, except as needed for the purpose of 341 developing Internet standards in which case the procedures for 342 copyrights defined in the Internet Standards process must be 343 followed, or as required to translate it into languages other than 344 English. 346 The limited permissions granted above are perpetual and will not be 347 revoked by the Internet Society or its successors or assigns. 349 This document and the information contained herein is provided on an 350 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 351 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 352 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 353 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 354 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.