Network Working Group Mark Bakke INTERNET DRAFT Cisco<draft-mcdonald-svrloc-mib-03.txt><draft-mcdonald-svrloc-mib-04.txt> Ira McDonaldUpdates: RFC 2608 High North[Target Category: Standards Track]1 March 2002High North Expires:1 September 200227 August 2003 27 February 2003 Definitions of Managed Objects for Service Location Protocol (SLP MIB) <draft-mcdonald-svrloc-mib-04.txt> Copyright (C) The Internet Society(2002).(2003). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines as set of managed objects that support monitoring (but not configuration) of Service Location Protocol Version 2(SLPv2) [RFC2608] [RFC3111](SLPv2, RFC 2608, RFC 3111, RFC 3224) directory agents (DAs), service agents (SAs), and user agents (UAs). Table of Contents 1. Introduction ............................................... 3 2.SNMP NetworkThe Internet-Standard Management Framework........................................... 3 3. Design Requirements for SLP MIB ............................ 4 4. Overview of SLP MIB ........................................54 4.1. Conformance Terminology ................................54 4.2. SLP Terminology ........................................ 5 4.3. Abstract Model of SLP MIB ..............................65 4.4. Relationship to SNMPArchitectureFramework MIB (RFC2571) ....... 73411) .......... 6 4.5. Relationship to Host Resources MIB (RFC 2790) ..........76 5. Definition of SLP MIB ......................................87 5.1. Textual Conventions ....................................98 5.2. Agent Group (Mandatory) Objects ........................109 5.3. Scope Group (Mandatory) Objects ........................1312 5.4. Address Group (Optional) Objects .......................1413 5.5. Attribute Group (Optional) Objects .....................1615 5.6. Conformance Statements .................................1817 5.7. Conformance Groups .....................................1817 6. IANA Considerations ........................................2019 7. Intellectual Property ...................................... 19 8. Internationalization Considerations ........................20 8.19 9. Security Considerations .................................... 209.10. Acknowledgements..................................................................................... 2110.11. Normative References ...................................... 2111.12. Informative References .................................... 2212. Authors' Addresses ........................................ 2313. Authors Addresses ......................................... 22 14. Full Copyright Statement ..................................24 14.23 15. Appendix X - Change Log ...................................2524 1. IntroductionThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines as set of managed objects that support monitoring (but not configuration) of Service Location Protocol Version 2 (SLPv2) [RFC2608] [RFC3111] directory agents (DAs), service agents (SAs), and user agents (UAs).The SLP MIB supports minimal passive monitoring of SLPv2 agents for network management purposes. The SLP MIB also supports (optional) passive monitoring ofremote SLPv2 DA andconfigured or discovered SLPv2SADA/SA network addresses andlocal SLPv2 DA andSLPv2SA agentDA/SA attributes. This document islaid outstructured as follows:o- Section 2 briefly describes the SNMP network management framework.o- Section 3 enumerates design requirements for the SLP MIB.o- Section 4 provides an overview of the SLP MIB, including conformance terminology and SLP-specific terminology.o- Section 5 specifies the SLP MIB in SMIv2 [RFC2578], including the conformance requirements for SNMP Command Responders that claim conformance to this document.o- Sections 6, 7, 8, and89 specify IANA, intellectual property, internationalization, and security considerations.o- Sections9,10, 11, 12, 13, and1314 list acknowledgements, normative references, informative references, authors' addresses, and full IETF copyright statement. 2.SNMP Network Management FrameworkTheSNMPInternet-Standard Management Frameworkpresently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A setFor a detailed overview offundamental applications described in RFC 2573 [RFC2573] andtheview-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction todocuments that describe the currentSNMPInternet-Standard ManagementFramework can be found inFramework, please refer to section 7 of RFC2570 [RFC2570].3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in theSMI.Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to theSMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translationSMIv2, which ispossible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptionsdescribed inSMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Design Requirements for SLP MIB The SLP MIB design requirements listed below are _not_ conformance requirements on _implementations_ of the SLP MIB. Therefore the words must, should, and may are used below in lowercase (informative per [RFC2119] conventions).o(1) The SLP MIB must provide an SNMP interface to monitor SLPv2 [RFC2608] directory agents (DAs), service agents (SAs), and user agents (UAs).o(2) The SLP MIB must be organized so that access can be controlled effectively by using the User-based Security Model [RFC2574] and the View-based Access Control Model [RFC2575] from the SNMPv3 framework.o(3) The SLP MIB must not compromise native security in SLPv2 [RFC2608] by exposing private keys or other confidential information via SNMP.o(4) The SLP MIB must define a core set of mandatory object groups that support minimal passive monitoring requirements.o(5) The SLP MIB must use UTF-8 [2279] for all human-readable text strings per [RFC2277] for internationalization support. 4. Overview of SLP MIB The SLP MIB can be used to monitor SLPv2 [RFC2608] directory agents (DAs), service agents (SAs), and user agents (UAs). The SLP MIB makes no assumptions about the particular system topology of the managed SLP agents (for example, they may be distributed across several rack-mounted processors in a router). 4.1. Conformance Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4.2. SLP Terminology The SLP MIB uses the following definitions from SLPv2 [RFC2608]:o- "User Agent (UA)" A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents.o- "Service Agent (SA)" A process working on the behalf of one or more services to advertise the services.o- "Directory Agent (DA)" A process which collects service advertisements. There can only be one DA present per given host.o- "Scope" A set of services, typically making up a logical administrative group. 4.3. Abstract Model of SLP MIB The Agent group is the principal object group in the abstract model defined in the SLP MIB. The Scope, Address, and Attribute tables (all subordinate to "slpAgentTable") each use a high-order index of "slpAgentIndex" for linkage to the "slpAgentTable". The following is a diagram of the abstract model of the SLP MIB. (Mandatory) |===========| | Agent | (One row perlocalDA, SA, or UA on managed system) |===========| | INDEX { slpAgentIndex } | | | (Mandatory) | 0..* |===========| |.............| Scope | (One row perlocalscope value) | |===========| | INDEX { slpAgentIndex, | slpScopeIndex } | | (Optional) | 0..* |===========| |.............| Address | (One row per remote DA/SA address) | |===========| | INDEX { slpAgentIndex, | slpAddressIndex } | | (Optional) | 0..* |===========| |.............| Attribute | (One row perlocalDA/SA attr) |===========| INDEX { slpAgentIndex, slpAttributeIndex } 4.4. Relationship to SNMPArchitectureFramework MIB (RFC2571)3411) The SLP MIB defines all text strings with a syntax of 'SnmpAdminString'[RFC2571][RFC3411] which supports human-readable information in UTF-8 [RFC2279]. 4.5. Relationship to Host Resources MIB (RFC 2790) The SLP MIB supports specification of the SLP agent software for eachlocalmanaged SLP agent via a pointer to the 'hrSWInstalledTable' in the Host Resources MIB [RFC2790] in the following object:o- "slpAgentSWInstalledIndexOrZero" - a value for "hrSWInstalledIndex" in the Host Resources MIB for this SLP agent's software 5. Definition of SLP MIB SERVICE-LOCATION-PROTOCOL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, mib-2 FROM SNMPv2-SMI -- IETF RFC 2578 TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC -- IETF RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- IETF RFC 2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- IETF RFC 2571 slpMIB MODULE-IDENTITY LAST-UPDATED "200203010000Z" -- 1 March 2002 ORGANIZATION "SLP Project (at Source Forge)" CONTACT-INFO " SLP Project (at Source Forge) Email: srvloc-discuss@lists.sourceforge.net Editor: Mark Bakke Postal: Cisco Systems Inc 6450 Wedgwood Road, Suite 130 Maple Grove, MN 55311 USA Tel: +1 763-398-1000 Email: mbakke@cisco.com Editor: Ira McDonald Postal: High North Inc 221 Ridge Ave Grand Marais, MI 49839 USA Tel: +1 906-494-2434 Email: imcdonald@sharplabs.com" DESCRIPTION "The MIB module for monitoring (but not configuration) of SLP (Service Location Protocol) directory agents (DAs), service agents (SAs), and/or user agents (UAs) on managed systems." ::= { mib-2 999 } -- [to be assigned by IANA] -- [standards track module] slpMIBObjects OBJECT IDENTIFIER ::= { slpMIB 1 } slpMIBConformance OBJECT IDENTIFIER ::= { slpMIB 2 } slpMIBObjectGroups OBJECT IDENTIFIER ::= { slpMIBConformance 2 } -- -- Textual Conventions -- SlpAgentTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of this SLP agent. See: 'net.slp.isDA' in SLP API (RFC 2614)." SYNTAX INTEGER { da(1), -- directory agent sa(2), -- service agent ua(3) -- user agent } SlpScopeSourceTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The source (DHCP, etc) of this SLP scope or scope list. See: Section 2 'Introduction' in RFC 2610." SYNTAX INTEGER { static(1), -- from static local config info staticDA(2), -- from static local config DA dhcp(3), -- from DHCP config info dhcpDA(4), -- from DHCP config DA dynamicDA(5), -- from dynamic DA (DAAdvert) dynamicSA(6), -- from dynamic SA (SAAdvert) default(7) -- use of scope 'DEFAULT' } SlpAttributeTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of this SLP attribute. See: Section 5 'Service Attributes' in SLPv2 (RFC 2608)." SYNTAX INTEGER { attrBoolean(1), -- Boolean ('true' or 'false') attrInteger(2), -- Integer (32-bit string) attrString(3), -- String (UTF-8 string) attrOpaque(4), -- Opaque (sequence of bytes) attrKeyword(5) -- Keyword (name only, no value) } -- -- Agent Group (Mandatory) Objects -- slpAgent OBJECT IDENTIFIER ::= { slpMIBObjects 1 } slpAgentTable OBJECT-TYPE SYNTAX SEQUENCE OF SlpAgentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing SLP (Service Location Protocol) objects for all of the SLP directory agents (DAs), service agents (SAs), or user agents (UAs) currently installed and (possibly) active on this managed system." ::= { slpAgent 1 } slpAgentEntry OBJECT-TYPE SYNTAX SlpAgentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing SLP (Service Location Protocol) objects for one of the SLP directory agents (DAs), service agents (SAs), or user agents (UAs) currently installed and (possibly) active on this managed system." INDEX { slpAgentIndex } ::= { slpAgentTable 1 } SlpAgentEntry ::= SEQUENCE { slpAgentIndex Integer32, slpAgentSWInstalledIndexOrZero Integer32, slpAgentName SnmpAdminString, slpAgentType SlpAgentTypeTC, slpAgentIsBroadcastOnly TruthValue, slpAgentActiveDADiscovery TruthValue, slpAgentPassiveDADiscovery TruthValue, slpAgentMessageTypesSupported OCTET STRING, slpAgentExtensionsSupported OCTET STRING } slpAgentIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ordinal of this conceptual row in 'slpAgentTable'." ::= { slpAgentEntry 1 } slpAgentSWInstalledIndexOrZero OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of 'hrSWInstalledIndex' in the Host Resources MIB (RFC 2790) for the executable software for this SLP agent, or zero if none. See: 'hrSWInstalledIndex' in Host Resources MIB (RFC 2790)." ::= { slpAgentEntry 2 } slpAgentName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The friendly locally unique name for this SLP agent, for use with remote network management scripts and GUIs For example 'daNewYork'." ::= { slpAgentEntry 3 } slpAgentType OBJECT-TYPE SYNTAX SlpAgentTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this SLP agent (DA, SA, or UA). See: 'net.slp.isDA' in SLP API (RFC 2614)." ::= { slpAgentEntry 4 } slpAgentIsBroadcastOnly OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Broadcast only network enabled for this SLP agent. If 'true', SLP agent MUST send only broadcast messages. If 'false', SLP agent MAY send multicast messages. See: 'Broadcast Only' in section 14 of SLPv2 (RFC 2608). See: 'net.slp.isBroadcastOnly' in SLP API (RFC 2614)." DEFVAL { false } -- multicast allowed ::= { slpAgentEntry 5 } slpAgentActiveDADiscovery OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Active DA discovery allowed for this SLP agent. If 'true', SLP agent MAY actively discover DAs, If 'false', SLP agent MUST NOT actively discover DAs. See: 'Active DA Discovery' in SLPv2 (RFC 2608). See: 'net.slp.DAActiveDiscoveryInterval' in SLP API (RFC2614)." DEFVAL { true } -- active DA discovery allowed ::= { slpAgentEntry 6 } slpAgentPassiveDADiscovery OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Passive DA discovery allowed for this SLP agent. If 'true', SLP agent MAY passively discover DAs, If 'false', SLP agent MUST NOT passively discover DAs. See: 'Passive DA Advertising' in SLPv2 (RFC 2608). See: 'net.slp.passiveDADetection' in SLP API (RFC2614)." DEFVAL { true } -- passive DA discovery allowed ::= { slpAgentEntry 7 } slpAgentMessageTypesSupported OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SLP message types supported by this SLP agent, expressed as an array of binary Function-ID values (RFC 2608). For example '0102'H means 'SrvRqst, SrvRply'. See: Section 8 'Required SLP Messages' in SLPv2 (RFC 2608)." ::= { slpAgentEntry 8 } slpAgentExtensionsSupported OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SLP extensions supported by this SLP agent, expressed as an array of binary Extension ID values (RFC 2608), in network byte order (i.e., big-endian representation). For example '00020003'H means 'AttributeList, VendorOpaque'. See: Section 9.1 'SLP Extensions' in SLPv2 (RFC 2608)." DEFVAL { ''H } -- no extensions supported ::= { slpAgentEntry 9 } -- -- Scope Group (Mandatory) Objects -- slpScope OBJECT IDENTIFIER ::= { slpMIBObjects 2 } slpScopeTable OBJECT-TYPE SYNTAX SEQUENCE OF SlpScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing SLP (Service Location Protocol) objects for scope lists on this managed system. Usage: This table sparsely augments the 'slpAgentTable'. Usage: Scope lists consist of one or more rows in the 'slpScopeTable' (one row per scope value) for each SLP agent." ::= { slpScope 1 } slpScopeEntry OBJECT-TYPE SYNTAX SlpScopeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing SLP (Service Location Protocol) objects for one scope value on this managed system." INDEX { slpAgentIndex, slpScopeIndex } ::= { slpScopeTable 1 } SlpScopeEntry ::= SEQUENCE { slpScopeIndex Integer32, slpScopeSource SlpScopeSourceTC, slpScopeValue SnmpAdminString } slpScopeIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ordinal of this conceptual single row in 'slpScopeTable', subordinate to 'slpAgentIndex'." ::= { slpScopeEntry 1 } slpScopeSource OBJECT-TYPE SYNTAX SlpScopeSourceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The source (DHCP, etc) of this SLP scope. See: Section 2 'Introduction' in RFC 2610." ::= { slpScopeEntry 2 } slpScopeValue OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "One scope configured or discovered for this SLP agent. Note: The default (and lowest preference) scope value for any SLP agent is the string 'DEFAULT' verbatim in uppercase, per SLPv2 (RFC 2608). See: 'net.slp.useScopes' in SLP API (RFC 2614)." DEFVAL { ''H } -- no scope configured ::= { slpScopeEntry 3 } -- -- Address Group (Optional) Objects -- slpAddress OBJECT IDENTIFIER ::= { slpMIBObjects 3 } slpAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF SlpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing SLP (Service Location Protocol) objects for remote DA/SA address lists known to this managed system. Usage: This table sparsely augments the 'slpAgentTable'. Usage: DA/SA address lists consist of one or more rows in the 'slpAddressTable' (one row per address) for each SLP agent." ::= { slpAddress 1 } slpAddressEntry OBJECT-TYPE SYNTAX SlpAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing SLP (Service Location Protocol) objects for one remote DA or SA address known to this managed system." INDEX { slpAgentIndex, slpAddressIndex } ::= { slpAddressTable 1 } SlpAddressEntry ::= SEQUENCE { slpAddressIndex Integer32, slpAddressAgentType SlpAgentTypeTC, slpAddressSource SlpScopeSourceTC, slpAddressOrName SnmpAdminString } slpAddressIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ordinal of this conceptual single row in 'slpAddressTable', subordinate to 'slpAgentIndex'." ::= { slpAddressEntry 1 } slpAddressAgentType OBJECT-TYPE SYNTAX SlpAgentTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this remote SLP agent (DA or SA). See: 'net.slp.isDA' in SLP API (RFC 2614)." ::= { slpAddressEntry 2 } slpAddressSource OBJECT-TYPE SYNTAX SlpScopeSourceTC MAX-ACCESS read-only STATUS current DESCRIPTION "The source (DHCP, etc) of this remote SLP agent address. For example 'static(1)'. See: 'slpScopeSource' above in this SLP MIB." ::= { slpAddressEntry 3 } slpAddressOrName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "Text formatted (dotted decimal) IPv4 address; or (per RFC 2373) text formatted (colon-delimited hexadecimal) IPv6 address; or a fully qualifed DNS name for this remote SLP agent (DA or SA). For example '13.281.11.12' or '3FFE:2A00:100:7031::1'. See: IP Version 6 Addressing Architecture (RFC 2373). See: Format for Literal IPv6 Addresses in URLs (RFC 2732). See: 'net.slp.DAAddresses' in SLP API (RFC 2614)." ::= { slpAddressEntry 4 } -- -- Attribute Group (Optional) Objects -- slpAttribute OBJECT IDENTIFIER ::= { slpMIBObjects 4 } slpAttributeTable OBJECT-TYPE SYNTAX SEQUENCE OF SlpAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing SLP (Service Location Protocol) objects for SLP agent (DA or SA) attribute lists on this managed system. Usage: This table sparsely augments the 'slpAgentTable' (UAs do not have attribute lists - DAs/SAs should have attribute lists with at least the SLP standard DA/SA attributes). Usage: Attribute lists consist of one or more rows in the 'slpAttributeTable' (one row per attribute) for each SLP agent." ::= { slpAttribute 1 } slpAttributeEntry OBJECT-TYPE SYNTAX SlpAttributeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing SLP (Service Location Protocol) objects for one SLP agent (DA or SA) attribute on this managed system. See: 'net.slp.DAAttributes' in SLP API (RFC 2614). See: 'net.slp.SAAttributes' in SLP API (RFC 2614)." INDEX { slpAgentIndex, slpAttributeIndex } ::= { slpAttributeTable 1 } SlpAttributeEntry ::= SEQUENCE { slpAttributeIndex Integer32, slpAttributeName SnmpAdminString, slpAttributeType SlpAttributeTypeTC, slpAttributeValue SnmpAdminString } slpAttributeIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ordinal of this conceptual single row in 'slpAttributeTable', subordinate to 'slpAgentIndex'." ::= { slpAttributeEntry 1 } slpAttributeName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of this SLP attribute. For example 'printer-resolution-supported' in the 'service:printer' IANA registered service template. See: Section 5 'Service Attributes' in SLPv2 (RFC 2608)." ::= { slpAttributeEntry 2 } slpAttributeType OBJECT-TYPE SYNTAX SlpAttributeTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this SLP attribute. For example 'attrBoolean' for a string formatted boolean. See: Section 5 'Service Attributes' in SLPv2 (RFC 2608)." ::= { slpAttributeEntry 3 } slpAttributeValue OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this SLP attribute: a) A UTF-8 string if 'slpAttributeType' is 'attrBoolean', 'attrInteger', or 'attrString' b) an escaped string if 'slpAttributeType' is 'attrOpaque'; or c) an empty string if 'slpAttributeType' is 'attrKeyword'. See: Section 5 'Service Attributes' in SLPv2 (RFC 2608)." ::= { slpAttributeEntry 4 } -- -- Conformance Statements -- slpMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statements for SNMP Command Responders that implement the Service Location Protocol MIB." MODULE -- this module MANDATORY-GROUPS { slpAgentGroup, slpScopeGroup } GROUP slpAddressGroup DESCRIPTION "Address Group" GROUP slpAttributeGroup DESCRIPTION "Attribute Group" ::= { slpMIBConformance 1 } -- -- Conformance Groups -- slpAgentGroup OBJECT-GROUP OBJECTS { slpAgentSWInstalledIndexOrZero, slpAgentName, slpAgentType, slpAgentIsBroadcastOnly, slpAgentActiveDADiscovery, slpAgentPassiveDADiscovery, slpAgentMessageTypesSupported, slpAgentExtensionsSupported } STATUS current DESCRIPTION "The Agent object group in the SLP MIB" ::= { slpMIBObjectGroups 1 } slpScopeGroup OBJECT-GROUP OBJECTS { slpScopeSource, slpScopeValue } STATUS current DESCRIPTION "The Scope object group in the SLP MIB" ::= { slpMIBObjectGroups 2 } slpAddressGroup OBJECT-GROUP OBJECTS { slpAddressAgentType, slpAddressSource, slpAddressOrName } STATUS current DESCRIPTION "The Address object group in the SLP MIB" ::= { slpMIBObjectGroups 3 } slpAttributeGroup OBJECT-GROUP OBJECTS { slpAttributeName, slpAttributeType, slpAttributeValue } STATUS current DESCRIPTION "The Attribute object group in the SLP MIB" ::= { slpMIBObjectGroups 4 } END 6. IANA Considerations IANA should assign a base arc in the 'mgmt' (standards track) OID tree for the 'slpMIB' MODULE-IDENTITY defined in the SLP MIB. The following definitions in the SLP MIB depend on IANA registrations:o- "slpAgentMessageTypesSupported" contains an array of the binary values assigned by SLPv2 [RFC2608] or assigned by IANA for the Function-ID in SLPv2 messages.o- "slpAgentExtensionsSupported" contains an array of the binary values assigned by SLPv2 [RFC2608] or assigned by IANA for the Extension ID in SLPv2 messages. There are no other IANA considerations associated with the SLP MIB. 7. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Internationalization Considerations The SLP MIB defines all text strings with a syntax of 'SnmpAdminString'[RFC2571][RFC3411] which supports human-readable information in UTF-8 [RFC2279]. The SLP MIB is therefore in full conformance with the best practices in "IETF Policy on Character Sets and Languages" [RFC2277].8.9. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-writeorand/or read-create.There are a number of read-only managed objects inSo, if this MIB module is implemented correctly, then there is no risk thatmay contain sensitive information. These include: o "slpScopeSource" - a configuration source foranSLPv2 setintruder can alter or create any management objects ofservices (typically an administrative group) o "slpScopeValue" - a string scope value for an SLPv2 setthis MIB module via direct SNMP SET operations. Some ofservices (typically an administrative group) o "slpAddressSource" - a configuration source for an SLPv2 remote directory agent (DA) or service agent (SA) address o "slpAddressOrName" - a string IPv4 address, IPv6 address, or DNS name for an SLPv2 remote DA or SA address These fourthe readable objects in this MIB module (i.e., objectsreveal potentiallywith a MAX-ACCESS other than not-accessible) may be considered sensitiveinformation about the existence and identification of SLPv2 infrastructure.or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP.Not all versions ofThese are the tables and objects and their sensitivity/vulnerability: slpAgentTable: slpAgentSWInstalledIndexOrZero - possible configuration data loss slpAgentName - possible configuration data loss slpAgentType - possible configuration data loss slpAgentIsBroadcastOnly - possible configuration data loss slpAgentActiveDADiscovery - possible configuration data loss slpAgentPassiveDADiscovery - possible configuration data loss slpAgentMessageTypesSupported - possible configuration data loss slpAgentExtensionsSupported - possible configuration data loss slpScopeTable: slpScopeSource - possible configuration data loss slpScopeValue - possible configuration data loss slpAddressTable: slpAddressAgentType - possible configuration data loss slpAddressSource - possible configuration data loss slpAddressOrName - possible configuration data loss slpAttributeTable: slpAttributeName - possible configuration data loss slpAttributeType - possible configuration data loss slpAttributeValue - possible configuration data loss SNMPprovide features for such a secure environment. SNMPv1 by itself isversions prior to SNMPv3 did nota secure environment.include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in thisMIB.MIB module. It isrecommendedRECOMMENDED thattheimplementers consider the security features as provided by the SNMPv3framework. Specifically, the use offramework (see [RFC3410], section 8), including full support for theUser-based Security Model RFC 2574 [RFC2574]SNMPv3 cryptographic mechanisms (for authentication andthe View- based Access Control Model RFC 2575 [RFC2575]privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it isrecommended.RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then acustomer/usercustomer/operator responsibility to ensure that the SNMP entity giving access to an instance of thisMIB,MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.9.10. Acknowledgements The editors would like to thank: Pete St. Pierre (Sun) for his original work on an SLP MIB in 1997; Erik Guttman (Sun) for compiling the requirements for this SLP MIB for SLPv2; Jim Muchow (Cisco) for his comments on the ASN.1 structure and compliance macros; and Bert Wijnen (Lucent) for his comments on size and complexity.10.11. Normative References [RFC2119]S.Bradner. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2277]H.Alvestrand. "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [RFC2279]F.Yergeau. "UTF-8, a Transformation of ISO 10646", RFC 2279, January 1998.[RFC2571] B. Wijnen, D. Harrington, R. Presuhn. "An Architecture for Describing SNMP Network Management Frameworks", RFC 2571, April 1999. [RFC2574] U. Blumenthal, B. Wijnen. "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] B. Wijnen, R. Presuhn, K. McCloghrie. "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.[RFC2578]K.McCloghrie,D.Perkins,J.Shoenwaelder. "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [RFC2579]K.McCloghrie,D.Perkins,J.Shoenwaelder. "Textual Conventions for SMIv2", RFC 2579, April 1999. [RFC2580]K.McCloghrie,D.Perkins,J.Shoenwaelder. "Conformance Statements for SMIv2", RFC 2580, April 1999. [RFC2608]E.Guttman,C.Perkins,J.Veizades,M.Day. "Service Location Protocol, Version 2", RFC 2608, June 1999.[RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and Service: Schemes", RFC 2609, June 1999. [RFC2610] C. Perkins, E. Guttman. "DHCP Options for Service Location Protocol", RFC 2610, June 1999.[RFC2790]S.Waldbusser,P.Grillo. "Host Resources MIB", RFC 2790, March 2000. [RFC3111]E.Guttman. "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.11. Informative References [RFC1155] M. Rose, K. McCloghrie. "Structure and Identification of Management Information for TCP/IP-based internets" [SMIv1], RFC 1155, May 1990. [RFC1157] J. Case, M. Fedor, M. Schoffstall, C. Davin. "Simple Network Management Protocol (SNMP)" [SNMPv1], RFC 1157, May 1990. [RFC1212] M. Rose, K. McCloghrie. "Concise MIB Definitions", RFC 1212, March 1991. [RFC1213] K. McCloghrie, M. Rose. "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991. [RFC1215] M. Rose. "Convention for Defining Traps[RFC3224] Guttman. "Vendor Extensions foruse with the SNMP", RFC 1215, March 1991. [RFC1901] J. Case, K. McCloghrie, M. Rose, S. Waldbusser. "Introduction to Community-based SNMPv2",Service Location Protocol", RFC1901,3224, January1996. [RFC1905] J. Case, K. McCloghrie, M. Rose, S. Waldbusser. "Protocol Operations2002. [RFC3411] Harrington, Presuhn, Wijnen. "An Architecture forVersion 2 of the SimpleDescribing SNMP Network ManagementProtocol (SNMPv2)",Frameworks", STD 62, RFC1905, January 1996. [RFC1906] J. Case, K. McCloghrie, M. Rose, S. Waldbusser. "Transport Mappings3411, December 2002. 12. Informative References [RFC2609] Guttman, Perkins, Kempf. "Service Templates and Service: Schemes", RFC 2609, June 1999. [RFC2610] Perkins, Guttman. "DHCP Options forVersion 2 of the Simple Network Management Protocol (SNMPv2)",Service Location Protocol", RFC1906, January 1996. [RFC1907] J. Case, K. McCloghrie, M. Rose, S. Waldbusser. "Management Information Base2610, June 1999. [RFC2614] Kempf, Guttman. "An API forVersion 2 of the Simple Network Management Protocol (SNMPv2)",Service Location", RFC1907, January 1996. [RFC2570] J.2614, June 1999. [RFC3410] Case,R.Mundy,D.Partain,B.Stewart. "Introductionto Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2572] J. Case, D. Harrington, R. Presuhn, B. Wijnen. "Message ProcessingandDispatchingApplicability Statements forthe Simple NetworkInternet Standard ManagementProtocol (SNMP)", RFC 2572, April 1999. [RFC2573] D. Levi, P. Meyer, B. Stewart. "SNMP Applications",Framework", RFC2573, April 1999. 12. Authors'3410, December 2002. 13. Authors Addresses Editor: Mark Bakke Postal: Cisco Systems Inc 6450 Wedgwood Road, Suite 130 Maple Grove, MN 55311 USA Tel: +1 763-398-1000 Email: mbakke@cisco.com Editor: Ira McDonald Postal: High North Inc 221 Ridge Ave Grand Marais, MI 49839 USA Tel: +1 906-494-2434 Email: imcdonald@sharplabs.com" Usage questions and comments on this SLP MIB should be sent directly to the editors at their above addresses (and to the SLP Project mailing list - see below). Implementers of this specification are encouraged to join the SLP Project mailing list in order to participate in any discussions of clarification issues and comments. SLP Project Mailing List: svrloc-discuss@lists.sourceforge.net To subscribe to the SLP Project mailing list, visit the web page: https://lists.sourceforge.net/lists/listinfo/srvloc-discuss13.14. Full Copyright Statement Copyright (C) The Internet Society(2002).(2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."14.15. Appendix X - Change Log [to be deleted before publication as an RFC] <draft-mcdonald-svrloc-mib-04.txt> 27 February 2003 - completely replaced Internet-Standard Management Framework section, per request of Bert Wijnen - added Intellectual Property section, per request of Bert Wijnen - completely rewrote Security Considerations section, per request of Bert Wijnen - revised Normative References and Informative References sections, per request of Bert Wijnen - added copyright in MODULE-IDENTITY, per request of Bert Wijnen - added REFERENCE clauses for references, per request of Bert Wijnen <draft-mcdonald-svrloc-mib-03.txt> 1 March 2002 - added Normative References section, per request of RFC Editor - added Informative References section, per request of RFC Editor - revised Abstract, Introduction, and Security Considerations to state that the SLP MIB supports passive monitoring (but not configuration), per concensus of SLP Project mailing list - deleted Property group (last remaining 'read-write' objects), per concensus of SLP Project mailing list <draft-mcdonald-svrloc-mib-02.txt> 11 February 2002 - major rewrite to reduce complexity, per request of Bert Wijnen - simplified indexing in Scope, Address, and Attribute groups - changed MAX-ACCESS of all columnar objects from 'read-create' to 'read-only' (for required Monitoring) - deleted all 'RowStatus' objects (no longer needed) - added Property group with 'read-write' scalar objects (for optional Configuration) based on SLPv2 API (RFC 2614). - deleted Admin, Timer, Network, Interface, Counter, and Trace groups - deleted Alert notification group <draft-mcdonald-svrloc-mib-01.txt> 20 November 2001 - removed sub-typing of objects in SEQUENCE clauses, per 'smilint' and section 7.1.12 'Conceptual Tables' of SMIv2 [RFC 2578] - renamed all textual conventions, suffixing 'TC' to avoid names which differ only by case, per 'smilint' warning <draft-mcdonald-svrloc-mib-00.txt> 1 November 2001 - initial version