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]