Service Location Working Group Michael Day INTERNET DRAFT Intel 15 January 1998 The Systems Management Abstract Service Type draft-ietf-svrloc-sysman-00.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), and ''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 30 June 1998 [Page 1]
Internet Draft Systems Management Abstract Service January 1998 2. The "sysman" Abstract Service ---------------------------template begins here----------------------- type = 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) snmpurl = url as defined in [2] ---------------------------template ends here------------------------- 3. 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 = host version = 0.0 language = en description = The "host" concrete service type provides information immediately relevant to the management of a desktop or host computer. Day Expires 30 June 1998 [Page 2]
Internet Draft Systems Management Abstract Service January 1998 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 ; 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. 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. Day Expires 30 June 1998 [Page 3]
Internet Draft Systems Management Abstract Service January 1998 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. 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. ---------------------------template ends here------------------------- 4. 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) [3]. The service:sysman:dmi service template is as follows: ---------------------------template begins here----------------------- type = dmi version = 0.0 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 Day Expires 30 June 1998 [Page 4]
Internet Draft Systems Management Abstract Service January 1998 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. 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 DCE # 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 # The access-point attribute is optional. It signifies the binding # access point of the service provider's remote interface; e.g., # "TCP/IP" or "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 Day Expires 30 June 1998 [Page 5]
Internet Draft Systems Management Abstract Service January 1998 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. ---------------------------template ends here------------------------- 5. The CIM Service Type The "cim" service type provides information about the computer's support of the Common Information Model (CIM)[4]. CIM is a schema description languate, meta-schema, and core schema published by the Desktop Management Task Force [4]. The service:sysman:cim service template is as follows: ---------------------------template begins here----------------------- type = 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. Day Expires 30 June 1998 [Page 6]
Internet Draft Systems Management Abstract Service January 1998 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. 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." Day Expires 30 June 1998 [Page 7]
Internet Draft Systems Management Abstract Service January 1998 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." 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. ---------------------------template ends here------------------------- 6. The SNMP Service Type The "snmp" service type provides information about the Simple Network Management Protocol services that are supported by the computer. The concrete snmp service template used by the "sysman" abstract type is defined in section A.3 of [2]. 7. 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]. 8. 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 [8] ALPHA = as defined in [8] HEXDIG = as defined in [8] CHAR = as defined in [8] 9. Vendor Strings In order to allow programmatic searching on the vendor attribute, there must be a convention for representing vendor strings. To illustrate the problem, imagine a vendor attribute is registered as follows: "vendor=Acme Widgets, Limited" Day Expires 30 June 1998 [Page 8]
Internet Draft Systems Management Abstract Service January 1998 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. 10. Acknowledgments This document benefited from the insights and work of Andrea Westerinen, John Keith, John Kilfoil, and Erik Guttman. 11. 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 6" Internet Draft (work in progress), November. [3] Desktop Management Interface Specification 2.0 - http://www.dmtf.org/ Day Expires 30 June 1998 [Page 9]
Internet Draft Systems Management Abstract Service January 1998 [4] Desktop Management Task Force, "Common Information Model Specification," version 2.0e, December 1997. http://www.dmtf.org [5] 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). [6] D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 2234, November 1997. 12. 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@ccm.ut.intel.com Day Expires 30 June 1998 [Page 10]
