idnits 2.17.1 draft-schoenw-policy-snmp-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 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 -- 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 (September 1999) is 8988 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) == Unused Reference: 'RAP-FRAME' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'COPS' is defined on line 792, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'RAP-FRAME') == Outdated reference: A later version (-08) exists of draft-ietf-rap-cops-07 -- No information found for draft-ietf-rap-cops-pr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'COPS-PR' == Outdated reference: A later version (-02) exists of draft-mfine-cops-pib-01 -- Possible downref: Normative reference to a draft: ref. 'COPS-PIB' -- Possible downref: Normative reference to a draft: ref. 'WHY-COPS' == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-snmp-tcp-01 ** Downref: Normative reference to an Experimental draft: draft-irtf-nmrg-snmp-tcp (ref. 'SNMP-TCP') == Outdated reference: A later version (-01) exists of draft-irtf-nmrg-snmp-compression-00 -- Possible downref: Normative reference to a draft: ref. 'SNMP-COMP' ** Obsolete normative reference: RFC 2096 (Obsoleted by RFC 4292) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Saperia 2 Internet-Draft IronBridge Networks 3 Expires March 2000 J. Schoenwaelder 4 TU Braunschweig 5 14. September 1999 7 Policy-Based Enhancements to the SNMP Framework 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this document is unlimited. 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This memo takes a look at some of the work on policy-driven networks 39 currently being done in several IETF working groups. The proposed 40 solutions (like COPS and PIBs) focus on solving local problems of 41 policy management. It is the view of the authors that while local 42 solutions like COPS can be more effective than more general ones, the 43 advantages to effective management through the use of a single 44 integrated management framework (an improved SNMP) outweigh the gains 45 of locally optimized solutions. 47 Table of Contents 49 1 Introduction ................................................. 3 50 2 Background ................................................... 3 51 3 Statement of the Problem - Need for Integrated Management .... 4 52 4 Requirements ................................................. 4 53 4.1 Multiple Management Stations ............................... 4 54 4.2 Multiple Users in Multiple Roles ........................... 5 55 4.3 Connection-oriented and Connection-less Management ......... 5 56 4.4 Hierarchically Managed Networks/Overlapping Domains ........ 5 57 Integration ............................................... 6 58 4.6 Compatibility with SNMP Management Data .................... 6 59 4.7 Multiple Configurations and Switching Configurations ....... 6 60 4.8 Evolution of Configuration Management Data ................. 7 61 5 Issues with COPS/PIB Approach ................................ 7 62 5.1 Incomplete SoPI Definition ................................. 7 63 5.2 PIB Instance Identification ................................ 8 64 5.3 Missing Contexts ........................................... 8 65 5.4 Evolution of PIBs .......................................... 8 66 5.5 Configuration Management for exisiting MIBs ................ 9 67 5.6 Manual Translations between PIBs and MIBs .................. 9 68 6 Possible Changes to SNMP ..................................... 9 69 6.1 SMIv2 Extensions to Define Operations ...................... 9 70 6.2 SNMP Transaction Support ................................... 10 71 6.3 Transport over TCP ......................................... 10 72 6.4 Additional Protocol Operations ............................. 10 73 6.5 Efficiency Improvements .................................... 11 74 7 Comments on draft-kzm-policy-protocomp-00.txt ................ 11 75 7.1 Section 3.3 Exclusive Access by the PDP .................... 11 76 7.2 Section 3.5 COPS Takes Advantage of TCP .................... 11 77 7.3 Section 3.7 COPS over TCP (Revisited) ...................... 14 78 7.4 Section 3.8 Modifying Message Formats ...................... 14 79 7.5 Section 3.9 Initiation by the PEP .......................... 15 80 7.6 Section 3.10 Deleting Policy ............................... 15 81 7.7 Additional Sections ........................................ 16 82 8 Conclusions .................................................. 17 83 9 Suggested Plan of Action ..................................... 18 84 10 References .................................................. 19 85 11 Authors' Address ............................................ 20 87 1. Introduction 89 With the addition of Differentiated Services and other technologies, 90 the need for policy based management has grown. A number of working 91 groups including the Policy Framework and Resource Allocation 92 Protocol working groups needed support for the configuration of 93 policy in the network. SNMP was evaluated by these working groups and 94 in some cases and found lacking in a number of areas. As a result, 95 new work was undertaken which led to COPS and PIBs among other 96 things. These solutions focused on solving the local problems of 97 policy management. 99 This document was prepared for a meeting involving some of the 100 involved area directors and working group participants scheduled to 101 take place in mid September 1999. The purpose of the meeting is to 102 help the Area Directors gather information about the various 103 proposals and the needs that they are to address. In addition, these 104 needs will be evaluated against the features available in SNMP. This 105 document has an additional purpose in addition to preparation for the 106 meeting. It is background for a proposal to integrate the best 107 features of COPS/PIBs and the best features of SNMP that is hoped 108 will evolve from the Chicago meeting. Local solutions like COPS can 109 be, if properly specified and implemented, more effective than 110 general ones. However, the advantages to effective management through 111 the use of a single integrated management framework (e.g., an 112 improved SNMP) far outweigh the gains of locally optimized solutions. 114 2. Background 116 Over the years SNMP has evolved and most recently has undergone the 117 addition of improved security and refinement of the specifications. 118 In many important areas, such as the ability to retrieve large 119 amounts of data and support complex configuration operations, many 120 people felt that SNMP did not provide adequate solutions. 122 Given this view, people sought other solutions to fill in the gaps 123 (real or perceived) that existed in SNMP. 125 The solutions range from formal protocol proposal like COPS to 126 informal and proprietary solutions offered by vendors or implemented 127 by network operations staffs. The result is a management environment 128 which is fragmented. SNMP has been dominant in the areas of network 129 status monitoring and statistics gathering, but has not been widely 130 used for configuration management. This fundamental split makes 131 problem resolution more costly and difficult. 133 The original focus of this draft was to have been cross referencing 134 on how SNMP can meet the stated needs of the community. In the view 135 of the authors, SNMP does need some enhancements in order to be 136 effective in the policy area. These enhancements are not driven only 137 by policy requirements since they can benefit all areas of 138 management. We are advocates for effective management - not for a 139 particular protocol. We felt that a good approach would be to work 140 with the community to develop a clearly articulated list of 141 requirements (which should not be to difficult), evaluate some of the 142 principles that have been developed for COPS etc. and create a list 143 of additions needed for SNMP. This is based on the belief that the 144 Internet needs an integrated management approach to deal with the 145 challenges of the coming years. 147 3. Statement of the Problem - Need for Integrated Management 149 It is a strongly held view by many that when configuration 150 information (policy provisioning data is just one kind of 151 configuration data) is in a different form than fault and other types 152 of data, that management becomes more difficult. Imagine a network 153 operator tasked with relating the failure of an interface which is 154 the backup interface (in a sonet APS sense) to an SLA if the SLA has 155 been expressed in a form which makes it difficult to associate the 156 failed component. This can only be done when instance level 157 information is known. This is not a dismissal of the powerful 158 concept of classes found in the various framework and schema 159 documents that have been published over the past few months. To the 160 contrary, the concepts can be well used to augment the existing 161 management framework. Using this approach a more integrated method 162 of management can be achieved. 164 4. Requirements 166 For effective management to take place, there are a number of 167 requirements relevant to the current discussion which can not be 168 ignored. Below are some of the areas which any policy management 169 paradigm must address to successfully integrate into currently 170 deployed Internet management environment. 172 4.1. Multiple Management Stations 174 Multiple management systems exist today for concurrent access to 175 managed elements for a wide variety of reasons. In modern networks 176 service and performance interruptions must be kept to a minimum - 177 this applies to the management infrastructure as well. As a result, 178 multiple standby management components are often on hot stand-by and 179 in full sync with their primary counterparts to avoid extra delay for 180 connection re-establishment in the case of failure. These standby 181 components are often geographically dispersed. 183 Beyond the basic issues of multiple redundant components, multiple 184 management systems may need to be in communication with managed 185 devices (often concurrently) for other reasons. In some cases, 186 different organizations within the management community perform 187 different configuration functions (e.g., routing, versus provisioning 188 of the hardware). These different aspects are often related to 189 policy. 191 4.2. Multiple Users in Multiple Roles 193 From the previous item, it should be clear that multiple users must 194 have access to a single system - often concurrently. What is also 195 true is that not all management personnel are given the same 196 privileges with respect to access to information. Some people are 197 allowed only read access to certain configuration information while 198 others are permitted to have full access to a wider range of 199 management objects inside the network elements. A restricted few 200 have wide and full access. Even in these cases, there may be some 201 systems within a particular administrative domain that have even more 202 restrictive access. Policy/Configuration information is sensitive and 203 management operations staffs require flexibility in the permissions 204 given people in different roles. 206 4.3. Connection-oriented and Connection-less Management 208 A great deal has been written and tried over time for management with 209 connection-oriented and connection-less approaches. What may be 210 needed is a combination of the two since neither one meets all types 211 of requirements. Connection-less polling for short term information 212 is far less costly than maintaining many (potentially thousands) of 213 connections for the collection of this type of data - connection- 214 oriented management systems have always been problematic with regard 215 to scale. Status polling for certain types of information also has 216 some scale problems, so asynchronous notification is a viable 217 scalable alternative. 219 Connection-oriented management for the retrieval of large amounts of 220 data or the transmission of complex configuration information has 221 proved to be of great value over time. 223 4.4. Hierarchically Managed Networks/Overlapping Domains 225 Networks of size must provide for some level of hierarchical 226 management and overlapping management domains. Often management has 227 a functional flavor where the WAN folks deal with part of the net, 228 and the local people deal with another part of the network. To some 229 extent, even in the policy area there will be overlap. Imagine an 230 edge device which is subject to the policies of multiple 231 administrative domains. Hierarchy is not always exactly straight up 232 and down and it is often the case that policy does not have clean 233 boundaries and systems must to some degree have multiple masters. 235 4.5. Policy and Instance Specific Information - Required Integration 237 The idea of saving data transfer to the PEP by avoiding the 238 granularity of instance level data is a helpful concept. There is 239 often some configuration information that is required on a per 240 instance basis. A good example would be the IP address of an 241 interface. It is essential that these two types of information, 242 general policy rules/roles and specific instance related information 243 be well connected otherwise detecting and correcting configuration 244 errors will be more difficult. 246 One of the side effects of requiring the PEP to convert to instance 247 level data is that while the transmission of the data to the machine 248 would be less resource intensive than if SNMP based instance level 249 data were sent, there will be considerable additional processing 250 needed to make the conversion. In addition it will require a global 251 knowledge of the system and 'smarts' to make the conversion that are 252 not currently available in many systems. Please also see next point. 254 4.6. Compatibility with SNMP Management Data 256 If a card or some other hardware or software component fails, it is 257 important to tie this to the SLA or SLAs that are in jeopardy. In 258 large systems especially this will require the tight integration of 259 the information described in the various policy documents with other 260 standard information. The failure will always be expressed in terms 261 of instance specific information. In fact only by evaluation of the 262 instance specific information can a determination be made about the 263 impact to an SLA. 265 Similarly, data about the utilization of various resources in the 266 network is necessarily collected via SNMP based mechanisms. It will 267 be impossible to make good policy decisions without this information. 268 The conversion of this (SNMP) data to another format could be costly. 270 4.7. Multiple Configurations and Switching Configurations 272 Configuration management systems in general have to support the 273 notion of multiple configurations. There are usually at least two 274 configurations stored in networking devices: The currently active 275 configuration and a configuration which is stored in stable storage 276 and reloaded upon re-initialization. 278 Some devices contain additional configuration sets so that changes 279 can be made without risking disruption to existing services and to 280 allow operators to program automated switching between different 281 complex configurations (e.g. based on the time of day). Such a switch 282 between configurations may affect lots of devices and it should 283 therefore be supported in an effective way. 285 4.8. Evolution of Configuration Management Data 287 Configuration management data models are not fixed for all time and 288 are subject to evolution like any other management data model. It is 289 therefore necessary to anticipate changes in the configuration data 290 model and to provide mechanisms that can deal with changes 291 effectively without causing interoperability problems or having to 292 replace/update large amounts of fielded networking devices. 294 5. Issues with COPS/PIB Approach 296 This section lists some problems with the current COPS/PIBs approach. 297 The focus here is on conceptual problems rather than technical 298 details of the specifications. 300 5.1. Incomplete SoPI Definition 302 The COPS policy provisioning protocol [COPS-PR] requires a new 303 language called Structure of Policy Information (SoPI) which is used 304 to define concrete policy objects in a Policy Information Base (PIB). 305 SoPI is defined by refering to the SMIv2 standard and making several 306 changes as described in Section 4.1 in [WHY-COPS]. There are several 307 problems with this approach. 309 First, the ad-hoc definition of SoPI leaves many issues unspecified. 310 It is for example unclear whether the usage of the Counter32 SMIv2 311 base type is allowed in PIBs. It is also unclear how SMIv2 base data 312 types with restricted SMIv2 access interact with the POLICY-ACCESS 313 clause. Another example are the SMIv2 macros to describe compliance 314 requirements. Are they also applicable to PIBs? Or is every 315 implementation required to implement a full PIB even if some of the 316 PIB objects do not make sense on a particular device? 318 These are only examples of questions that arise since there is no 319 real definition of the Structure of Policy Information (SoPI). Many 320 more can be found be carefully analyzing the SMIv2 definition in 321 light of the COPS/PIB approach to policy provisioning. 323 5.2. PIB Instance Identification 325 The SoPI and the COPS protocol requires that all instances are 326 indentified by what is called a Policy Rule Instance Identifier 327 (PRID). The POLICY-FRAMEWORK-PIB [COPS-PIB] introduces the 328 PolicyInstanceId textual convention derived from Unsigned32 to 329 identify policy rule instances. 331 It is at least unclear whether more complex PRIDs are legal. 332 Simple-minded PRIDs introduce a need to map MIB instance identifiers, 333 which are in many cases complex and meaningful, to PRID values used 334 in PIBs. Furthermore, such a simple PRID identification schemes makes 335 direct translation of PIBs into MIBs in many cases useless since 336 table indexing in MIBs is usually optimized for typical retrieval 337 operations and/or efficient access control. 339 5.3. Missing Contexts 341 The SNMP evolution has lead to the introduction of contexts which 342 contain collections of MIB variables. Contexts turn out to be a very 343 useful thing in order to handle multiple instantiations of MIB trees, 344 which would map to multiple configurations in the policy provisioning 345 scenario. 347 The COPS/PIB approach is missing a similar mechanism. Instead, each 348 instance of a rule class can only exist once. It is therefore not 349 possible to easily describe and manipulate multiple configurations, 350 which makes policy changes at for example a particular time during a 351 day costly. In this scenario, COPS/PIBs require to remove all policy 352 data from all PEPs and to install new policy data on them. 354 5.4. Evolution of PIBs 356 SMIv2 MIBs and the SNMP protocol have the important property that 357 individual definitions can be added, updated or removed without 358 having to deprecate complete tables. This allows for a smooth 359 evolution of SMIv2 MIBs and experience with for example the 360 Interfaces MIB [RFC-2233] shows that changes are unavoidable. 362 The PIBs in contrast do not support such an evolution of PIBs. The 363 reason is basically that the install/remove/notify operations are 364 bound to a PIB class (which corresponds to a MIB table) and that the 365 COPS-PR protocol only transfers a sequence of values. Thus, changes 366 like the addition of an element to a class (table) requires to 367 completely redefine the whole table. 369 Furthermore, it can be expected that some implementations will not 370 support all elements of a class (table) definition. There is no 371 mechanism to deal with this situation in an explicit way. Hence, a 372 PEP which does not support all elements of a class (table) still has 373 to conform to the interface and it has to provide/accept dummy values 374 during notify or install operations. This can lead to serious 375 problems in troubleshooting situations since dummy values are hard to 376 identify. 378 5.5. Configuration Management for exisiting MIBs 380 The COPS/PIBs proposal can not be directly applied for policy 381 provisioning with existing MIBs. A good example are SNMP access 382 control tables [RFC-2575] or IP forwarding tables [RFC-2096] for 383 which well known MIB definitions do exist. 385 The fact that there are two different languages to describe the same 386 information seems like a costly way to operate networks and it will 387 lead to duplication of work within the IETF. It will also lead to 388 more complexity in typical implementations. 390 5.6. Manual Translations between PIBs and MIBs 392 There is no algorithm that can automatically convert a PIB into a 393 MIB. There are also no provisions to leverage existing MIBs and to 394 make them available for more efficient configuration management 395 without having to manually redefine the MIB as a PIB. 397 The authors believe that it is desirable to have a single and 398 coherent language and format for defining management information. In 399 particular, it should be possible to use the same definition for 400 monitoring and configuration management purposes. The introduction of 401 multiple languages with manual translations between them introduces 402 costs and another source of possible inconsistencies. 404 6. Possible Changes to SNMP 406 In this section, we will briefly outline changes to the SNMP 407 Framework that will enhance the SNMP Framework to support Policy- 408 Based management. Some of the changes listed below are actually 409 being worked on for other reasons, mainly to improve the efficiency 410 of bulk data transfers. 412 6.1. SMIv2 Extensions to Define Operations 414 The SMIv2 should be extended to allow the definition of operations on 415 collections of managed objects (typically on table rows). A 416 definition of an operation should include the operation signature, 417 which includes the operation name (a registered OID value), the 418 arguments of the operation (a list of object-types), the results 419 produced by the operation (a list of object-types) and operation 420 specific exceptions. It is important to reduce the degree of freedom 421 that currently exist with the SNMP set operation. Furthermore, it is 422 necessary that SMIv2 defined operations can be mapped to APIs in 423 frequently used implementation languages automatically in order to 424 make the development of (configuration) management applications more 425 efficient and cost effective. 427 An SMIv2 extension for operations will allow the definition of 428 install/remove/notify operations on table rows for existing as well 429 as future MIB modules. Care must be taken to allow proper versioning 430 of operation definitions since MIB definitions (such as conceptual 431 table) can and will change over time. 433 6.2. SNMP Transaction Support 435 There is a need for enhanced transaction support across sequences of 436 simple SNMP operations. In its simplest form, a transaction will be 437 made up of a sequence of SNMP operations targeted at the same SNMP 438 entity. 440 6.3. Transport over TCP 442 An SNMP over TCP transport mapping is needed in order to enable more 443 efficient bulk data transfers and to ease the implementation of 444 larger transactions. A document defining SNMP over TCP is under 445 development by the Network Management Research Group (NMRG) [SNMP- 446 TCP]. 448 It is important to realize that an SNMP over TCP transport mapping 449 complements the SNMP over UDP transport mapping and does not replace 450 it. 452 6.4. Additional Protocol Operations 454 The SNMP protocol could be extended with additional PDUs if necessary 455 that realize operations on collections of object-types. This 456 minimally requires the introduction of a new "CallOperation" PDU. 457 Support for larger transactions may require the introduction of 458 additional PDUs unless one uses other mechanisms for transaction 459 handling (such as contexts or transport system mechanisms). 461 6.5. Efficiency Improvements 463 Bulk data transfers are not very efficient with SNMP since the 464 payload contains large amounts of redundant OID fragments. This is 465 caused by common OID prefixes and instance identifiers in the 466 payload. A compression scheme is one potential solution to increase 467 the bandwidth efficiency of SNMP [SNMP-COMP]. Such a mechanism may 468 have advantages over alternate encoding schemes since the receiving 469 application still has access to full instance-level names rather than 470 just a sequence of values. This provides for robustness since 471 ordering or omission problems in the encoded values, which may be 472 caused by legal changes to the MIB definition or simply 473 implementations that support only subsets of the standardized 474 configuration information, can be detected and dealt with. 476 7. Comments on draft-kzm-policy-protocomp-00.txt 478 This section comments on the document [WHY-COPS] which was intended 479 as a comparison between COPS and SNMP. The introduction read in part, 480 "it has been requested that a comparison be undertaken as to why COPS 481 is better suited to this than a (modified if necessary) version of 482 SNMP". 484 At first glance, it seems to be well written and appears to make a 485 number of good points. However, upon closer examination, several of 486 the points made in that document deserve further scrutiny in order to 487 arrive at a more balanced view. 489 7.1. Section 3.3 Exclusive Access by the PDP 491 An early major point of the [WHY-COPS] document is that different 492 requirements have led to different design choices for COPS/PIBs vis- 493 a-vis SNMP/MIB. One of these requirements differences is with regard 494 to the "single PDP" versus "multiple manager" dimension and the 495 design choices that spring therefrom. 497 The COPS document considers the possibility of multiple PDPs 498 operating on a system which had multiple sets of policy. It was not 499 made clear how this can or should/will work within a single managed 500 system. 502 7.2. Section 3.5 COPS Takes Advantage of TCP 504 A second major point is that of choice of transport: TCP versus UDP. 505 It has a number of sub-points. 507 The first is maximum message size. The document contrasts the 508 maximum message size of a COPS object (64KB) with the minimum size an 509 SNMP implementation must support (484 bytes). It fails to 510 acknowledge that the maximum message size of an SNMP message is also 511 64KB (actually virtually unlimited -- limited to 2 billion varbinds 512 and the practical limit comes from the buffering capability of the 513 underlying operating system and maximum message size of the transport 514 which goes up to 64KB for UDP). The document does correctly state 515 that messages this large are rare. One could quibble over the stated 516 value of 1500 bytes but it is not of importance for this discussion. 518 One reason this is of no importance is that the SNMP-based framework 519 allows a large transaction to be broken into groups of multiple, 520 smaller, transactions. Each transaction-let can be transported 521 independently and then made to go active simultaneously. Not only 522 can all columns of an entire row be made active simultaneously, 523 multiple rows can be made active simultaneously. This is a MIB and 524 application design issue, not a protocol issue, as it properly should 525 be. The related portions of policy can be conveyed independently and 526 made active simultaneously, hence SNMP-based management can be used 527 to convey policy information (or any other information) without 528 concern for the maximum message size. Operational experience 529 indicates that it is possible to move a management script consisting 530 of multiple tens of kilobytes via SNMP/MIB and then to activate the 531 script. Although it is not suggested that SNMP will replace FTP over 532 TCP, the applicability to moving other management information, such 533 as policy configuration data, is obvious. 535 Section 3.5 talks about the problems with incremental creation of a 536 read-create table and how atomic access is easier to implement and 537 test. In many of today's modern SNMP implementations, the code to 538 implement incremental and atomic row creation and deletion are a part 539 of a subroutine library and the grungy details are isolated from the 540 developer who uses it and who may not be an SNMP expert. As a result 541 of wrapping a powerful API and automatically generated code around 542 the row creation, implementation and test is not as difficult as 543 represented and movement to COPS' atomic creation does not yield the 544 stated advantages. 546 Finally, with regard to incremental creation, there is an additional 547 important point worthy of discussion. One reason for the ability to 548 handle incremental creation is that there is a possibility of version 549 skew in the version of the information known by the sender and the 550 information known by the receiver as would occur because of evolution 551 of the PIB, such evolution to be expected. COPS/PIB needs a robust 552 mechanism for dealing with this evolution. 554 Another point made in the discussion of TCP versus UDP is that COPS 555 can afford to rely on TCP because the design choices for COPS assume 556 that the network is up and working. SNMP's typical use of UDP is an 557 appropriate one because research and field experience have shown that 558 UDP, with an appropriate application layer retransmission strategy is 559 more robust, and provides a lower mean time to conduct a transaction, 560 than does TCP with it one-size-fits-all retransmission algorithm. 561 This is particularly true when the network is at or near congestion 562 collapse. 564 It seems obvious that if you ever want SNMP to work, you want it to 565 work when the network is at or near congestion collapse, and the 566 choice of a UDP transport with an intelligent application-layer 567 retransmission algorithm would be an appropriate design choice. 569 Similarly, it seems obvious that if you ever want policies to work, 570 especially RSVP and diffserv-related policy, you want it to work when 571 the network is at or near congestion collapse, and the choice of a 572 UDP transport with an intelligent application-layer retransmission 573 algorithm would again be an appropriate design choice. Such a choice 574 would be important in minimizing the mean time to complete those 575 transactions that could be used to bring the network back from the 576 brink of congestion collapse. 578 The [WHY-COPS] document failed to make the critical distinction 579 between transport reliability obtained through retransmission and 580 transactional integrity. 582 A third major point is that SNMP operations are more complex than are 583 necessary for COPS/PIBs. 585 In order to make this point, the authors use an example from the 586 User-based Security Model (USM) for creating a row in a user table, 587 along with appropriate secrets. Aspects of this table that are not 588 explained in the document are that the creation of secrets on the new 589 user comes from a manipulation of the keys of a user being "cloned" 590 from. These operations allow the creation of a new user and new 591 secrets to be done in the clear, but without disclosing either the 592 new or the old secrets. Consequently, neither the old nor the new 593 secret can be read, and the operation must be idempotent. The 594 operation must be performed at least once and at most once, therefore 595 exactly once even during periods of network instability. Therefore, 596 this is fundamentally a harder problem than typically encountered. 598 Furthermore, sometimes writers of specifications intentionally elect 599 to write algorithms in "simpleminded" baby steps in the interest of 600 reader understanding rather than implementation efficiency. This 601 algorithm is such an example. As a result, it is inappropriate to 602 compare a COPS-based approach with no exception handling to a non- 603 optimized approach with exception handling. A better comparison would 604 be to document the steps one would use with a COPS-based approach to 605 perform an idempotent operation and to be able to determine if the 606 operation succeeded or failed in the presence of a race condition 607 between the loss of the management connection and the conclusion of 608 the transaction/sending of the response. 610 Of course, it is possible that a COPS proponent might say that it is 611 not necessary or appropriate to perform operations that must be 612 conducted exactly once. If that is the case, then it is not 613 appropriate to compare with an example that achieves that which is 614 unnecessary. 616 7.3. Section 3.7 COPS over TCP (Revisited) 618 Section 3.7 claims that the use of COPS over TCP is different from 619 and superior to SNMP/MIB with respect to the volatility of 620 provisioned policy information. The document states that COPS over 621 TCP can invoke an expire timeout on provisioned policy information 622 after loss of communications with a PDP. The expire timeout 623 information comes as a part of the policy information. 625 Sometimes the [WHY-COPS] document uses "SNMP" to mean the entire 626 SNMP-based Internet-standard Management Framework (including the SMI, 627 MIB, and Protocol with security and administration) and at other 628 times uses "SNMP" to mean merely the protocol portion of the 629 management framework. This is unfortunate and sometimes misleads the 630 reader. 632 The section goes on to say that SNMP is different whereas in reality 633 it is the same. In the SNMP-based management framework, the 634 volatility of MIB information to be stored, as the document states, 635 is communicated along with the MIB information. Having volatility 636 information or timer information in MIB data which could be directly 637 applied to expiry rules is neither new nor unusual. One of the 638 oldest examples is ipRouteAge, which dates back to MIB I and 1988. 639 More recently, it has become customary for MIB documents to use the 640 StorageType textual convention, which designates data to be volatile, 641 non-volatile, permanent, etc. It is obviously easy to use a similar 642 textual convention to associate a time-based MIB object which conveys 643 expiry information with MIB-based policy data in an manner that is 644 exactly analogous to that of COPS over TCP. In this case, the expiry 645 would be invoked when communications between the PDP and PEP were 646 lost. 648 Contrary to the claim, SNMP is no different and COPS over TCP offers 649 no advantages in this regard. 651 7.4. Section 3.8 Modifying Message Formats 653 Section 3.8 makes the point that COPS messages use a TLV format, 654 making COPS superior to SNMP. SNMP similarly uses a TLV format. 656 Section 3.8 also speaks to the fact that in SNMP the varbindlist in a 657 response is identical to that of the corresponding request. This is 658 an important design feature. This feature was added in order to 659 insure that systems (including managers and agents) designed around 660 the SNMP-based management framework were able to attain transactional 661 integrity. It is important to distinguish between transactional 662 integrity and transport reliability. 664 7.5. Section 3.9 Initiation by the PEP 666 It is interesting to note that the document compares apples and 667 oranges in that it contrasts the COPS approach wherein the PEP, such 668 as a router, querying the PDP, i.e., pulling the policy data. 669 However, in the SNMP approach, it has the PDP doing set requests on 670 the PEP, i.e., pushing the policy data. Section 3.9 dismisses this 671 approach without a fair analysis. 673 The SNMP protocol has since its invention a mechanism to send 674 unsolicited notifications. SNMPv3 includes a confirmed operation to 675 submit notifications. It is therefore very well possible that a PEP 676 can initiate a configuration over SNMP in much the same way a 677 configuration can be initiated using COPS by sending a notification 678 to the PDP which in turn installs the relevant MIB objects on the 679 PEP. The statement that a PEP router likely requires a command 680 generator for this purpose seems to ignore this possibility and may 681 mislead readers. 683 The analysis fails to consider the use of logical contexts to sort 684 out the subset of relevant policies for a given router and throws in 685 SQL as a red herring. According to the last paragraph of the 686 section, the COPS approach is for the PEP to indicate its 687 capabilities and status to the PDP. The PDP then sends the relevant 688 policies via COPS. It is equally practical for the PEP to use an 689 SNMP/MIB-based approach to indicate its capabilities and status to 690 the PDP and for the PDP to provide the relevant policies via 691 SNMP/MIB. 693 7.6. Section 3.10 Deleting Policy 695 Section 3.10 rightly states that MIB objects can be used to delete 696 multiple instances to be deleted and that RowStatus is a common 697 mechanism for deleting a particular row. If there is a need for a 698 mechanism to delete all rows in a table, definition and 699 implementation is done through the MIB, i.e., this is a MIB 700 definition issue. The fact that objects to delete all rows in a 701 table are rare is simply a reflection of the fact that the 702 requirement for such a capability has been rare. 704 7.7. Additional Sections 706 Later sections of the document discuss hypothetical scenarios. During 707 the meeting we can discuss a wide range of opportunities for 708 modification of SNMP and integrating value add features from 709 COPS/PIBs. 711 8. Conclusions 713 The publication of COPS as a proposed standard without consideration 714 of how that standard is to relate to the IETF standard management 715 protocol, SNMP, will have a number of undesired effects. This would 716 be particularly unfortunate if the benefits of the COPS/PIB approach 717 were not as significant as claimed in [WHY-COPS]. The undesired 718 effects include fragmenting focus and resources in the IETF, vendors 719 and customers, and adding confusion in an already difficult area. For 720 example, how does the policy information in COPS relate to the 721 instance based fault information which is widely deployed using SNMP? 723 The already difficult problem of management will be made more so if 724 we start configuring policy with COPS/PIBs and do other management 725 with SNMP. Some excellent work has taken place in the Policy area. 726 Some of the COPS ideas, and a good deal of the work described in the 727 Policy Framework and other documents are very helpful - they do not 728 require a new protocol. Implementing these ideas with SNMP where 729 changes are necessary to support them would result in a unified 730 management environment utilizing the best features of both. 732 In the end it is necessary to read performance information via SNMP. 733 Policy information can be read by SNMP. Configuration of device 734 instance specific information via SNMP is and will continue to be 735 done. The only item remaining is configuration of policy based 736 information. It makes sense to evolve SNMP so that it can meet this 737 important requirement. 739 The differences between the COPS/PIB approach and the SNMP/MIB 740 approach are not as great as presented. The advantages of COPS/PIB 741 over SNMP/MIB do not outweigh the importance of a single, consistent, 742 and coordinated management approach which is complementary to the 743 vast installed base of SNMP-based management. 745 9. Suggested Plan of Action 747 Many of the best proposals are the result of a concentrated effort by 748 interested and involved individuals. We recommend that this approach 749 be used in this case. Realizing that time is important and that 750 pragmatic trade-offs are necessary the following is the recommended 751 course of action: 753 1. Within a short time of the meeting the involved area directors 754 and working group chairs should reach agreement on details with 755 regard to the participants. That is, they will have selected 756 (or be in the process of selecting) a small group of individuals 757 representing many disciplines. This approach has been 758 successfully employed many times in a variety of circumstances 759 in the IETF. 761 2. The first step will be the laundry listing of policy related 762 features which are deemed mandatory. Input for this effort will 763 naturally come from COPS/PIBs and much of the other related work 764 that has been done. This work should be completed in time for 765 the IETF in Washington. 767 3. The Area Directors and Working Group Chairs should work together 768 to make good presentations to the working groups involved so 769 that the community can add anything to the requirements. 771 4. Within 2 weeks after the close of the IETF, requirements 772 gathering should close. The closure of this phase is not a 773 prerequisite to starting the other phases of the project listed 774 below. 776 5. After the requirements have been identified, the changes 777 necessary to SNMP should be isolated. 779 6. These changes should then be integrated into a revised set of 780 the impacted SNMP documents and put out for a review about 1 781 month prior to the spring IETF. 783 7. Issues can be discussed at the Spring IETF and then closed on 784 the mailing lists within 4 - 6 weeks after the meeting. 786 10. References 788 [RAP-FRAME] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 789 for Policy-based Admission Control", draft-ietf-rap- 790 framework-03.txt, April 1999. 792 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 793 A. Sastry, "The COPS (Common Open Policy Service) Protocol", 794 draft-ietf-rap-cops-07.txt, August 1999. 796 [COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, 797 R., Gai, S., McCloghrie, K., and A. Smith,"COPS Usage for 798 Policy Provisioning", draft-ietf-rap-cops-pr-00.txt, June 799 1999. 801 [COPS-PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S., 802 and A. Smith, "Quality of Service Policy Information Base", 803 draft-mfine-cops-pib-01.txt, June 1999. 805 [WHY-COPS] McCloghrie, K., and M. Fine, "A Comparison of Policy 806 Provisioning Protocols", draft-kzm-policy-protcomp-00.txt, 807 September 1999. 809 [SNMP-TCP] J. Schoenwaelder (editor), "SNMP-over-TCP Transport 810 Mapping", draft-irtf-nmrg-snmp-tcp-01.txt, June 1999. 812 [SNMP-COMP] J. Schoenwaelder (editor), "SNMP Payload Compression", 813 draft-irtf-nmrg-snmp-compression-00.txt, June 1999. 815 [RFC-2096] F. Baker, "IP Forwarding Table MIB", RFC 2096, January 1997. 817 [RFC-2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB 818 using SMIv2", RFC 2233, November 1997. 820 [RFC-2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 821 Access Control Model (VACM) for the Simple Network 822 Management Protocol (SNMP)", RFC 2575, April 1999. 824 11. Authors' Address 826 Jon Saperia 827 IronBridge Networks 828 55 Hayden Avenue 829 Lexington, MA 02173 830 USA 832 Phone: +1 781-402-8029 833 Fax: +1 781-402-8090 834 EMail: saperia@mediaone.net 836 Juergen Schoenwaelder 837 TU Braunschweig 838 Bueltenweg 74/75 839 38106 Braunschweig 840 Germany 842 Phone: +49 531 391-3283 843 EMail: schoenw@ibr.cs.tu-bs.de