Internet Draft Administrative Model for SNMPv2C September 1995 Administrative Model for Version 2C of the | Simple Network Management Protocol (SNMPv2C) | Fri Sep 08 1995 draft-various-snmpv2-adminv2C-syn-01.txt | Tell U. Later snmpv2@tis.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires February 1996 [Page 1] Internet Draft Administrative Model for SNMPv2C September 1995 running list of open issues: need to better tie in to the appropriate mib objects bok wants to add report operations reference list reference citations acknowledgements authors author addresses spell check Expires February 1996 [Page 2] Internet Draft Administrative Model for SNMPv2C September 1995 1. Introduction A management system contains: several (potentially many) manageable nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol. The management protocol is used to convey management information between the agents and management stations; and, for manager-to-manager communications, between management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. It is the purpose of this document, the Administrative Model for | SNMPv2C, | to define a transitional framework which realizes effective management during the transition from the SNMPv1 framework to the SNMPv2 framework. 1.1. A Note on Terminology The original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, [@ref 1155, 1157, 1212], defined an initial community-based administrative model, and an initial set of protocol operations. For the purpose of exposition, this is termed the SNMP version 1 framework (SNMPv1). The SNMP version 2 framework (SNMPv2) consists of an identity-based administrative model [@ref v2admin], coupled with an enhanced set of protocol operations [@ref protoops]. is termed the SNMP version 2 framework (SNMPv2). This document describes a transitional approach, using the SNMP version 1 community-based administrative model in combination with the SNMP version 2 protocol operations. This hybrid, which is halfway between the SNMPv1 framework and the SNMPv2 framework is called SNMPv2C to | reflect its character and to avoid confusion | in the marketplace were it to be called SNMPv1 or SNMPv2. Expires February 1996 [Page 3] Internet Draft Administrative Model for SNMPv2C September 1995 2. Overview This document describes the SNMP version 2C (SNMPv2C) management | framework. SNMPv2C is a hybrid, based on some elements of the SNMPv1 | management framework, | and some elements of the SNMPv2 management framework. In particular, it couples the community-based administrative model of SNMPv1 with the SNMPv2 protocol operations. The document also describes a multi-lingual implementation including the | mapping of the SNMPv2C authentication mechanism onto the SNMPv2 | administrative | model, including an appropriate set of MIB objects. 2.1. Framework Components The basic structure of the SNMP framework is shown in Figure 1. It consists of multiple components, two of which are an administrative model and a protocol suite. Other components include the Structure of Management Information, and definitions of management objects. +-----------------------------------------+ | SNMP Framework | | +----------------+ +-------------+ | | | Administrative | | Protocol | | | | Model | | Suite | | | +----------------+ +-------------+ | +-----------------------------------------+ Figure 1: The SNMP Framework 2.2. Historical Perspective The combination of an administrative model with a set of protocol operations has a rich tradition in SNMP-style management. The Internet Standard Management framework, based on the SNMP [@ref 1157] was first introduced in 1988. Since that time, there have been several evolutionary changes to that framework proposed. The Secure SNMP framework [@ref 1351-1353], now historic, was advanced in 1992. It proposed a party and context-based administrative model to provide several services, including authentication and integrity, privacy, access control, and the cooperation of multiple protocol Expires February 1996 [Page 4] Internet Draft Administrative Model for SNMPv2C September 1995 entities (proxy relationships). The party and context-based administrative model was coupled with the SNMPv1 protocol operations. The SMP framework was proposed soon thereafter. The SMP framework coupled a simplified version of the party and context-based administrative framework with an enhanced and expanded set of protocol operations. The SMP framework was adopted as the basis for the SNMPv2 framework in mid 1992. Version 2 of the internet-standard management framework, SNMPv2, when first published in 1993 [@ref 1441-1452], reflected that same modularity, with a party and context-based administrative model coupled with an enhanced and expanded set of protocol operations. More recently, the SNMPv2 framework evolved to an identity and context- based administrative model coupled with an enhanced and expanded set of protocol operations. 2.3. SNMP Version 2C Framework The Version 2C framework described herein follows in this rich heritage. | Like its predecessors, it couples an administrative model with a set of protocol operations. The administrative model is that of the SNMPv1 framework. The set of protocol operations are those of the SNMPv2 framework. This hybrid "transitional" approach is well-aligned with the current needs of major segments of the marketplace and enables the rapid and wide deployment of many SNMPv2 improvements. It also facilitates the orderly transition of community-based user configurations to the more secure authentication and privacy mechanisms of the SNMPv2 administrative model. It is recognized that the community-based administrative model of the SNMPv1 framework [@ref 1157] is intrinsically insecure (that is, users must rely on mechanisms external to the protocol if they want increased authentication and/or privacy). It is also believed that the large installed base of existing community-based implementations will need to be "transitioned" over time, in a gradual and orderly manner, to a more secure SNMP security architecture in the future. It is for these reasons that this document is characterized as a "transitional" approach. Although the security inherent in the SNMPv2C | Expires February 1996 [Page 5] Internet Draft Administrative Model for SNMPv2C September 1995 management framework will not be stronger than that of the | SNMPv1 framework, neither will it be lessened. 2.4. Benefits This proposal offers the SNMP marketplace numerous benefits at a very low incremental cost relative to the existing SNMPv1 installed base. The following are among the major expected benefits of the SNMPv2C | implementation and deployment alternative: o Widely understood and accepted parts of SNMPv2 will be put to work with minimal additional delay. o Easy and quick implementation and deployment by vendors. o Slip-streamable introduction into the field. o No administrative reconfiguration required by users to achieve "better SNMP" with same level of security currently used today. o Smoother transition to future more secure SNMP products (certainly for the users; and possibly for most vendors too). 3. Elements of the Model This section contains definitions required to realize the security model defined by this memo. For the most part, readers should understand that the security model intended is identical to that described in RFC1157 [@ref rfc1157] and we have opted not the replicate all of the relevant text from that document here. The sections that follow are meant to explain the small number of adaptations required. 3.1. SNMPv2C Community Identities Management operations using this security model make use of a defined set of community identities (community names). For any SNMPv2C | community on whose behalf management operations are | authorized at a particular SNMPv2 agent, that agent must have knowledge of that community. An SNMPv2 manager that wishes to communicate with a particular agent must also have knowledge of a community known to that agent, including knowledge of the applicable attributes of that community. Expires February 1996 [Page 6] Internet Draft Administrative Model for SNMPv2C September 1995 A community and its attributes are defined as follows: An octet string representing the name of the community. Operations that are allowed on behalf of this community. A MIBview defining all the object instances for which access is granted for read operations. A MIBview defining all the object instances for which access is granted for write operations. The type of this community (local, remote or proxy). Note: The above list of attributes is not an exhaustive list. Implementations may have other or different attributes. This list is not meant to prescribe an implementation of community names and their attributes. Instead, the list above is used to help explain the Elements of Procedure later on in this document. For example, an implementation may not have any proxy support, and so the value of proxy for the attribute will never hold. In this case, an | implementation may just assume that an SNMPv2C entity | in the manager role is using a community as if the , while an agent uses the community as if the . 3.2. Access Policy An administration's access policy determines the access rights of | communities. For SNMPv2C, the fundamental parameters of any | compliant access policy are defined in Section 3.2.5, "Definition of Administrative Relationships", in RFC1157 [@ref rfc1157]. Compliant implementations of that specification allow for implementation-specific extensions to support an associated "authentication scheme". Many SNMP Expires February 1996 [Page 7] Internet Draft Administrative Model for SNMPv2C September 1995 implementors have, in fact, used such extensions to improve the degree of security provided by the community model (e.g., using the source address as a further qualifier). For a particular SNMPv2C community, that community's access rights | are given by the associated , and for a community, a and a . The read-view is the set of object instances authorized for the user when reading objects. Reading objects occurs when processing a retrieval (get, get- next, get-bulk) operation and when sending a notification. The write- view is the set of object instances authorized for the user when writing objects. Writing objects occurs when processing a set operation. A community's access rights may be different at different agents. 3.3. SNMPv2C Messages The syntax of an SNMPv2C message differs from that of an SNMPv1 | message as follows: o The version component is changed to 1. (The version component in SNMP version 1 had a value of 0.) o The data component contains an SNMPv2 PDU as defined in [@ref protoops]. Consequently, an SNMPv2C message is an ASN.1 value with the following | syntax: | SnmpV2CAdmin DEFINITIONS EXPLICIT TAGS ::= BEGIN | IMPORTS PDUs FROM SNMPv2-PDU SnmpV2CMessage ::= | SEQUENCE { version -- version 1 for this specification INTEGER { version-2C (1) | }, community -- as per RFC1157 OCTET STRING, -- SNMPv1 communityName Expires February 1996 [Page 8] Internet Draft Administrative Model for SNMPv2C September 1995 data PDUs -- SNMPv2 PDUs } END 3.3.1. Version Field The version field communicates the version of the SNMP Framework, which denotes a specific pair of administrative model and protocol suite employed within the message. For messages that conform to this specification, i.e., SNMPv2C messages, | the version number is 1, which denotes a community-based administrative model similar to that of SNMPv1, coupled with SNMPv2 protocol operations. 4. Elements of Procedure This section describes the procedures followed by an SNMPv2C entity in | processing SNMPv2C messages. | 4.1. Generating a Request or Notification This section describes the procedure followed by an SNMPv2C protocol | entity | whenever it generates a message containing a management operation (either a request or a notification) on behalf of an application belonging to a community. (1) Information concerning the communityName is extracted from the LCD. The transport domain and transport address to which the operation is to be sent is determined. (2) The operation is serialized (i.e., encoded) according to the conventions of [@ref tm] and [@ref protoops] into a PDUs value. (3) An SNMPv2C message is constructed using the ASN.1 SnmpV2CMessage | syntax with the version component set to the value 1. (4) The constructed SnmpV2CMessage value is serialized (i.e., encoded) | according to the conventions of [@ref tm] and [@ref protoops]. Expires February 1996 [Page 9] Internet Draft Administrative Model for SNMPv2C September 1995 (5) The serialized SnmpV2CMessage value is transmitted to the | determined | transport address. 4.2. Processing a Received Communication This section describes the procedure followed by an SNMPv2C protocol | entity whenever it receives an SNMPv2C message. This procedure is | independent of the transport service address at which the message was received. (1) The snmpInPkts counter [@ref v2mib4v2] is incremented. If the | received message is not the serialization (according to the | conventions of [@ref tm] of a SnmpV2CMessage value, then the | snmpInASNParseErrs counter [@ref v2mib4v2] is incremented, and the | message is discarded without further processing. (2) If the value of the version component has a value other than 1, then the message is either processed according to some other | version of this protocol, or the snmpInASNParseErrs | counter [@ref v2mib4v2] is incremented, and the message is discarded without further processing. (3) The communityName is extracted from the community component of the | SnmpV2CMessage value. | (4) Information about the value of the communityName is extracted from the LCD. If no information is available, then the received message is discarded without further processing. However, if the SNMPv2C | protocol entity is acting | in an agent role and the snmpV2EnableAuthenTraps object [@ref v2mib4v2] is enabled, then it sends authenticationFailure traps [@ref v2mib4v2] according to its configuration. (5) The operation type is determined from the ASN.1 tag value associated with the PDUs component. (6) If the operation type is either a Get, GetNext, GetBulk, or Set operation, then: a. the LCD is consulted for access rights authorized for communications on behalf of the community concerning management information for the particular operation type. Expires February 1996 [Page 10] Internet Draft Administrative Model for SNMPv2C September 1995 b. if the operation type is not among the authorized access rights, then the snmpV1BadCommunityUses counter [@ref v2mib4v2] is incremented. The received message is then discarded without further processing after generation and transmission of a response message. This response message is sent on behalf of the same community. Its var-bind-list and request-id components are identical to those of the received request. Its error-index component is zero and its error-status component is authorizationError [@ref protoops]. c. The information extracted from the LCD concerning the community, together with the sending transport address of the received message is cached for later use in generating a response message. d. if the LCD information indicates the SNMPv2C community is | of type local, then the management operation represented by the | PDUs value is performed by the receiving SNMPv2C protocol entity | with respect to the relevant MIB view associated with this community according to the procedures set forth in [@ref protoops], where the relevant MIB view is determined according to the community and the type of operation requested. e. if the LCD information indicates the community is of type proxy, then: 1) the LCD is consulted to extract information on how to forward the request (e.g. a communityName to be used for forwarding). If this information is not available, the received message is discarded. 2) a new SNMPv2C message is constructed: its PDUs | component is copied from that in the received message except that the contained request-id is replaced by a unique value (this value will enable a subsequent response message to be correlated with this request); A new communityName (as extracted from the LCD) is used as communityName. 3) the information cached in Step 6c above is augmented with the request-id of the received message as well as the request-id of the constructed message. 4) the constructed message is forwarded to the appropriate Expires February 1996 [Page 11] Internet Draft Administrative Model for SNMPv2C September 1995 transport address. (7) If the operation type is either a SNMPv2-Trap, Inform, or Response operation, then: a. if the LCD information indicates the community is of type local, then the received message is discarded without further processing. b. if the LCD information indicates the community is of type remote then the management operation represented by the PDUs value is | performed by the receiving SNMPv2C protocol entity | according to the procedures set forth in [@ref protoops]. c. if the LCD information indicates the community is of type proxy, and the operation type is a Response, then: 1) the request-id is extracted from the PDUs component of the received message. The communityName and extracted request-id are used to correlate this response message to the corresponding values for a previously forwarded request by inspecting the cache of information as augmented in Step 6e3 above. If no such correlated information is found, then the received message is discarded without further processing. 2) a new SNMPv2C message is constructed: its PDUs | component is copied from that in the received message except that the contained request-id is replaced by the value saved in the correlated information from the original request; its communityName is set to the value saved from the original request. 3) the constructed message is forwarded to the transport address saved in the correlated information as the sending transport address of the original request. 4) the correlated information is deleted from the cache of information. d. if the LCD information indicates the community is of type proxy and the operation type is an Inform or SNMPv2-Trap, then: Expires February 1996 [Page 12] Internet Draft Administrative Model for SNMPv2C September 1995 1) a unique request-id is selected for use by all forwarded copies of this request. This value will enable a subsequent response message to be correlated with this request. 2) information is extracted from the LCD concerning all communityNames with which the received message is to be forwarded. 3) for each such combination whose access rights permit Inform or SNMPv2-Trap operations (as appropriate) to be forwarded, a new | SNMPv2C message is constructed: its | PDUs component is copied from that in the received message except that the contained request-id is replaced by the value selected in Step 8d1 above; its communityName is set to the value extracted in Step 8d2. 4) if the operation type of the received message is an Inform, | then for each constructed SNMPv2C message, | information concerning the communityName, request-id and sending transport address of the received message, as well as the request-id and communityName of the constructed message, is cached for later use in generating a response message. 5) each constructed message is forwarded to the appropriate transport address. 4.3. Generating a Response The procedure for generating a response to an SNMPv2C management | request is identical to the procedure for transmitting a request (see Section 4.1, "Generating a Request or Notification", with these exceptions: o The response is sent on behalf of the same community as the request. o The PDUs value of the responding SnmpV2CMessage value is the | response | which results from performing the operation specified in the original PDUs value. Expires February 1996 [Page 13] Internet Draft Administrative Model for SNMPv2C September 1995 o The serialized SnmpV2CMessage value is transmitted using the | transport | address and transport domain from which its corresponding request originated - even if that is different from any transport information obtained from the LCD. 5. Multi-Lingual Implementation Considerations This section considers important issues for implementations which chose | to support SNMPv2C framework in conjunction with the SNMPv2 framework. | In particular, mappings between the SNMPv2C framework and the SNMPv2 | framework are described. There are many reasons why an implementer might chose to co-locate an | SNMPv2C protocol entity with an SNMPv2 protocol entity; the most likely | is | to ease the transition from the SNMPv1 management framework to the SNMPv2 management framework. In such cases, the Elements of Procedure section, above, can be replaced with references to the SNMPv2 framework, and its elements of procedure. 5.1. Processing a Received Communication in Multilingual Environments This section describes the procedure followed by a multilingual protocol | entity which supports the SNMPv2C management framework and the SNMPv2 | management framework whenever it receives an SNMPv2C message. | (1) The snmpInPkts counter [@ref v2mib4v2] is incremented. If the | received message is not the serialization according to the | conventions of [@ref tm] of a SnmpV2CMessage value, then the | message is passed to another appropriate SNMP protocol entity running on the node, e.g., an SNMPv1 [@ref 1157] or SNMPv2 [@ref v2admin] protocol entity, if any, for further processing. Otherwise, the snmpInASNParseErrs counter [@ref v2mib4v2] is | incremented, and the | message is discarded without further processing. (2) The communityName is extracted from the community component of the | SnmpV2CMessage value. | (3) Information about the value of the communityName is extracted from the LCD. Information extracted includes the communityAuthSnmpID, Expires February 1996 [Page 14] Internet Draft Administrative Model for SNMPv2C September 1995 communityGroupName, communityContextSnmpID, communityContextName, and communityTransportLabel. If no information is available, then the received message is discarded without further processing. However, if the SNMPv2C | protocol entity is acting | in an agent role and the snmpV2EnableAuthenTraps object [@ref v2mib4v2] is enabled, then it sends authenticationFailure traps [@ref v2mib4v2] according to its configuration. (4) The source address is then validated. If the extracted communityTransportLabel is zero octets in length, or not present, which indicate that source address validation is not desired or not implemented, then the message is deemed authentic. If the communityTransportLabel is non-null, the transport table [@ref adminmib] is consulted. All entries in the transport table corresponding to the communityTransportLabel are examined which match the received transport domain. If, for any one or more entries, the entry's transportAddress logically anded with the entry's transportReceiveMask is equal to the source address of the message anded with the entry's transportReceiveMask, then the values of transportSnmpID, and transportMMS are extracted, and the message is deemed authentic. Otherwise, the received message is discarded without further | processing. However, if the SNMPv2C protocol entity is acting | in an agent role and the snmpV2EnableAuthenTraps object [@ref v2mib4v2] is enabled, then it sends authenticationFailure traps [@ref v2mib4v2] according to its configuration. (5) The extracted context information is combined with the received PDUs value to construct a plaintext ScopedPDU. (6) The value of communityName is assigned to identityName. (7) The extracted values of communityName, communityGroupName, transportSnmpID, are delivered to the SNMPv2 protocol engine with the resulting ScopedPDU corresponding to values of identityName, groupName, authSnmpID, and plaintext ScopedPDU, respectively for further processing as if they had been returned from an authentication and privacy service corresponding to an sPI value corresponding to SNMPv2C. These data are accompanied by the | Expires February 1996 [Page 15] Internet Draft Administrative Model for SNMPv2C September 1995 sender's transport information, | and the extracted value of the sender's maximum message size. 5.2. Generating a Request or Notification This section describes the procedure followed by a multilingual protocol entity which supports the SNMPv2C management framework and the SNMPv2 | management framework whenever it generates a message containing a management operation (either a request or a notification) on behalf of an application with a requested sPI value corresponding to SNMPv2C. | (1) The communityTable is consulted to locate an entry such that o the communityAuthSnmpID matches the provided authSnmpID; o the communityName matches the provided identityName; o the communityContextName matches the provided contextName; and o the communityContextSnmpID matches the provided contextSnmpID. If there is no such entry, then the message cannot be sent and the requesting application is suitably advised. (2) Otherwise, the communityName and communityTransportLabel are extracted from the matching entry (it is an ambiguous configuration for there to be more than one such entry). (3) The operation is serialized (i.e., encoded) according to the conventions of [@ref tm] and [@ref protoops] into a PDUs value. (4) An SNMPv2C message is constructed using the ASN.1 SnmpV2CMessage | syntax with the version component set to the value 1, the extracted value of communityName, and the resulting PDUs value. (5) The constructed SnmpV2CMessage value is serialized (i.e., encoded) | according to the conventions of [@ref tm] and [@ref protoops]. (6) The serialized SnmpV2CMessage value is transmitted to | each appropriate transport domain and transport address, as Expires February 1996 [Page 16] Internet Draft Administrative Model for SNMPv2C September 1995 determined from entries in the transportTable corresponding to the extracted value of communityTransportLabel, or otherwise, as indicated by the requesting application. Expires February 1996 [Page 17] Internet Draft Administrative Model for SNMPv2C September 1995 6. Definitions COMMUNITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, UInteger32 FROM SNMPv2-SMI RowStatus, TestAndIncr FROM SNMPv2-TC MemoryType, TransportLabel, AuthName, SnmpID FROM V2ADMIN-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; communityMIB MODULE-IDENTITY LAST-UPDATED "9508121700" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO "snmpv2@tis.com Full contact info to be provided . . ." DESCRIPTION "The MIB module for configuring SNMPv2 agents." ::= { snmpModules xx } -- -- Spin lock for modification of the communityTable -- communitySpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating SNMPv2 entities, all acting in a manager role, to coordinate their use of SNMPv2 set operations to entries in the communityTable. A manager application should include the value of communitySpinLock in every set operation which accesses the communityTable. Since this is an advisory lock, entities acting in an agent role do not enforce the use of communitySpinLock." ::= { communityMIB 1 } -- -- The communityTable contains a database of community strings. -- This table provides mappings between a community string, and the Expires February 1996 [Page 18] Internet Draft Administrative Model for SNMPv2C September 1995 -- parameters required for processing SNMPv2 messages. -- -- Note that this table does not include an authSnmpID, as this -- value will always be equal to the snmpID object of the agent -- which implements the table. -- communityTable OBJECT-TYPE SYNTAX SEQUENCE OF CommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The database of community strings." ::= { communityMIB 2 } communityEntry OBJECT-TYPE SYNTAX CommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { communityAuthSnmpID, IMPLIED communityName } | ::= { communityTable 1 } CommunityEntry ::= SEQUENCE { communityAuthSnmpID SnmpID, communityName AuthName, communityGroupName AuthName, communityContextSnmpID SnmpID, communityContextName AuthName, communityTransportLabel TransportLabel, communityMemoryType MemoryType, communityStatus RowStatus } communityAuthSnmpID OBJECT-TYPE SYNTAX SnmpID MAX-ACCESS read-create STATUS current DESCRIPTION "The authSnmpID to which a community string maps. For non-proxy and incoming proxy community strings, this should always be equal to the local SNMPv2 entity's snmpID object. For outgoing proxy community strings, this should be equal to the snmpID of the destination Expires February 1996 [Page 19] Internet Draft Administrative Model for SNMPv2C September 1995 SNMPv2 entity." ::= { communityEntry 1 } | communityName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration. This value is also used as an identityName when mapping between community strings and identityNames." ::= { communityEntry 2 } communityGroupName OBJECT-TYPE SYNTAX AuthName MAX-ACCESS read-create STATUS current DESCRIPTION "The SNMPv2 groupName to which a community string maps. This object is used to determine access rights for a community string through the acTable." ::= { communityEntry 3 } communityContextSnmpID OBJECT-TYPE SYNTAX SnmpID MAX-ACCESS read-create STATUS current DESCRIPTION "The v2ContextSnmpID to which a community string maps. This object specifies the snmpID of the context in which management information is accessible to this community." ::= { communityEntry 4 } communityContextName OBJECT-TYPE SYNTAX AuthName MAX-ACCESS read-create STATUS current DESCRIPTION "The v2ContextName to which a community string maps. This object specifies the context in which management information is accessible to this community." ::= { communityEntry 5 } communityTransportLabel OBJECT-TYPE SYNTAX TransportLabel Expires February 1996 [Page 20] Internet Draft Administrative Model for SNMPv2C September 1995 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints from which an agent will accept management requests. If a management request containing this community is received on a transport endpoint other than the transport endpoints identified by this object, the request is deemed unauthentic. The transports identified by this object are specified in the transportTable. Entries in the transportTable whose transportLabel value are equal to this object are identified. If the value of this object has zero-length, or if the transportTable is not implemented, then transport endpoints are not checked when authenticating messages containing this community string." ::= { communityEntry 6 } communityMemoryType OBJECT-TYPE SYNTAX MemoryType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the communityTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { communityEntry 7 } communityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the communityTable. An entry in this table is not qualified for activation until instance of all corresponding columns have been initialized, either through default values, or through Set operations." ::= { communityEntry 8 } Expires February 1996 [Page 21] Internet Draft Administrative Model for SNMPv2C September 1995 v2AdminCommunityGroup OBJECT-GROUP OBJECTS { communitySpinLock, communityAuthSnmpID, communityName, communityGroupName, communityContextSnmpID, communityContextName, communityTransportLabel, communityMemoryType, communityStatus } STATUS current DESCRIPTION "A collection of objects providing for configuration of an | SNMPv1 or SNMPv2C agent." | ::= { v2AdminMIBGroups 6 } END Expires February 1996 [Page 22] Internet Draft Administrative Model for SNMPv2C September 1995 7. Acknowledgements To be provided here. 8. References To be provided here. 9. Authors' Addresses Tell U. Later snmpv2@tis.com Expires February 1996 [Page 23] Internet Draft Administrative Model for SNMPv2C September 1995 Table of Contents 1 Introduction .................................................... 3 1.1 A Note on Terminology ......................................... 3 2 Overview ........................................................ 4 2.1 Framework Components .......................................... 4 2.2 Historical Perspective ........................................ 4 2.3 SNMP Version 2C Framework ..................................... 5 2.4 Benefits ...................................................... 6 3 Elements of the Model ........................................... 6 3.1 SNMPv2C Community Identities .................................. 6 3.2 Access Policy ................................................. 7 3.3 SNMPv2C Messages .............................................. 8 3.3.1 Version Field ............................................... 9 4 Elements of Procedure ........................................... 9 4.1 Generating a Request or Notification .......................... 9 4.2 Processing a Received Communication ........................... 10 4.3 Generating a Response ......................................... 13 5 Multi-Lingual Implementation Considerations ..................... 14 5.1 Processing a Received Communication in Multilingual Environ- ments ........................................................ 14 5.2 Generating a Request or Notification .......................... 16 6 Definitions ..................................................... 18 7 Acknowledgements ................................................ 23 8 References ...................................................... 23 9 Authors' Addresses .............................................. 23 Expires February 1996 [Page 24]