idnits 2.17.1 draft-ops-endpoint-mib-05.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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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. ** There are 2 instances of too long lines in the document, the longest one being 1 character 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 293 has weird spacing: '... octets cont...' == Line 305 has weird spacing: '... octets cont...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 21, 2000) is 8861 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: '20' is defined on line 630, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2012 (ref. '18') (Obsoleted by RFC 4022) ** Obsolete normative reference: RFC 2452 (ref. '19') (Obsoleted by RFC 4022, RFC 8096) ** Obsolete normative reference: RFC 2233 (ref. '20') (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 2373 (ref. '21') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2553 (ref. '22') (Obsoleted by RFC 3493) Summary: 22 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Daniele 2 Internet-Draft Compaq Computer Corporation 3 Expires: July 21, 2000 B. Haberman 4 Nortel Networks 5 S. Routhier 6 Integrated Systems, Inc. 7 J. Schoenwaelder 8 TU Braunschweig 9 January 21, 2000 11 Textual Conventions for Internet Network Addresses 12 draft-ops-endpoint-mib-05.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To view the entire list of Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/iid-abstracts.txt 35 This Internet-Draft will expire on July 21, 2000. 37 Copyright Notice 39 Copyright (C) The Internet Society (2000). All Rights Reserved. 41 Abstract 43 This MIB module defines textual conventions to represent commonly 44 used Internet network layer addressing information. The intent is 45 that these definitions will be imported and used in MIBs that would 46 otherwise define their own representations. 48 This work is output from the Operations and Management Area 49 "IPv6MIB" design team. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The SNMP Management Framework . . . . . . . . . . . . . . . . 5 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 10 58 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 11 59 4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . . 11 60 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 11 61 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 12 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 7. Intellectual Property Notice . . . . . . . . . . . . . . . . . 15 64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 68 1. Introduction 70 Several standard-track MIB modules use the IpAddress SMIv2 base 71 type. This limits the applicability of these MIB modules to IP 72 Version 4 (IPv4) since the IpAddress SMIv2 base type can only 73 contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has 74 become problematic with the introduction of IP Version 6 (IPv6) 75 addresses [21]. 77 This document defines multiple textual conventions as a mechanism to 78 express generic Internet network layer addresses within MIB module 79 specifications. The solution is compatible with SMIv2 (STD 58) and 80 SMIv1 (STD 16). New MIB definitions which need to express network 81 layer Internet addresses SHOULD use the textual conventions defined 82 in this memo. New MIBs SHOULD NOT use the SMIv2 IpAddress base type 83 anymore. 85 A generic Internet address consists of two objects, one whose syntax 86 is InetAddressType, and another whose syntax is InetAddress. The 87 value of the first object determines how the value of the second 88 object is encoded. The InetAddress textual convention represents an 89 opaque Internet address value. The InetAddressType enumeration is 90 used to "cast" the InetAddress value into a concrete textual 91 convention for the address type. This usage of multiple textual 92 conventions allows expression of the display characteristics of each 93 address type and makes the set of defined Internet address types 94 extensible. 96 The textual conventions defined in this document can be used to 97 define Internet addresses by using DNS domain names in addition to 98 IPv4 and IPv6 addresses. A MIB designer can write compliance 99 statements to express that only a subset of the possible address 100 types must be supported by a compliant implementation. 102 MIB developers who need to represent Internet addresses SHOULD use 103 these definitions whenever applicable, as opposed to defining their 104 own constructs. Even MIBs that only need to represent IPv4 or IPv6 105 addresses SHOULD use the textual conventions defined in this memo. 107 In order to make existing widely-deployed IPv4-only MIBs fit for 108 IPv6, it might be a valid approach to define separate tables for 109 different address types. This is a decision for the MIB designer. 110 For example, the tcpConnTable of the TCP-MIB [18] was left intact 111 and a new table was added for TCP connections over IPv6 in the 112 IPV6-TCP-MIB [19]. Note that even in this case, the MIBs SHOULD use 113 the textual conventions defined in this memo. 115 Note that MIB developers SHOULD NOT use the textual conventions 116 defined in this document to represent transport layer addresses. 118 Instead the SMIv2 TAddress textual convention and associated 119 definitions should be used for transport layer addresses. 121 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 122 in this document are to be interpreted as described in RFC 2119 [1]. 124 2. The SNMP Management Framework 126 The SNMP Management Framework presently consists of five major 127 components: 129 o An overall architecture, described in RFC 2571 [2]. 131 o Mechanisms for describing and naming objects and events for the 132 purpose of management. The first version of this Structure of 133 Management Information (SMI) is called SMIv1 and described in STD 134 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 135 second version, called SMIv2, is described in STD 58, RFC 2578 136 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 138 o Message protocols for transferring management information. The 139 first version of the SNMP message protocol is called SNMPv1 and 140 described in STD 15, RFC 1157 [9]. A second version of the SNMP 141 message protocol, which is not an Internet standards track 142 protocol, is called SNMPv2c and described in RFC 1901 [10] and 143 RFC 1906 [11]. The third version of the message protocol is 144 called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and 145 RFC 2574 [13]. 147 o Protocol operations for accessing management information. The 148 first set of protocol operations and associated PDU formats is 149 described in STD 15, RFC 1157 [9]. A second set of protocol 150 operations and associated PDU formats is described in RFC 1905 151 [14]. 153 o A set of fundamental applications described in RFC 2573 [15] and 154 the view-based access control mechanism described in RFC 2575 155 [16]. 157 A more detailed introduction to the current SNMP Management 158 Framework can be found in RFC 2570 [17]. 160 Managed objects are accessed via a virtual information store, termed 161 the Management Information Base or MIB. Objects in the MIB are 162 defined using the mechanisms defined in the SMI. 164 This memo specifies a MIB module that is compliant to the SMIv2. A 165 MIB conforming to the SMIv1 can be produced through the appropriate 166 translations. The resulting translated MIB must be semantically 167 equivalent, except where objects or events are omitted because no 168 translation is possible (use of Counter64). Some machine readable 169 information in SMIv2 will be converted into textual descriptions in 170 SMIv1 during the translation process. However, this loss of machine 171 readable information is not considered to change the semantics of 172 the MIB. 174 3. Definitions 176 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 178 IMPORTS 179 MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI 180 TEXTUAL-CONVENTION FROM SNMPv2-TC; 182 inetAddressMIB MODULE-IDENTITY 183 LAST-UPDATED "200001210000Z" 184 ORGANIZATION 185 "IETF Operations and Management Area" 186 CONTACT-INFO 187 "Mike Daniele 188 Compaq Computer Corporation 189 110 Spit Brook Rd 190 Nashua, NH 03062, USA 192 Phone: +1 603 884-1423 193 EMail: daniele@zk3.dec.com 195 Brian Haberman 196 Nortel Networks 197 4039 Emperor Blvd., Suite 200 198 Durham, NC 27703, USA 200 Phone: +1 919 992-4439 201 EMail: haberman@nortelnetworks.com 203 Shawn A. Routhier 204 Integrated Systems, Inc. 205 1 Tara Blvd, Suite 403 206 Nashua, NH 03062, USA 208 Phone: +1 603 897-2000 209 EMail: sar@epilogue.com 211 Juergen Schoenwaelder 212 TU Braunschweig 213 Bueltenweg 74/75 214 38106 Braunschweig, Germany 216 Phone: +49 531 391-3266 217 EMail: schoenw@ibr.cs.tu-bs.de 219 Send comments to mibs@ops.ietf.org." 221 DESCRIPTION 222 "This MIB module defines textual conventions for 223 representing Internet addresses. An Internet 224 address can be an IPv4 address, an IPv6 address 225 or a DNS domain name." 227 REVISION "200001210000Z" 228 DESCRIPTION 229 "Initial version, published as RFC XXXX." 230 ::= { mib-2 XXXX } -- to be assigned by IANA 232 InetAddressType ::= TEXTUAL-CONVENTION 233 STATUS current 234 DESCRIPTION 235 "A value that represents a type of Internet address. 237 unknown(0) An unknown address type. This value MUST 238 be used if the value of the corresponding 239 InetAddress object is a zero-length string. 240 It may also be used to indicate an IP address 241 which is not in one of the formats defined 242 below. 244 ipv4(1) An IPv4 address as defined by the 245 InetAddressIPv4 textual convention. 247 ipv6(2) An IPv6 address as defined by the 248 InetAddressIPv6 textual convention. 250 dns(16) A DNS domain name as defined by the 251 InetAddressDNS textual convention. 253 Each definition of a concrete InetAddressType value must be 254 accompanied by a definition of a textual convention for use 255 with that InetAddressType. 257 The InetAddressType textual convention SHOULD NOT be subtyped 258 in object type definitions to support future extensions. It 259 MAY be subtyped in compliance statements in order to require 260 only a subset of these address types for a compliant 261 implementation." 262 SYNTAX INTEGER { 263 unknown(0), 264 ipv4(1), 265 ipv6(2), 266 dns(16) -- align with AddressFamilyNumbers in 267 } -- IANA-ADDRESS-FAMILY-NUMBERS-MIB 269 InetAddress ::= TEXTUAL-CONVENTION 270 STATUS current 271 DESCRIPTION 272 "Denotes a generic Internet address. 274 An InetAddress value is always interpreted within the context 275 of an InetAddressType value. When this Textual Convention is 276 used, then the DESCRIPTION clause MUST specify which 277 associated object specifies the context for the InetAddress 278 value. 280 When this Textual Convention is used as the syntax of an 281 index object, there may be issues with the limit of 128 282 sub-identifiers specified in SMIv2, STD 58. In this case, 283 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 284 to limit the number of potential instance sub-identifiers." 285 SYNTAX OCTET STRING (SIZE (0..255)) 287 InetAddressIPv4 ::= TEXTUAL-CONVENTION 288 DISPLAY-HINT "1d.1d.1d.1d" 289 STATUS current 290 DESCRIPTION 291 "Represents an IPv4 network address: 293 octets contents encoding 294 1-4 IP address network-byte order 296 The corresponding InetAddressType value is ipv4(1)." 297 SYNTAX OCTET STRING (SIZE (4)) 299 InetAddressIPv6 ::= TEXTUAL-CONVENTION 300 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x@4d" 301 STATUS current 302 DESCRIPTION 303 "Represents an IPv6 network address: 305 octets contents encoding 306 1-16 IPv6 address network-byte order 307 17-20 scope identifier network-byte order 309 The corresponding InetAddressType value is ipv6(2). 311 The scope identifier (bytes 17-20) MUST NOT be present 312 for global IPv6 addresses. For non-global IPv6 addresses 313 (e.g. link-local or site-local addresses), the scope 314 identifier MUST always be present. 316 The scope identifier contains an interface index value 317 (ifIndex) for the interface on which the address is 318 configured for link-local IPv6 addresses. The ifIndex 319 value MUST conform to the InterfaceIndex textual 320 convention defined in the IF-MIB (RFC 2233). 322 The scope identifier contains a site identifier for 323 site-local IPv6 addresses." 324 SYNTAX OCTET STRING (SIZE (16|20)) 326 InetAddressDNS ::= TEXTUAL-CONVENTION 327 DISPLAY-HINT "255a" 328 STATUS current 329 DESCRIPTION 330 "Represents a DNS domain name. The name SHOULD be 331 fully qualified whenever possible. 333 The corresponding InetAddressType is dns(16). 335 The DESCRIPTION clause of InetAddress objects that 336 may have InetAddressDNS values must fully describe 337 how (and when) such names are to be resolved to IP 338 addresses." 339 SYNTAX OCTET STRING (SIZE (1..255)) 341 END 343 4. Usage Hints 345 One particular usage of InetAddressType/InetAddress pairs is to 346 avoid over-constraining an object definition by the use of the 347 IpAddress SMI base type. An InetAddressType/InetAddress pair allows 348 to represent IP addresses in various formats. 350 The InetAddressType and InetAddress objects SHOULD NOT be subtyped. 351 Subtyping binds the MIB module to specific address formats, which 352 may cause serious problems if new address formats need to be 353 introduced. Note that it is possible to write compliance statements 354 in order to express that only a subset of the defined address types 355 must be implemented to be compliant. 357 Internet addresses MUST always be represented by a pair of 358 InetAddressType/InetAddress objects. It is not allowed to "share" an 359 InetAddressType between multiple InetAddress objects. Furthermore, 360 the InetAddressType object must be registered immediately before the 361 InetAddress object. In other words, the OIDs for the InetAddressType 362 object and the InetAddress object MUST have the same length and the 363 last sub-identifier of the InetAddressType object MUST be 1 less 364 than the last sub-identifier of the InetAddress object. 366 4.1 Table Indexing 368 When a generic Internet address is used as an index, both the 369 InetAddressType and InetAddress objects MUST be used. The 370 InetAddressType object MUST come immediately before the InetAddress 371 object in the INDEX clause. If multiple Internet addresses are used 372 in the INDEX clause, then every Internet address must be represented 373 by a pair of InetAddressType and InetAddress objects. 375 The IMPLIED keyword MUST NOT be used for an object of type 376 InetAddress in an the INDEX clause. Instance sub-identifiers are 377 then of the form T.N.O1.O2...On, where T is the value of the 378 InetAddressType object, O1...On are the octets in the InetAddress 379 object, and N is the number of those octets. 381 There is a meaningful lexicographical ordering to tables indexed in 382 this fashion. Command generator applications may 384 o lookup specific addresses of known type and value; 386 o issue GetNext requests for addresses of a single type; 388 o issue GetNext requests for specific type and address prefix. 390 4.2 Uniqueness of Addresses 392 IPv4 addresses were intended to be globally unique, current usage 393 notwithstanding. IPv6 addresses were architected to have different 394 scopes and hence uniqueness [21]. In particular, IPv6 "link-local" 395 and "site-local" addresses are not guaranteed to be unique on any 396 particular node. In such cases, the duplicate addresses must be 397 configured on different interfaces, so the combination of an IPv6 398 address and an interface number is unique. 400 The InetAddressIPv6 textual convention has been defined to represent 401 global and non-global IPv6 addresses. MIB designers who use 402 InetAddressType/InetAddress pairs therefore do not need to worry 403 about link-local or site-local addresses. 405 The size of the scope identifier has been choosen so that it matches 406 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 407 2553 [22]. 409 4.3 Multiple InetAddresses per Host 411 A single host system may be configured with multiple addresses (IPv4 412 or IPv6), and possibly with multiple DNS names. Thus it is possible 413 for a single host system to be represented by multiple (unique) 414 InetAddressType/InetAddress pairs. 416 If this could be an implementation or usage issue, then the 417 DESCRIPTION clause of the relevant objects MUST fully describe 418 required behavior. 420 4.4 Resolving DNS Names 422 DNS names must be resolved to IP addresses when communication with a 423 host is required. This raises a temporal aspect to defining MIB 424 objects whose value is a DNS name: When is the name translated to an 425 address? 427 For example, consider an object defined to indicate a forwarding 428 destination, and whose value is a DNS name. When does the forwarding 429 entity resolve the DNS name? Each time forwarding occurs? Once, when 430 the object was instantiated? 432 The DESCRIPTION clause of such objects SHOULD precisely define how 433 and when any required name to address resolution is done. 435 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 436 define how and when a reverse lookup is being done if an object is 437 not created administratively. 439 5. Table Indexing Example 441 This example shows a table listing communication peers that are 442 identified by either an IPv4 address, an IPv6 address or a DNS name. 443 The table definition also prohibits entries with an empty address 444 (whose type would be "unknown"). The size of a DNS name is limited 445 to 64 characters. 447 peerTable OBJECT-TYPE 448 SYNTAX SEQUENCE OF PeerEntry 449 MAX-ACCESS not-accessible 450 STATUS current 451 DESCRIPTION 452 "A list of communication peers." 453 ::= { somewhere 1 } 455 peerEntry OBJECT-TYPE 456 SYNTAX PeerEntry 457 MAX-ACCESS not-accessible 458 STATUS current 459 DESCRIPTION 460 "An entry containing information about a particular peer." 461 INDEX { peerAddressType, peerAddress } 462 ::= { peerTable 1 } 464 PeerEntry ::= SEQUENCE { 465 peerAddressType InetAddressType, 466 peerAddress InetAddress, 467 peerStatus INTEGER 468 } 470 peerAddressType OBJECT-TYPE 471 SYNTAX InetAddressType 472 MAX-ACCESS not-accessible 473 STATUS current 474 DESCRIPTION 475 "The type of Internet address by which the peer 476 is reachable." 477 ::= { peerEntry 1 } 479 peerAddress OBJECT-TYPE 480 SYNTAX InetAddress (SIZE (1..64)) 481 MAX-ACCESS not-accessible 482 STATUS current 483 DESCRIPTION 484 "The Internet address for the peer. Note that 485 implementations must limit themselves to a single 486 entry in this table per reachable peer. 488 The peerAddress may not be empty due to the SIZE 489 restriction. 491 If a row is created administratively by an SNMP 492 operation and the address type value is dns(4), 493 then a name lookup must be performed whenever 494 this entry is being used to contact the peer. 496 If a row is created by the managed entity and the 497 address type value is dns(4), then a reverse lookup 498 need be performed only when the row is instantiated." 499 ::= { peerEntry 2 } 501 The following compliance statement specifies that implementations 502 need only support IPv4 addresses and globally unique IPv6 addresses 503 to be compliant. Support for DNS names or scoped IPv6 addresses is 504 not required. 506 peerCompliance MODULE-COMPLIANCE 507 STATUS current 508 DESCRIPTION 509 "The compliance statement the peer MIB." 511 MODULE -- this module 512 MANDATORY-GROUPS { peerGroup } 514 OBJECT peerAddressType 515 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 516 DESCRIPTION 517 "An implementation is only required to support IPv4 518 and IPv6 addresses." 520 OBJECT peerAddress 521 SYNTAX InetAddress (SIZE(4|16)) 522 DESCRIPTION 523 "An implementation is only required to support IPv4 524 and globally unique IPv6 addresses." 526 ::= { somewhere 2 } 528 6. Security Considerations 530 This module does not define any management objects. Instead, it 531 defines a set of textual conventions which may be used by other MIB 532 modules to define management objects. 534 Meaningful security considerations can only be written in the 535 modules that define management objects. 537 7. Intellectual Property Notice 539 The IETF takes no position regarding the validity or scope of any 540 intellectual property or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; neither does it represent that it 544 has made any effort to identify any such rights. Information on the 545 IETF's procedures with respect to rights in standards-track and 546 standards-related documentation can be found in BCP-11. Copies of 547 claims of rights made available for publication and any assurances 548 of licenses to be made available, or the result of an attempt made 549 to obtain a general license or permission for the use of such 550 propritary rights by implementors or users of this specification can 551 be obtained from the IETF Secretariat. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights which may cover technology that may be required to practice 556 this standard. Please address the information to the IETF Executive 557 Director. 559 References 561 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 562 Levels", BCP 14, RFC 2119, March 1997. 564 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 565 Describing SNMP Management Frameworks", RFC 2571, April 1999. 567 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 568 Management Information for TCP/IP-based Internets", STD 16, RFC 569 1155, May 1990. 571 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 572 RFC 1212, March 1991. 574 [5] Rose, M., "A Convention for Defining Traps for use with the 575 SNMP", RFC 1215, March 1991. 577 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 578 M. and S. Waldbusser, "Structure of Management Information 579 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 581 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 582 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 583 RFC 2579, April 1999. 585 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 586 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 587 58, RFC 2580, April 1999. 589 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 590 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 592 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 593 "Introduction to Community-based SNMPv2", RFC 1901, January 594 1996. 596 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 597 "Transport Mappings for Version 2 of the Simple Network 598 Management Protocol (SNMPv2)", RFC 1906, January 1996. 600 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 601 Processing and Dispatching for the Simple Network Management 602 Protocol (SNMP)", RFC 2572, April 1999. 604 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 605 for version 3 of the Simple Network Management Protocol 606 (SNMPv3)", RFC 2574, April 1999. 608 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 609 "Protocol Operations for Version 2 of the Simple Network 610 Management Protocol (SNMPv2)", RFC 1905, January 1996. 612 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 613 2573, April 1999. 615 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 616 Control Model (VACM) for the Simple Network Management 617 Protocol (SNMP)", RFC 2575, April 1999. 619 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 620 to Version 3 of the Internet-standard Network Management 621 Framework", RFC 2570, April 1999. 623 [18] McCloghrie, K., "SNMPv2 Management Information Base for the 624 Transmission Control Protocol using SMIv2", RFC 2012, November 625 1996. 627 [19] Daniele, M., "IP Version 6 Management Information Base for the 628 Transmission Control Protocol", RFC 2452, December 1998. 630 [20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB 631 using SMIv2", RFC 2233, November 1997. 633 [21] Hinden, R. and S. Deering, "IP Version 6 Addressing 634 Architecture", RFC 2373, July 1998. 636 [22] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 637 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 639 Authors' Addresses 641 Mike Daniele 642 Compaq Computer Corporation 643 110 Spit Brook Rd 644 Nashua, NH 03062 645 USA 647 Phone: +1 603 884-1423 648 EMail: daniele@zk3.dec.com 649 Brian Haberman 650 Nortel Networks 651 4039 Emperor Blvd., Suite 200 652 Durham, NC 27703 653 USA 655 Phone: +1 919 992-4439 656 EMail: haberman@nortelnetworks.com 658 Shawn A. Routhier 659 Integrated Systems, Inc. 660 1 Tara Blvd, Suite 403 661 Nashua, NH 03062 662 USA 664 Phone: +1 603 897-2000 665 EMail: sar@epilogue.com 667 Juergen Schoenwaelder 668 TU Braunschweig 669 Bueltenweg 74/75 670 38106 Braunschweig 671 Germany 673 Phone: +49 531 391-3266 674 EMail: schoenw@ibr.cs.tu-bs.de 676 Full Copyright Statement 678 Copyright (C) The Internet Society (2000). All Rights Reserved. 680 This document and translations of it may be copied and furnished to 681 others, and derivative works that comment on or otherwise explain it 682 or assist in its implmentation may be prepared, copied, published 683 and distributed, in whole or in part, without restriction of any 684 kind, provided that the above copyright notice and this paragraph 685 are included on all such copies and derivative works. However, this 686 document itself may not be modified in any way, such as by removing 687 the copyright notice or references to the Internet Society or other 688 Internet organizations, except as needed for the purpose of 689 developing Internet standards in which case the procedures for 690 copyrights defined in the Internet Standards process must be 691 followed, or as required to translate it into languages other than 692 English. 694 The limited permissions granted above are perpetual and will not be 695 revoked by the Internet Society or its successors or assigns. 697 This document and the information contained herein is provided on an 698 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 699 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 700 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 701 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 702 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Acknowledgement 706 Funding for the RFC editor function is currently provided by the 707 Internet Society.