idnits 2.17.1 draft-ops-endpoint-mib-07.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 is 1 instance 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 297 has weird spacing: '... octets cont...' == Line 309 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 (February 17, 2000) is 8835 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 654, 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: August 17, 2000 B. Haberman 4 Nortel Networks 5 S. Routhier 6 Integrated Systems, Inc. 7 J. Schoenwaelder 8 TU Braunschweig 9 February 17, 2000 11 Textual Conventions for Internet Network Addresses 12 draft-ops-endpoint-mib-07.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 August 17, 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 . . . . . . . . . . . . . . . . . . . 15 63 7. Intellectual Property Notice . . . . . . . . . . . . . . . . . 16 64 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 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 "200002170000Z" 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 "200002170000Z" 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 275 context of an InetAddressType value. The InetAddressType 276 object which defines the context must be registered 277 immediately before the object which uses the InetAddress 278 textual convention. In other words, the object identifiers 279 for the InetAddressType object and the InetAddress object 280 MUST have the same length and the last sub-identifier of 281 the InetAddressType object MUST be 1 less than the last 282 sub-identifier of the InetAddress object. 284 When this textual convention is used as the syntax of an 285 index object, there may be issues with the limit of 128 286 sub-identifiers specified in SMIv2, STD 58. In this case, 287 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 288 to limit the number of potential instance sub-identifiers." 289 SYNTAX OCTET STRING (SIZE (0..255)) 291 InetAddressIPv4 ::= TEXTUAL-CONVENTION 292 DISPLAY-HINT "1d.1d.1d.1d" 293 STATUS current 294 DESCRIPTION 295 "Represents an IPv4 network address: 297 octets contents encoding 298 1-4 IP address network-byte order 300 The corresponding InetAddressType value is ipv4(1)." 301 SYNTAX OCTET STRING (SIZE (4)) 303 InetAddressIPv6 ::= TEXTUAL-CONVENTION 304 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 305 STATUS current 306 DESCRIPTION 307 "Represents an IPv6 network address: 309 octets contents encoding 310 1-16 IPv6 address network-byte order 311 17-20 scope identifier network-byte order 313 The corresponding InetAddressType value is ipv6(2). 315 The scope identifier (bytes 17-20) MUST NOT be present 316 for global IPv6 addresses. For non-global IPv6 addresses 317 (e.g. link-local or site-local addresses), the scope 318 identifier MUST always be present. It contains a link 319 identifier for link-local and a site identifier for 320 site-local IPv6 addresses. 322 The scope identifier MUST disambiguate identical address 323 values. For link-local addresses, the scope identifier will 324 typically be the interface index (ifIndex as defined in the 325 IF-MIB, RFC 2233) of the interface on which the address is 326 configured. 328 The scope identifier may contain the special value 0 329 which refers to the default scope. The default scope 330 may be used in cases where e.g. a management application 331 needs to write a site-local InetAddressIPv6 address 332 without knowing the site identifier value. The default 333 scope SHOULD NOT be used as an easy way out in cases 334 where the scope identifier for a non-global IPv6 is 335 known." 336 SYNTAX OCTET STRING (SIZE (16|20)) 338 InetAddressDNS ::= TEXTUAL-CONVENTION 339 DISPLAY-HINT "255a" 340 STATUS current 341 DESCRIPTION 342 "Represents a DNS domain name. The name SHOULD be 343 fully qualified whenever possible. 345 The corresponding InetAddressType is dns(16). 347 The DESCRIPTION clause of InetAddress objects that 348 may have InetAddressDNS values must fully describe 349 how (and when) such names are to be resolved to IP 350 addresses." 351 SYNTAX OCTET STRING (SIZE (1..255)) 353 END 355 4. Usage Hints 357 One particular usage of InetAddressType/InetAddress pairs is to 358 avoid over-constraining an object definition by the use of the 359 IpAddress SMI base type. An InetAddressType/InetAddress pair allows 360 to represent IP addresses in various formats. 362 The InetAddressType and InetAddress objects SHOULD NOT be subtyped. 363 Subtyping binds the MIB module to specific address formats, which 364 may cause serious problems if new address formats need to be 365 introduced. Note that it is possible to write compliance statements 366 in order to express that only a subset of the defined address types 367 must be implemented to be compliant. 369 Internet addresses MUST always be represented by a pair of 370 InetAddressType/InetAddress objects. It is not allowed to "share" an 371 InetAddressType between multiple InetAddress objects. Furthermore, 372 the InetAddressType object must be registered immediately before the 373 InetAddress object. In other words, the object identifiers for the 374 InetAddressType object and the InetAddress object MUST have the same 375 length and the last sub-identifier of the InetAddressType object 376 MUST be 1 less than the last sub-identifier of the InetAddress 377 object. 379 4.1 Table Indexing 381 When a generic Internet address is used as an index, both the 382 InetAddressType and InetAddress objects MUST be used. The 383 InetAddressType object MUST come immediately before the InetAddress 384 object in the INDEX clause. If multiple Internet addresses are used 385 in the INDEX clause, then every Internet address must be represented 386 by a pair of InetAddressType and InetAddress objects. 388 The IMPLIED keyword MUST NOT be used for an object of type 389 InetAddress in an the INDEX clause. Instance sub-identifiers are 390 then of the form T.N.O1.O2...On, where T is the value of the 391 InetAddressType object, O1...On are the octets in the InetAddress 392 object, and N is the number of those octets. 394 There is a meaningful lexicographical ordering to tables indexed in 395 this fashion. Command generator applications may 397 o lookup specific addresses of known type and value; 399 o issue GetNext requests for addresses of a single type; 401 o issue GetNext requests for specific type and address prefix. 403 4.2 Uniqueness of Addresses 405 IPv4 addresses were intended to be globally unique, current usage 406 notwithstanding. IPv6 addresses were architected to have different 407 scopes and hence uniqueness [21]. In particular, IPv6 "link-local" 408 and "site-local" addresses are not guaranteed to be unique on any 409 particular node. In such cases, the duplicate addresses must be 410 configured on different interfaces. So the combination of an IPv6 411 address and an interface number is unique. The interface number may 412 therefore be used as a scope identifier. 414 The InetAddressIPv6 textual convention has been defined to represent 415 global and non-global IPv6 addresses. MIB designers who use 416 InetAddressType/InetAddress pairs therefore do not need to worry 417 about link-local or site-local addresses. 419 The size of the scope identifier has been choosen so that it matches 420 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 421 2553 [22]. 423 4.3 Multiple InetAddresses per Host 425 A single host system may be configured with multiple addresses (IPv4 426 or IPv6), and possibly with multiple DNS names. Thus it is possible 427 for a single host system to be represented by multiple (unique) 428 InetAddressType/InetAddress pairs. 430 If this could be an implementation or usage issue, then the 431 DESCRIPTION clause of the relevant objects MUST fully describe 432 required behavior. 434 4.4 Resolving DNS Names 436 DNS names must be resolved to IP addresses when communication with a 437 host is required. This raises a temporal aspect to defining MIB 438 objects whose value is a DNS name: When is the name translated to an 439 address? 441 For example, consider an object defined to indicate a forwarding 442 destination, and whose value is a DNS name. When does the forwarding 443 entity resolve the DNS name? Each time forwarding occurs? Once, when 444 the object was instantiated? 446 The DESCRIPTION clause of such objects SHOULD precisely define how 447 and when any required name to address resolution is done. 449 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 450 define how and when a reverse lookup is being done if an object is 451 not created administratively. 453 5. Table Indexing Example 455 This example shows a table listing communication peers that are 456 identified by either an IPv4 address, an IPv6 address or a DNS name. 457 The table definition also prohibits entries with an empty address 458 (whose type would be "unknown"). The size of a DNS name is limited 459 to 64 characters. 461 peerTable OBJECT-TYPE 462 SYNTAX SEQUENCE OF PeerEntry 463 MAX-ACCESS not-accessible 464 STATUS current 465 DESCRIPTION 466 "A list of communication peers." 467 ::= { somewhere 1 } 469 peerEntry OBJECT-TYPE 470 SYNTAX PeerEntry 471 MAX-ACCESS not-accessible 472 STATUS current 473 DESCRIPTION 474 "An entry containing information about a particular peer." 475 INDEX { peerAddressType, peerAddress } 476 ::= { peerTable 1 } 478 PeerEntry ::= SEQUENCE { 479 peerAddressType InetAddressType, 480 peerAddress InetAddress, 481 peerStatus INTEGER 482 } 484 peerAddressType OBJECT-TYPE 485 SYNTAX InetAddressType 486 MAX-ACCESS not-accessible 487 STATUS current 488 DESCRIPTION 489 "The type of Internet address by which the peer 490 is reachable." 491 ::= { peerEntry 1 } 493 peerAddress OBJECT-TYPE 494 SYNTAX InetAddress (SIZE (1..64)) 495 MAX-ACCESS not-accessible 496 STATUS current 497 DESCRIPTION 498 "The Internet address for the peer. Note that 499 implementations must limit themselves to a single 500 entry in this table per reachable peer. 502 The peerAddress may not be empty due to the SIZE 503 restriction. 505 If a row is created administratively by an SNMP 506 operation and the address type value is dns(16), then 507 the agent stores the DNS name internally. A DNS name 508 lookup must be performed on the internally stored DNS 509 name whenever it is being used to contact the peer. 511 If a row is created by the managed entity itself and 512 the address type value is dns(16), then the agent 513 stores the IP address internally. A DNS reverse lookup 514 must be performed on the internally stored IP address 515 whenever the value is retrieved via SNMP." 516 ::= { peerEntry 2 } 518 The following compliance statement specifies that implementations 519 need only support IPv4 addresses and globally unique IPv6 addresses 520 to be compliant. Support for DNS names or scoped IPv6 addresses is 521 not required. 523 peerCompliance MODULE-COMPLIANCE 524 STATUS current 525 DESCRIPTION 526 "The compliance statement the peer MIB." 528 MODULE -- this module 529 MANDATORY-GROUPS { peerGroup } 531 OBJECT peerAddressType 532 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 533 DESCRIPTION 534 "An implementation is only required to support IPv4 535 and IPv6 addresses." 537 OBJECT peerAddress 538 SYNTAX InetAddress (SIZE(4|16)) 539 DESCRIPTION 540 "An implementation is only required to support IPv4 541 and globally unique IPv6 addresses." 543 ::= { somewhere 2 } 545 Note that the SMIv2 does not allow to list not-accessible objects in 546 an object group (see section 3.1 in STD 58, RFC 2580 [8]). It is 547 therefore not possible to formally refine the syntax of auxiliary 548 objects which are not-accessible. In such a case, it is suggested to 549 express the refinement informally in the DESCRIPTION clause of the 550 MODULE-COMPLIANCE macro invocation. 552 6. Security Considerations 554 This module does not define any management objects. Instead, it 555 defines a set of textual conventions which may be used by other MIB 556 modules to define management objects. 558 Meaningful security considerations can only be written in the 559 modules that define management objects. 561 7. Intellectual Property Notice 563 The IETF takes no position regarding the validity or scope of any 564 intellectual property or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; neither does it represent that it 568 has made any effort to identify any such rights. Information on the 569 IETF's procedures with respect to rights in standards-track and 570 standards-related documentation can be found in BCP-11. Copies of 571 claims of rights made available for publication and any assurances 572 of licenses to be made available, or the result of an attempt made 573 to obtain a general license or permission for the use of such 574 propritary rights by implementors or users of this specification can 575 be obtained from the IETF Secretariat. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights which may cover technology that may be required to practice 580 this standard. Please address the information to the IETF Executive 581 Director. 583 References 585 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 586 Levels", BCP 14, RFC 2119, March 1997. 588 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 589 Describing SNMP Management Frameworks", RFC 2571, April 1999. 591 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 592 Management Information for TCP/IP-based Internets", STD 16, RFC 593 1155, May 1990. 595 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 596 RFC 1212, March 1991. 598 [5] Rose, M., "A Convention for Defining Traps for use with the 599 SNMP", RFC 1215, March 1991. 601 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 602 M. and S. Waldbusser, "Structure of Management Information 603 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 605 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 606 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 607 RFC 2579, April 1999. 609 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 610 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 611 58, RFC 2580, April 1999. 613 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 614 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 616 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 617 "Introduction to Community-based SNMPv2", RFC 1901, January 618 1996. 620 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 621 "Transport Mappings for Version 2 of the Simple Network 622 Management Protocol (SNMPv2)", RFC 1906, January 1996. 624 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 625 Processing and Dispatching for the Simple Network Management 626 Protocol (SNMP)", RFC 2572, April 1999. 628 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 629 for version 3 of the Simple Network Management Protocol 630 (SNMPv3)", RFC 2574, April 1999. 632 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 633 "Protocol Operations for Version 2 of the Simple Network 634 Management Protocol (SNMPv2)", RFC 1905, January 1996. 636 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 637 2573, April 1999. 639 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 640 Control Model (VACM) for the Simple Network Management 641 Protocol (SNMP)", RFC 2575, April 1999. 643 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 644 to Version 3 of the Internet-standard Network Management 645 Framework", RFC 2570, April 1999. 647 [18] McCloghrie, K., "SNMPv2 Management Information Base for the 648 Transmission Control Protocol using SMIv2", RFC 2012, November 649 1996. 651 [19] Daniele, M., "IP Version 6 Management Information Base for the 652 Transmission Control Protocol", RFC 2452, December 1998. 654 [20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB 655 using SMIv2", RFC 2233, November 1997. 657 [21] Hinden, R. and S. Deering, "IP Version 6 Addressing 658 Architecture", RFC 2373, July 1998. 660 [22] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 661 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 663 Authors' Addresses 665 Mike Daniele 666 Compaq Computer Corporation 667 110 Spit Brook Rd 668 Nashua, NH 03062 669 USA 671 Phone: +1 603 884-1423 672 EMail: daniele@zk3.dec.com 673 Brian Haberman 674 Nortel Networks 675 4039 Emperor Blvd., Suite 200 676 Durham, NC 27703 677 USA 679 Phone: +1 919 992-4439 680 EMail: haberman@nortelnetworks.com 682 Shawn A. Routhier 683 Integrated Systems, Inc. 684 1 Tara Blvd, Suite 403 685 Nashua, NH 03062 686 USA 688 Phone: +1 603 897-2000 689 EMail: sar@epilogue.com 691 Juergen Schoenwaelder 692 TU Braunschweig 693 Bueltenweg 74/75 694 38106 Braunschweig 695 Germany 697 Phone: +49 531 391-3266 698 EMail: schoenw@ibr.cs.tu-bs.de 700 Full Copyright Statement 702 Copyright (C) The Internet Society (2000). All Rights Reserved. 704 This document and translations of it may be copied and furnished to 705 others, and derivative works that comment on or otherwise explain it 706 or assist in its implmentation may be prepared, copied, published 707 and distributed, in whole or in part, without restriction of any 708 kind, provided that the above copyright notice and this paragraph 709 are included on all such copies and derivative works. However, this 710 document itself may not be modified in any way, such as by removing 711 the copyright notice or references to the Internet Society or other 712 Internet organizations, except as needed for the purpose of 713 developing Internet standards in which case the procedures for 714 copyrights defined in the Internet Standards process must be 715 followed, or as required to translate it into languages other than 716 English. 718 The limited permissions granted above are perpetual and will not be 719 revoked by the Internet Society or its successors or assigns. 721 This document and the information contained herein is provided on an 722 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 723 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 724 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 725 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 726 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Acknowledgement 730 Funding for the RFC editor function is currently provided by the 731 Internet Society.