idnits 2.17.1 draft-kzm-rap-pol-aux-mib-01.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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 535 has weird spacing: '...imed to perta...' -- 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 (12 July 2000) is 8660 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 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- 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 (-09) exists of draft-ietf-rap-frameworkpib-01 ** Downref: Normative reference to an Historic draft: draft-ietf-rap-frameworkpib (ref. 'FRAMEPIB') == Outdated reference: A later version (-08) exists of draft-ietf-policy-core-info-model-06 Summary: 19 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chan 3 Internet Draft J. Seligson 4 Expires January 2001 Nortel Networks 5 K. McCloghrie 6 M. Fine 7 Cisco Systems 8 S. Hahn 9 Intel 10 A. Smith 11 No Affiliation 12 F. Reichmeyer 13 IP Highway 15 12 July 2000 17 The Policy Device Auxiliary MIB 19 draft-kzm-rap-pol-aux-mib-01.txt 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with all 24 provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are 25 working documents of the Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Distribution of this document is unlimited. Please send comments to the 41 Resource Allocation Protocol (RAP) Working Group at rap@iphighway.com. 43 Draft Policy Auxiliary MIB July 2000 45 Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 Draft Policy Auxiliary MIB July 2000 51 1. Introduction 53 This memo defines a portion of the Management Information Base (MIB) for 54 use with network management protocols in the Internet community. In 55 particular, it describes managed objects used for managing Policy Client 56 devices, including the relationship between device interfaces and policy 57 role combinations. Policy role combinations are used as part of the 58 data model for policy information when a Policy Client is provisioned 59 using the COPS protocol [COPS-PR] and a Policy Information Base (PIB) 60 [FRAMEPIB]. 62 2. The SNMP Network Management Framework 64 The SNMP Management Framework presently consists of five major 65 components: 67 - An overall architecture, described in RFC 2571 [RFC2571]. 69 - Mechanisms for describing and naming objects and events for the 70 purpose of management. The first version of this Structure of 71 Management Information (SMI) is called SMIv1 and described in STD 72 16/RFC 1155 [RFC1155], STD 16/RFC 1212 [RFC1212] and RFC 1215 73 [RFC1215]. The second version, called SMIv2, is described in STD 74 58, which consists of RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 75 2580 [RFC2580]. 77 - Message protocols for transferring management information. The 78 first version of the SNMP message protocol is called SNMPv1 and 79 described in STD 15/RFC 1157 [RFC1157]. A second version of the 80 SNMP message protocol, which is not an Internet standards track 81 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and 82 RFC 1906 [RFC1906]. The third version of the message protocol is 83 called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 84 [RFC2572] and RFC 2574 [RFC2574]. 86 - Protocol operations for accessing management information. The first 87 set of protocol operations and associated PDU formats is described 88 in STD 15/RFC 1157 [RFC1157]. A second set of protocol operations 89 and associated PDU formats is described in RFC 1905 [RFC1905]. 91 - A set of fundamental applications described in RFC 2573 [RFC2573] 92 and the view-based access control mechanism described in RFC 2575 93 [RFC2575]. 95 Draft Policy Auxiliary MIB July 2000 97 A more detailed introduction to the current SNMP Management Framework 98 can be found in RFC 2570 [RFC2570]. 100 Managed objects are accessed via a virtual information store, termed the 101 Management Information Base or MIB. Objects in the MIB are defined 102 using the mechanisms defined in the SMI. 104 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 105 conforming to the SMIv1 can be produced through the appropriate 106 translations. The resulting translated MIB must be semantically 107 equivalent, except where objects or events are omitted because no 108 translation is possible (e.g., use of Counter64). Some machine readable 109 information in SMIv2 will be converted into textual descriptions in 110 SMIv1 during the translation process. However, this loss of machine 111 readable information is not considered to change the semantics of the 112 MIB. 114 3. Role Combinations for Interfaces 116 Policy is being defined using the concept of "roles" [COREMODEL]. A 117 first application of roles is to assign one or more roles to each 118 interface on a network device. The combination of all roles assigned to 119 an interface is termed a "role combination". The Framework PIB 120 [FRAMEPIB] uses role combinations as the means to specify policy 121 information which applies to multiple interfaces. Each Policy 122 Client/Policy Enforce Point (PEP) notifies the Policy Server/Policy 123 Decision Point (PDP) of the role combinations for which it needs policy. 124 It is the PEP which locally resolves the relationship between role 125 combinations and its local interfaces. The relationship of role 126 combination to interface is a one-to-many association, i.e, many 127 interfaces can have the same role combination, but each interface has 128 one and only one role combination. 130 The Policy Interface Table defined in this MIB can be used to configure 131 each interface of a PEP with its role combination. The whole role 132 combination is modified rather than individual roles within the role 133 combination to avoid race conditions if and when multiple managers were 134 updating the values at the same time. The table can also be read to 135 determine which interfaces are configured with a particular role 136 combination. This allows information available on a per-interface basis 137 to be aggregated and compared to information available on a per-role 138 combination basis. Such comparisons can be useful for trouble-shooting 139 the effectivesness of policies, for aggregate statistics and/or for 140 accounting purposes. 142 Draft Policy Auxiliary MIB July 2000 144 4. Policy Device Auxiliary MIB Definitions 146 POLICY-DEVICE-AUX-MIB DEFINITIONS ::= BEGIN 148 IMPORTS 149 MODULE-IDENTITY, OBJECT-TYPE, experimental 150 FROM SNMPv2-SMI 151 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 152 TEXTUAL-CONVENTION, RowStatus, StorageType 153 FROM SNMPv2-TC 154 SnmpAdminString FROM SNMP-FRAMEWORK-MIB 155 InterfaceIndex FROM IF-MIB; 157 policyDeviceAuxMib MODULE-IDENTITY 158 LAST-UPDATED "200007121800Z" -- 12 July 2000 159 ORGANIZATION "IETF RAP WG" 160 CONTACT-INFO 161 "Kwok Ho Chan 162 Nortel Networks, Inc. 163 600 Technology Park Drive 164 Billerica, MA 01821 USA 165 Phone: +1 978 288 8175 166 Email: khchan@nortelnetworks.com 168 John Seligson 169 Nortel Networks, Inc. 170 4401 Great America Parkway 171 Santa Clara, CA USA 95054 172 Phone: +1 408 495-2992 173 Email: jseligso@nortelnetworks.com 175 Keith McCloghrie 176 Cisco Systems, Inc. 177 170 West Tasman Drive, 178 San Jose, CA 95134-1706 USA 179 Phone: +1 408 526 5260 180 Email: kzm@cisco.com" 181 DESCRIPTION 182 "This module defines an infrastructure used 183 for support of policy-based provisioning of 184 a network device." 185 ::= { experimental 999 } 187 Draft Policy Auxiliary MIB July 2000 189 policyDeviceAuxObjects OBJECT IDENTIFIER ::= { policyDeviceAuxMib 1 } 190 policyDeviceAuxConformance OBJECT IDENTIFIER ::= { policyDeviceAuxMib 2 } 192 policyDeviceConfig OBJECT IDENTIFIER ::= { policyDeviceAuxObjects 1 } 194 Role ::= TEXTUAL-CONVENTION 195 STATUS current 196 DESCRIPTION 197 "A role represents a functionality characteristic or 198 capability of a resource to which policies are applied. 199 Examples of roles include Backbone interface, Frame Relay 200 interface, BGP-capable router, web server, firewall, etc. 202 Valid characters are a-z, A-Z, 0-9, period, hyphen and 203 underscore. A role must not start with an underscore." 204 REFERENCE 205 "Policy Core Information Model, 206 draft-ietf-policy-core-info-model-06.txt" 207 SYNTAX SnmpAdminString (SIZE (1..31)) 209 RoleCombination ::= TEXTUAL-CONVENTION 210 STATUS current 211 DESCRIPTION 212 "A Display string consisting of a set of roles concatenated 213 with a '+' character where the roles are in lexicographic 214 order from minimum to maximum. 216 For example, a+b and b+a are NOT different role-combinations; 217 rather, they are different formating of the same (one) role- 218 combination. 220 Notice the roles within a role-combination are in lexicographic 221 order from minimum to maximum, hence, we declare: 222 a+b is the valid formating of the role-combination, 223 b+a is an invalid formating of the role-combination. 225 Notice the need of zero-length role-combination as the role- 226 combination of interfaces to which no roles have been assigned. 227 This role-combination is also known as the null role-combination. 228 (Note the deliberate use of lower case leters to avoid confusion 229 with the ASCII NULL character which has a value of zero but length 230 of one.)" 231 SYNTAX SnmpAdminString (SIZE (0..255)) 233 Draft Policy Auxiliary MIB July 2000 235 -- The Policy Interface Table supports 236 -- associating an interface with a specific role combination. 238 -- This table satisfy the need to monitor the configuration of 239 -- roles on a per interface basis, and is no less scalable as 240 -- other required per interface parameters. 241 -- This does not preclude roles being associated with some less 242 -- granular entities, and should be addressed when such need arise. 244 policyInterfaceTable OBJECT-TYPE 245 SYNTAX SEQUENCE OF PolicyInterfaceEntry 246 MAX-ACCESS not-accessible 247 STATUS current 248 DESCRIPTION 249 "Policy information about a device's interfaces." 250 ::= { policyDeviceConfig 1 } 252 policyInterfaceEntry OBJECT-TYPE 253 SYNTAX PolicyInterfaceEntry 254 MAX-ACCESS not-accessible 255 STATUS current 256 DESCRIPTION 257 "A conceptual row in the policyInterfaceTable. 258 Each row identifies policy infromation about a 259 particular interface." 260 INDEX { policyInterfaceIfIndex } 261 ::= { policyInterfaceTable 1 } 263 PolicyInterfaceEntry ::= SEQUENCE { 264 policyInterfaceIfIndex InterfaceIndex, 265 policyInterfaceRoleCombo RoleCombination, 266 policyInterfaceStorage StorageType, 267 policyInterfaceStatus RowStatus 268 } 270 policyInterfaceIfIndex OBJECT-TYPE 271 SYNTAX InterfaceIndex 272 MAX-ACCESS not-accessible 273 STATUS current 274 DESCRIPTION 275 "The ifIndex value for which this conceptual row provides 276 policy information." 278 Draft Policy Auxiliary MIB July 2000 280 ::= { policyInterfaceEntry 1 } 282 policyInterfaceRoleCombo OBJECT-TYPE 283 SYNTAX RoleCombination 284 MAX-ACCESS read-create 285 STATUS current 286 DESCRIPTION 287 "The role combination that is associated with this interface 288 for the purpose of assigning policies to this interface." 289 ::= { policyInterfaceEntry 2 } 291 policyInterfaceStorage OBJECT-TYPE 292 SYNTAX StorageType 293 MAX-ACCESS read-create 294 STATUS current 295 DESCRIPTION 296 "The storage type for this conceptual row. 298 Conceptual rows having the value permanent(4) need not 299 allow write-access to any columnar objects in the row. 301 This object may not be modified if the associated 302 policyInterfaceStatus object is equal to active(1)." 303 DEFVAL { volatile } 304 ::= { policyInterfaceEntry 3 } 306 policyInterfaceStatus OBJECT-TYPE 307 SYNTAX RowStatus 308 MAX-ACCESS read-create 309 STATUS current 310 DESCRIPTION 311 "The status of this row. 313 An entry may not exist in the active state unless all 314 objects in the entry have an appropriate value. Row 315 creation using only default values is supported." 316 ::= { policyInterfaceEntry 4 } 318 Draft Policy Auxiliary MIB July 2000 320 -- 321 -- Conformance Section 322 -- 324 policyDeviceCompliances 325 OBJECT IDENTIFIER ::= { policyDeviceAuxConformance 1 } 326 policyDeviceGroups OBJECT IDENTIFIER ::= { policyDeviceAuxConformance 2 } 328 policyDeviceCompliance MODULE-COMPLIANCE 329 STATUS current 330 DESCRIPTION 331 "Describes the requirements for conformance to the 332 Policy Auxiliary MIB." 334 MODULE -- this module 335 MANDATORY-GROUPS { policyInterfaceGroup } 337 OBJECT policyInterfaceRoleCombo 338 MIN-ACCESS read-only 339 DESCRIPTION "Write access is not required." 341 OBJECT policyInterfaceStorage 342 MIN-ACCESS read-only 343 DESCRIPTION "Write access is not required, nor is 344 support for the nonVolatile(2) enumeration." 346 OBJECT policyInterfaceStatus 347 MIN-ACCESS read-only 348 DESCRIPTION "Write access is not required." 349 ::= { policyDeviceCompliances 1 } 351 policyInterfaceGroup OBJECT-GROUP 352 OBJECTS { 353 policyInterfaceRoleCombo, 354 policyInterfaceStorage, 355 policyInterfaceStatus 356 } 357 STATUS current 359 Draft Policy Auxiliary MIB July 2000 361 DESCRIPTION 362 "Objects used to define interface to role combination 363 mappings." 364 ::= { policyDeviceGroups 1 } 366 END 367 Draft Policy Auxiliary MIB July 2000 369 5. References 371 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 372 RFC 2026, October 1996. 374 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 375 for Describing SNMP Management Frameworks", RFC 2571, April 376 1999. 378 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 379 of Management Information for TCP/IP-based Internets", STD 380 16, RFC 1155, May 1990. 382 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 383 16, RFC 1212, March 1991. 385 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 386 SNMP", RFC 1215, March 1991. 388 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 389 Rose, M., and S. Waldbusser, "Structure of Management 390 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 391 1999. 393 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 394 Rose, M., and S. Waldbusser, "Textual Conventions for 395 SMIv2", STD 58, RFC 2579, April 1999. 397 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 398 Rose, M., and S. Waldbusser, "Conformance Statements for 399 SMIv2", STD 58, RFC 2580, April 1999. 401 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 402 Network Management Protocol", STD 15, RFC 1157, May 1990. 404 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 405 "Introduction to Community-based SNMPv2", RFC 1901, January 406 1996. 408 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 409 "Transport Mappings for Version 2 of the Simple Network 410 Management Protocol (SNMPv2)", RFC 1906, January 1996. 412 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 413 Processing and Dispatching for the Simple Network Management 415 Draft Policy Auxiliary MIB July 2000 417 Protocol (SNMP)", RFC 2572, April 1999. 419 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 420 (USM) for version 3 of the Simple Network Management 421 Protocol (SNMPv3)", RFC 2574, April 1999. 423 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 424 "Protocol Operations for Version 2 of the Simple Network 425 Management Protocol (SNMPv2)", RFC 1905, January 1996. 427 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 428 RFC 2573, April 1999. 430 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 431 Access Control Model (VACM) for the Simple Network 432 Management Protocol (SNMP)", RFC 2575, April 1999. 434 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 435 "Introduction to Version 3 of the Internet-standard Network 436 Management Framework", RFC 2570, April 1999. 438 [COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, 439 R. Gai, S., McCloghrie, K. and A. Smith, "COPS Usage for 440 Policy Provisioning" Internet Draft, draft-ietf-rap-cops- 441 pr-03.txt, July 2000. 443 [FRAMEPIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S., 444 Smith, A., and F. Reichmeyer, "Framework Policy Information 445 Base", Internet Draft, draft-ietf-rap-frameworkpib-01.txt, 446 July 2000. 448 [COREMODEL] Moore, B., Ellesson, E., and J. Strassner, "Policy Framework 449 Core Information Model -- Version 1 Specification", Internet 450 Draft, draft-ietf-policy-core-info-model-06.txt, May 2000. 452 6. Authors' Addresses 454 Kwok Ho Chan 455 Nortel Networks, Inc. 456 600 Technology Park Drive 457 Billerica, MA 01821 USA 458 Phone: +1 978 288 8175 459 Email: khchan@nortelnetworks.com 461 John Seligson 462 Draft Policy Auxiliary MIB July 2000 464 Nortel Networks, Inc. 465 4401 Great America Parkway 466 Santa Clara, CA 95054 USA 467 Phone: +1 408 495 2992 468 Email: jseligso@nortelnetworks.com 470 Keith McCloghrie 471 Cisco Systems, Inc. 472 170 West Tasman Drive 473 San Jose, CA 95134-1706 USA 474 Phone: +1 408 526 5260 475 Email: kzm@cisco.com 477 Michael Fine 478 Cisco Systems, Inc. 479 170 West Tasman Drive 480 San Jose, CA 95134-1706 USA 481 Phone: +1 408 527 8218 482 Email: mfine@cisco.com 484 Scott Hahn 485 Intel 486 2111 NE 25th Avenue 487 Hillsboro, OR 97124 USA 488 Phone: +1 503 264 8231 489 Email: scott.hahn@intel.com 491 Andrew Smith 492 Fax: +1 415 345 1827 493 Email: ah_smith@pacbell.net 495 Francis Reichmeyer 496 IPHighway, Inc. 497 55 New York Avenue 498 Framingham, MA 01701 USA 499 Phone: +1 201 665 8714 500 Email: franr@iphighway.com 502 7. Security Considerations 504 There are a number of management objects defined in this MIB that have a 505 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 506 considered sensitive or vulnerable in some network environments. The 507 support for SET operations in a non-secure environment without proper 508 protection can have a negative effect on network operations. 510 Draft Policy Auxiliary MIB July 2000 512 In particular, write-able objects allow an administrator to control the 513 interfaces, and unauthorized access to these could cause a denial of 514 service, or in combination with other (e.g., physical) security 515 breaches, could cause unauthorized connectivity to a device. 517 SNMPv1 by itself is not a secure environment. Even if the network 518 itself is secure (for example by using IPSec), even then, there is no 519 control as to who on the secure network is allowed to access and GET/SET 520 (read/change/create/delete) the objects in this MIB. 522 It is recommended that the implementers consider the security features 523 as provided by the SNMPv3 framework. Specifically, the use of the User- 524 based Security Model RFC 2574 [RFC2574] and the View- based Access 525 Control Model RFC 2575 [RFC2575] is recommended. 527 It is then a customer/user responsibility to ensure that the SNMP entity 528 giving access to an instance of this MIB, is properly configured to give 529 access to the objects only to those principals (users) that have 530 legitimate rights to indeed GET or SET (change/create/delete) them. 532 8. Notice on Intellectual Property 534 The IETF takes no position regarding the validity or scope of any 535 intellectual property or other rights that might be claimed to pertain 536 to the implementation or use of the technology described in this 537 document or the extent to which any license under such rights might or 538 might not be available; neither does it represent that it has made any 539 effort to identify any such rights. Information on the IETF's 540 procedures with respect to rights in standards-track and standards 541 related documentation can be found in BCP-11. Copies of claims of 542 rights made available for publication and any assurances of licenses to 543 be made available, or the result of an attempt made to obtain a general 544 license or permission for the use of such proprietary rights by 545 implementors or users of this specification can be obtained from the 546 IETF Secretariat. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary rights 550 which may cover technology that may be required to practice this 551 standard. Please address the information to the IETF Executive Director. 553 Draft Policy Auxiliary MIB July 2000 555 9. Full Copyright Statement 557 Copyright (C) The Internet Society (2000). All Rights Reserved. 559 This document and translations of it may be copied and furnished to 560 others, and derivative works that comment on or otherwise explain it or 561 assist in its implementation may be prepared, copied, published and 562 distributed, in whole or in part, without restriction of any kind, 563 provided that the above copyright notice and this paragraph are included 564 on all such copies and derivative works. However, this document itself 565 may not be modified in any way, such as by removing the copyright notice 566 or references to the Internet Society or other Internet organizations, 567 except as needed for the purpose of developing Internet standards in 568 which case the procedures for copyrights defined in the Internet 569 Standards process must be followed, or as required to translate it into 570 languages other than English. 572 The limited permissions granted above are perpetual and will not be 573 revoked by the Internet Society or its successors or assigns. 575 This document and the information contained herein is provided on an "AS 576 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 577 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 578 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 579 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 580 FITNESS FOR A PARTICULAR PURPOSE."