Service Location Working Group Michael Day INTERNET DRAFT Intel 6 March 1998 The Systems Management Abstract Service Type draft-ietf-svrloc-sysman-02.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@corp.home.net mailing list. Distribution of this memo is unlimited. 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 ftp.is.co.za (Africa), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents definitions for the "sysman" (systems management) abstract service, and the "dmi" (desktop management interface), "cim" (common information model), "snmp" (simple network management protocol), and "host" concrete service types. These definitions are suitable for use with the Service Location Protocol [1]. Systems management, as used in this document, relates to the monitoring, diagnosing, service and support of desktop and host computers. 1. Introduction Service templates and abstract service types are defined in [2]. The systems management abstract service type is designed to organize information from various services, protocols, and schemas that relate to systems management. Day Expires 6 September 1998 [Page 1]
Internet Draft Systems Management Abstract Service March 1998 2. Using SLP For Network and Systems Management When deploying SLP for purposes of network or systems management, there are some important points to consider. These include ease of administration, having a low impact on the network, and providing SLP support for the entire range of systems on the network. (Note that using SLP to discover managed systems will only find managed systems that support SLP.) Network and systems management applications need to continue working when other network components are broken. Further, management applications frequently need to obtain information that has a very short lifetime. These considerations motivate some of the recommendations that are listed below. The Service Location Protocol can provide a number of applications for network and systems management. For example: - A manager can use SLP to discover managed systems without performing brute-force scanning of the network. - A manager can select manageable systems based on specific attributes, such as support for a specific management protocol, agent, instrumentation group, and software distribution format. - A managed system can use SLP to find its manager(s), to which the managed system can then send traps and issue trouble tickets. - A managed system can use SLP to publish basic information about itself, such as its operating system vendor, type and version; its MAC address(es); operator information; management agent(s) hosted by that system, and so on. - A manager can periodically search for new hosts using SLP. A good strategy to follow when using SLP for manageability includes the following points: - Peer-to-peer implementation. Each managed system, along with each management application, implements UA and SA functionality. The system advertises its management services using the "service:sysman" concrete types. - Bootstrap capability. Each managed system, along with each management application can begin functioning with no knowledge of exisiting manageability services beyond a knowledge of its own UA. For example, a management application can, with no foreknowledge, use SLP to build a list of manageable stations and their basic capabilities. Day Expires 6 September 1998 [Page 2]
Internet Draft Systems Management Abstract Service March 1998 This bootstrap capability requires the use of multicast or broadcast with convergence. Multicasting and broadcasting should be avoided when possible. However, bootstrap capability is a key aspect of systems management. (What happens when the DA is broken and needs to be managed?) Therefore, managers and managed stations should use DAs for discovery when they exist, but must also have the ability to perform multicast or broadcast with convergence. - DAs for support of mobile and occasionally connected stations, as well as for scalability. DAs provide a good way to support the discovery of mobile and occasionally connected systems because they can act as SLP proxies for such systems, which may be connected via a slow link. In addition, DAs provide scalability to SLP. - If the site implments adminstrative domains, it should also implement a management-specific domain. SAs that publish "service:sysman" types should register their information with DAs that are scoped for the management-specific domain. More information on domain scoping for management is in section section 9 below, "Domain Scoping for Manageability. 3. The "sysman" Abstract Service ---------------------------template begins here----------------------- type = service:sysman version = 0.0 language = en description = The 'service:sysman' abstract service type organizes information from various services, protocols, and schemas that relate to systems management. Systems management, as used in this document, relates to the monitoring, diagnosing, service and support of desktop and host computers. url-syntax = url-path = hosturl / dmiurl / cimurl / snmpurl hosturl = url as defined in "Host Service Type" (below) dmiurl = url as defined in "DMI Service Type" (below) cimurl = url as defined in "CIM Service Type" (below) snmp1url = url as defined in "SNMPv1 Service Type" (below) ---------------------------template ends here------------------------- contact="Erik Guttman" <Erik.Guttman@sun.com> Day Expires 6 September 1998 [Page 3]
Internet Draft Systems Management Abstract Service March 1998 security considerations= Note the security considerations associated with the concrete types defined below. 4. The Host Service Type The "host" concrete service type provides information immediately relevant to the management of a desktop or host computer, such as computer's the operating system version and vendor, its physical location, and so on. The service:sysman:host service template is as follows: ---------------------------template begins here----------------------- type = service:sysman:host version = 0.1 language = en description = The "host" concrete service type provides information immediately relevant to the management of a desktop or host computer. url syntax= url-path = ([machine-name] os-name os-vendor os-majorverion [os-minorversion] [os-revision] mac-address [contact]) machine-name = ";machine-name =" 1*alpha-num os-name = ";os-name =" 1*alpha-num os-vendor = ";os-vendor =" 1*alpha-num os-majorversion = ";os-major =" 1*DIGIT os-minorversion = ";os-minor =" 1*alpha-num os-revision = ";os-revision =" 1*alpha-num mac-address = ";mac-address =" 12HEXDIG owner = ";owner =" 1*CHAR machine-uuid = ";uuid =" as defined in [3] ;uuid is a 128-bit value, represented ;as a string, that provides a unique ;id to hardware that supports this ;this feature ; the fields beginning with machine-name and ending with ; owner are each defined as an attributed, below. machine-name = string O L # The machine-name attribute is optional. It SHOULD be included # whenever the computer has a network name other than a domain # name. Day Expires 6 September 1998 [Page 4]
Internet Draft Systems Management Abstract Service March 1998 os-name = string L # The os-name attribute is required. It signifies the operating # system running on the computer. Although there is no list of # allowed values, the following values are recommended for their # operating systems: # # (solaris, netware, windows-nt, windows-95, windows, # linux, dos, macos, aix, irix, hpux, bsdi, freebsd) # # Implementations SHOULD use a value from the preceeding list # when representing one of those operating systems. Other values # may be used for other operating systems. os-vendor = string L # The os-vendor attribute is required. It signifies the vendor of # operating system running on the computer. For example, "Sun # Microsystems," "Microsoft," or "Santa Cruz Operation." # # NOTE: There is an important convention for representing # vendor strings. See section 9. os-majorversion = integer L # The os-majorversion attribute is required. It signifies the # major version of the operating system running on the computer. os-minorversion = string O L # The os-minorversion attribute is optional. It signifies the minor # version of the operating system running on the computer. os-revision = string O L # The os-revision attribute is optional. Some vendors use a # revision string to indicate the build of their operating systems, # instead of a version number. mac-address = string M L # The mac-address attribute is required. It is a string # representation of the hexadecimal mac address of each network # card in the computer. There MUST be one mac-address attribute for # each network card in the computer. owner = string O # The owner attribute is optional and presents a human-readable # string containing contact information for the computer. This # attribute SHOULD contain a name and phone number, but MAY contain # other information. machine-uuid = string O L # The machine-uuid attribute is optional. It signifies the machine # UUID or GUID of the host. This value is specific to the machine # itself and not the host operating system nor to any of its # applications. For machines that do not have an embedded UUID, a # software program may generate a machine UUID. Day Expires 6 September 1998 [Page 5]
Internet Draft Systems Management Abstract Service March 1998 ---------------------------template ends here------------------------- contact="Michael Day" <michael_day@ccm.ut.intel.com> security considerations= Free access to computer owner information may present a security risk in some environments. The other information provided by this service type is generally available in most environments. 5. The DMI Service Type The "dmi" service type provides information about the computer's support of the Desktop Management Interface (DMI), an instrumentation standard supported by the Desktop Management Task Force (DMTF) [4]. The service:sysman:dmi service template is as follows: ---------------------------template begins here----------------------- type = service:sysman:dmi version = 0.1 language = en description = The "dmi" concrete service type provides information the availibility of Desktop Management Interface services on the computer. For information on the desktop management interface, see http://www.dmtf.org url syntax= url-path = (provider vendor provider-major provider-minor [remote-interface] [access-point] [security-level]) provider-vendor = ";vendor = " 1*alpha-num provider-major = ";major =" 1*DIGIT provider-minor = ";minor =" 1*alpha-num remote-interface = ";remote=" 1*ALPHA" access-point = ";access-point =" 1*safe-char security-level = ";security =" 1*safe-char ; The fields beginning with provider-major and ending with ; security-level are defined as attributes, below provider-vendor = string L # The provider-vendor attribute is required. It signifies the # vendor of the DMI service provider running on the computer. # # NOTE: There is an important convention for representing # vendor strings. See section 9. Day Expires 6 September 1998 [Page 6]
Internet Draft Systems Management Abstract Service March 1998 provider-major = integer X # The provider-major attribute is required, and SHOULD be included # in service request predicates. It signifies the major version of # the computer's DMI service provider. Allowable values are as # follows: 1, 2 provider-minor = string L # The provider-minor attribute is required. It signifies the minor # revision of the computer's DMI service provider. remote-interface = string L O # The remote-interface attribute is optional. It signifies the # network interface to the DMI service provider. Allowable values # are as follows: DCE, ONC, TI, RAP access-point = string L O ncacn_ip_tcp # The access-point attribute is optional. It signifies the binding # access point of the service provider's remote interface. # Allowable values are as follows: ncacn_ip_tcp ; connection-oriented, TCP over IP ncadg_ip_udp, ; datagram, UDP over IP ncacn_nb_tcp, ; connection-oriented, NetBIOS over TCP ncacn_spx, ; connection-oriented, Novell SPX ncadg_ipx ; datagram, Novell IPX security-level = string L O Off # The security-level attribute is optional. It signifies the # security mechanisms that are active with the computer's service # provider. On, Off ---------------------------template ends here------------------------- contact="Michael Day" <michael_day@ccm.ut.intel.com> security considerations= The Desktop Management Interface does not yet have a standard security scheme. Some attributes may not be secured. Information about remote access points to the DMI service provider may present a security risk if the RPC mechanism is not adminstered properly. 6. The CIM Service Type The "cim" service type provides information about the computer's support of the Common Information Model (CIM)[5]. CIM is a schema description languate, meta-schema, and core schema published by the Desktop Management Task Force. Day Expires 6 September 1998 [Page 7]
Internet Draft Systems Management Abstract Service March 1998 The service:sysman:cim service template is as follows: ---------------------------template begins here----------------------- type = service:sysman:cim version = 0.0 language = en description = The "cim" concrete service type provides information the availibility of Common Information Model services on the computer. For more information see http://www.dmtf.org url syntax= url-path = (cim-major cim-minor cim-revision om-vendor om-major om-minor om-revision [remote-interface] [access-point]) cim-major = ";cim-major =" 1*DIGIT cim-minor = ";cim-minor =" 1*DIGIT cim-revision = ";cim-revision =" 1*alpha-num om-vendor = ";om-vendor =" 1*alpha-num om-major = ";om-major =" 1*DIGIT om-minor = ";om-minor =" 1*DIGIT om-revision = ";om-revision =" 1*alpha-num remote-interface= ";remote =" 1*alpha-num access-point = ";access-point =" 1*safe-char ; The fields beginning with cim-major and ending with ; access-point defined as attributes, below. cim-major = integer X # The cim-major attribute is required and signifies the major # version of the Common Information Model Schema Description # Language that is supported on the computer. This attribute SHOULD # be included in service request predicates. Allowable values are # as follows: 1, 2 cim-minor = integer X # The cim-minor attribute is required and signifies the minor # version of the Common Information Model Schema Description # Language that is supported on this computer. This attribute SHOULD # be included in service request predicates. cim-revision = string L X # The cim-revision attribute is required and signifies the # revision of the Common Information Model Schema Description # Language that is supported on this computer. This attribute # SHOULD be included in service request predicates. Day Expires 6 September 1998 [Page 8]
Internet Draft Systems Management Abstract Service March 1998 om-vendor = string L X # The om-vendor attribute is required and signifies the vendor of # the CIM object manager (CIMOM) that is present on the computer. # This attribute SHOULD be included in service request predicates. # # NOTE: There is an important convention for representing # vendor strings. See section 9. om-major = integer X # The om-major attribute is required and signifies the major # version of the CIM object manager (CIMOM) that is supported on the # computer. This attribute SHOULD be included in service request # predicates. om-minor = integer X # The om-minor attribute is required and signifies the minor # version of the CIM object manager (CIMOM) that is supported on the # computer. This attribute SHOULD be included in service request # predicates. om-revision = string L # The om-minor attribute is required and signifies the revision # version of the CIM object manager (CIMOM) that is supported on the # computer. remote-interface = string L O # The remote-interface attribute is optional and signifies the # network interface to the CIM object manager (CIMOM). Examples # of expected values include be "DCE-RPC, "IIOP," or "DCOM." access-point = string L O # The access-point attribute is optional and signifies the network # service access point to the CIM object manager (CIMOM). Examples # of expected values include "TCP/IP," and "IPX." ---------------------------template ends here------------------------- contact="Michael Day" <michael_day@ccm.ut.intel.com> security considerations= CIM security is derived from the CIMOM and the attributes defined in the CIM schema being accessed. Adminstrators should take care to understand the security attributes of the CIM schemas and the characteristics o their CIMOM before publishing information about remote access to CIM data. 7. The SNMPv1 Service Type The "snmpv1" service type provides information about Simple Network Management Protocol version 1 services that are supported by the computer. Day Expires 6 September 1998 [Page 9]
Internet Draft Systems Management Abstract Service March 1998 The service:sysman:snmpv1 service template is as follows: -------------------------template begins here----------------------- type=service:sysman:snmpv1 version=0.0 lang=en description= The 'service:sysman:SNMPv1:' URL provides information about the SNMPv1 manageability of a given host. Namely, if this URL exists for a host (denoted by the <addr-spec> in the URL,) the host supports SNMPv1. url-syntax= url-path = ( [port-list] [comm-string] [oid-list]) ; None of the attributes listed in the URL path ; are required. They MAY be included. port-list = ";ports=" port-list ports = port / port "," ports ; See the Service URL <port> production rule. ; This field is defined as an attribute, below. comm-string = ";read-community-string=" 1*uchar ; See the Service URL <uchar> production rule. ; This field is defined as an attribute, below. ports=integer M L O 161 # This attribute must be included if the service:URL does not # contain transport protocol information. It lists all UDP ports on # which SNMP Agents are listening. read-community-string=string L O # The read community string may be included as an attribute of # a service:network-managment:snmp: URL. This is useful in # cases where the community string is PUBLIC and ease of access # to the SNMP Agent is desired. See the 'security considerations.' --------------------------template ends here------------------------ contact="Erik Guttman" <Erik.Guttman@sun.com> security considerations= The read-community-string MUST only be included if the value of this string is considered to be public. If this attribute is included, absolutely anyone may access the SNMP Agent and get information from it. This may be desirable in some cases. If this string is considered confidential information, the read-community-string MUST NOT be included in the URL path nor in service registrations of the URL made through SLP or other protocols. Day Expires 6 September 1998 [Page 10]
Internet Draft Systems Management Abstract Service March 1998 8. Other Security Considerations In addition to specific security considerations list above, each of these service types inherit the security considerations of the "service:" URL scheme as specified in [2]. 9. Domain Scoping for Manageability When a site activates SLP administrative scoping, this can cause problems for management applications that use SLP for discovery. The problems are associated with visibility of published services. Specifically, if a management application is not part of an administrative scope, it will not be able to discover management services that are within that scope. Management applications sometimes have a peculiar need to "see" and "hear" everything that exists in a computing environment, and this need extends to service location. Therefore, whenever SLP administrative scoping is in place, there should also be a service-specific scope established for the "service:sysman" type, for example "systems-management". With a systems-management scope in place, all UAs and SAs that support the "service:sysman" type will need to be configured to use that scope to advertise and discover management services. SLP supports scope lists, meaning that UAs and SAs can be members of more than one scope. In addition, the SLP DHCP discovery options will support an optional scope list. This will allow for management applications to have global vision even when administrative scoping divides the computing environment into disjoint scopes. 10. Core Rules This document uses the following core rules in its grammar definitions: alpha-num = ALPHA / DIGIT / "-" / "." safe-char = as defined in [2] DIGIT = as defined in [7] ALPHA = as defined in [7] HEXDIG = as defined in [7] CHAR = as defined in [7] 11. Vendor Strings In order to allow programmatic searching on the vendor attribute, there must be a convention for representing vendor strings. Day Expires 6 September 1998 [Page 11]
Internet Draft Systems Management Abstract Service March 1998 To illustrate the problem, imagine a vendor attribute is registered as follows: "vendor=Acme Widgets, Limited" Subsequently, three separate service requests are issued: (1) SrvRqst: "vendor=Acme" (2) SrvRqst: "vendor=Acme Ltd." (3) SrvRqst: "vendor=Acme Widgets, Limited" Only the third request above will succeed. One solution to this problem is to have a list of allowable values for vendor names. However, this is unrealistic because it limits vendors to a predefined small set. The better solution is to use a simple convention for representing vendor names: Vendor names SHOULD be represented by using the proper or trademarked name of the vendor with no embellishments. For example: Sun Microsystems, Wind River Systems, International Business Machines, Amazon.com, Digital Equipment Corporation, Hewlett-Packard The convention is to omit qualifiers such as "Inc.," "Ltd.," and so on, unless those qualifiers are part of the vendors trademarked or proper name. While this convention is not foolproof, it should allow programmatic matching of vendors in almost all cases. 12. Acknowledgments This document benefited from the insights and work of Andrea Westerinen, John Keith, John Kilfoil. Erik Guttman was a contributing author of the systems management templates. Day Expires 6 September 1998 [Page 12]
Internet Draft Systems Management Abstract Service March 1998 13. References Request For Comments (RFC) and Internet Drafts documents are available from <URL:ftp://ftp.internic.net> and numerous mirror sites [1] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol version 2.02," Internet Draft (work in progress), January 1998. [2] C. Perkins, E. Guttman, J. Kempf, "Service Tem- plates and 'service:' Schemes, version 7" Internet Draft (work in progress), February 1998. [3] P. Leach, R. Salz, "UUIDs and GUIDs" Internet Draft (work in progress), February 1998. [4] Desktop Management Interface Specification 2.0 - http://www.dmtf.org/ [5] Desktop Management Task Force, "Common Information Model Specification," version 2.0e, December 1997. http://www.dmtf.org [6] T. Berners-Lee, R. Fielding, and L. Masinter, "Uni- form Resource Locators (URL): Generic Syntax and Semantics," RFC1738 as amended by RFC1808 and updated by draft-fielding-url-syntax-09.txt, May 1997. (work in progress). [7] D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 2234, November 1997. 14. Author's address Michael Day Intel 734 East Utah Valley Drive, ste. 300 American Fork, UT 84003 USA Phone: +1 801 763-2341 Fax: +1 801 756-8349 EMail: michael.day@intel.com Day Expires 24 August 1998 [Page 13]
