One document matched: draft-ietf-svrloc-sysman-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:05:56 |