idnits 2.17.1 draft-ietf-svrloc-sysman-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 201: '...ute is optional. It SHOULD be included...' RFC 2119 keyword, line 214: '... Implementations SHOULD use a value fr...' RFC 2119 keyword, line 242: '... computer. There MUST be one mac-addre...' RFC 2119 keyword, line 248: '... # attribute SHOULD contain a name a...' RFC 2119 keyword, line 310: '...te is required, and SHOULD be included...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 March 1998) is 9547 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 627, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Location Working Group Michael Day 3 INTERNET DRAFT Intel 5 6 March 1998 7 The Systems Management Abstract Service Type 8 draft-ietf-svrloc-sysman-02.txt 10 Status of This Memo 12 This document is a submission by the Service Location Working Group 13 of the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the srvloc@corp.home.net mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check 29 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 31 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document presents definitions for the "sysman" (systems 37 management) abstract service, and the "dmi" (desktop management 38 interface), "cim" (common information model), "snmp" (simple network 39 management protocol), and "host" concrete service types. These 40 definitions are suitable for use with the Service Location Protocol 41 [1]. 43 Systems management, as used in this document, relates to the 44 monitoring, diagnosing, service and support of desktop and 45 host computers. 47 1. Introduction 49 Service templates and abstract service types are defined in [2]. The 50 systems management abstract service type is designed to organize 51 information from various services, protocols, and schemas that 52 relate to systems management. 54 2. Using SLP For Network and Systems Management 56 When deploying SLP for purposes of network or systems management, 57 there are some important points to consider. These include ease of 58 administration, having a low impact on the network, and providing SLP 59 support for the entire range of systems on the network. (Note that 60 using SLP to discover managed systems will only find managed systems 61 that support SLP.) 63 Network and systems management applications need to continue working 64 when other network components are broken. Further, management 65 applications frequently need to obtain information that has a 66 very short lifetime. These considerations motivate some of the 67 recommendations that are listed below. 69 The Service Location Protocol can provide a number of applications 70 for network and systems management. For example: 72 - A manager can use SLP to discover managed systems without 73 performing brute-force scanning of the network. 75 - A manager can select manageable systems based on specific 76 attributes, such as support for a specific management protocol, 77 agent, instrumentation group, and software distribution format. 79 - A managed system can use SLP to find its manager(s), to which the 80 managed system can then send traps and issue trouble tickets. 82 - A managed system can use SLP to publish basic information about 83 itself, such as its operating system vendor, type and version; 84 its MAC address(es); operator information; management agent(s) 85 hosted by that system, and so on. 87 - A manager can periodically search for new hosts using SLP. 89 A good strategy to follow when using SLP for manageability includes 90 the following points: 92 - Peer-to-peer implementation. Each managed system, along with 93 each management application, implements UA and SA functionality. 94 The system advertises its management services using the 95 "service:sysman" concrete types. 97 - Bootstrap capability. Each managed system, along with each 98 management application can begin functioning with no knowledge 99 of exisiting manageability services beyond a knowledge of its 100 own UA. For example, a management application can, with no 101 foreknowledge, use SLP to build a list of manageable stations and 102 their basic capabilities. 104 This bootstrap capability requires the use of multicast or 105 broadcast with convergence. Multicasting and broadcasting should 106 be avoided when possible. However, bootstrap capability is a 107 key aspect of systems management. (What happens when the DA is 108 broken and needs to be managed?) Therefore, managers and managed 109 stations should use DAs for discovery when they exist, but must 110 also have the ability to perform multicast or broadcast with 111 convergence. 113 - DAs for support of mobile and occasionally connected stations, as 114 well as for scalability. DAs provide a good way to support the 115 discovery of mobile and occasionally connected systems because 116 they can act as SLP proxies for such systems, which may be 117 connected via a slow link. In addition, DAs provide scalability 118 to SLP. 120 - If the site implments adminstrative domains, it should also 121 implement a management-specific domain. SAs that publish 122 "service:sysman" types should register their information with 123 DAs that are scoped for the management-specific domain. 125 More information on domain scoping for management is in section 126 section 9 below, "Domain Scoping for Manageability. 128 3. The "sysman" Abstract Service 130 ---------------------------template begins here----------------------- 131 type = service:sysman 133 version = 0.0 135 language = en 137 description = 138 The 'service:sysman' abstract service type organizes information 139 from various services, protocols, and schemas that relate to 140 systems management. Systems management, as used in this 141 document, relates to the monitoring, diagnosing, service and 142 support of desktop and host computers. 144 url-syntax = 145 url-path = hosturl / dmiurl / cimurl / snmpurl 146 hosturl = url as defined in "Host Service Type" (below) 147 dmiurl = url as defined in "DMI Service Type" (below) 148 cimurl = url as defined in "CIM Service Type" (below) 149 snmp1url = url as defined in "SNMPv1 Service Type" (below) 151 ---------------------------template ends here------------------------- 153 contact="Erik Guttman" 154 security considerations= 155 Note the security considerations associated with the concrete types 156 defined below. 158 4. The Host Service Type 160 The "host" concrete service type provides information 161 immediately relevant to the management of a desktop or host 162 computer, such as computer's the operating system version and 163 vendor, its physical location, and so on. 165 The service:sysman:host service template is as follows: 167 ---------------------------template begins here----------------------- 168 type = service:sysman:host 170 version = 0.1 172 language = en 174 description = 175 The "host" concrete service type provides information 176 immediately relevant to the management of a desktop or host 177 computer. 179 url syntax= 180 url-path = ([machine-name] os-name os-vendor 181 os-majorverion [os-minorversion] 182 [os-revision] mac-address [contact]) 183 machine-name = ";machine-name =" 1*alpha-num 184 os-name = ";os-name =" 1*alpha-num 185 os-vendor = ";os-vendor =" 1*alpha-num 186 os-majorversion = ";os-major =" 1*DIGIT 187 os-minorversion = ";os-minor =" 1*alpha-num 188 os-revision = ";os-revision =" 1*alpha-num 189 mac-address = ";mac-address =" 12HEXDIG 190 owner = ";owner =" 1*CHAR 191 machine-uuid = ";uuid =" as defined in [3] 192 ;uuid is a 128-bit value, represented 193 ;as a string, that provides a unique 194 ;id to hardware that supports this 195 ;this feature 197 ; the fields beginning with machine-name and ending with 198 ; owner are each defined as an attributed, below. 200 machine-name = string O L 201 # The machine-name attribute is optional. It SHOULD be included 202 # whenever the computer has a network name other than a domain 203 # name. 205 os-name = string L 206 # The os-name attribute is required. It signifies the operating 207 # system running on the computer. Although there is no list of 208 # allowed values, the following values are recommended for their 209 # operating systems: 210 # 211 # (solaris, netware, windows-nt, windows-95, windows, 212 # linux, dos, macos, aix, irix, hpux, bsdi, freebsd) 213 # 214 # Implementations SHOULD use a value from the preceeding list 215 # when representing one of those operating systems. Other values 216 # may be used for other operating systems. 218 os-vendor = string L 219 # The os-vendor attribute is required. It signifies the vendor of 220 # operating system running on the computer. For example, "Sun 221 # Microsystems," "Microsoft," or "Santa Cruz Operation." 222 # 223 # NOTE: There is an important convention for representing 224 # vendor strings. See section 9. 226 os-majorversion = integer L 227 # The os-majorversion attribute is required. It signifies the 228 # major version of the operating system running on the computer. 230 os-minorversion = string O L 231 # The os-minorversion attribute is optional. It signifies the minor 232 # version of the operating system running on the computer. 234 os-revision = string O L 235 # The os-revision attribute is optional. Some vendors use a 236 # revision string to indicate the build of their operating systems, 237 # instead of a version number. 239 mac-address = string M L 240 # The mac-address attribute is required. It is a string 241 # representation of the hexadecimal mac address of each network 242 # card in the computer. There MUST be one mac-address attribute for 243 # each network card in the computer. 245 owner = string O 246 # The owner attribute is optional and presents a human-readable 247 # string containing contact information for the computer. This 248 # attribute SHOULD contain a name and phone number, but MAY contain 249 # other information. 251 machine-uuid = string O L 252 # The machine-uuid attribute is optional. It signifies the machine 253 # UUID or GUID of the host. This value is specific to the machine 254 # itself and not the host operating system nor to any of its 255 # applications. For machines that do not have an embedded UUID, a 256 # software program may generate a machine UUID. 258 ---------------------------template ends here------------------------- 260 contact="Michael Day" 262 security considerations= 263 Free access to computer owner information may present a security 264 risk in some environments. The other information provided by this 265 service type is generally available in most environments. 267 5. The DMI Service Type 269 The "dmi" service type provides information about the computer's 270 support of the Desktop Management Interface (DMI), an 271 instrumentation standard supported by the Desktop Management Task 272 Force (DMTF) [4]. 274 The service:sysman:dmi service template is as follows: 276 ---------------------------template begins here----------------------- 277 type = service:sysman:dmi 279 version = 0.1 281 language = en 283 description = 284 The "dmi" concrete service type provides information the 285 availibility of Desktop Management Interface services on the 286 computer. For information on the desktop management interface, 287 see http://www.dmtf.org 289 url syntax= 290 url-path = (provider vendor provider-major 291 provider-minor [remote-interface] 292 [access-point] [security-level]) 293 provider-vendor = ";vendor = " 1*alpha-num 294 provider-major = ";major =" 1*DIGIT 295 provider-minor = ";minor =" 1*alpha-num 296 remote-interface = ";remote=" 1*ALPHA" 297 access-point = ";access-point =" 1*safe-char 298 security-level = ";security =" 1*safe-char 299 ; The fields beginning with provider-major and ending with 300 ; security-level are defined as attributes, below 302 provider-vendor = string L 303 # The provider-vendor attribute is required. It signifies the 304 # vendor of the DMI service provider running on the computer. 305 # 306 # NOTE: There is an important convention for representing 307 # vendor strings. See section 9. 309 provider-major = integer X 310 # The provider-major attribute is required, and SHOULD be included 311 # in service request predicates. It signifies the major version of 312 # the computer's DMI service provider. Allowable values are as 313 # follows: 314 1, 2 316 provider-minor = string L 317 # The provider-minor attribute is required. It signifies the minor 318 # revision of the computer's DMI service provider. 320 remote-interface = string L O 321 # The remote-interface attribute is optional. It signifies the 322 # network interface to the DMI service provider. Allowable values 323 # are as follows: 325 DCE, ONC, TI, RAP 327 access-point = string L O 328 ncacn_ip_tcp 329 # The access-point attribute is optional. It signifies the binding 330 # access point of the service provider's remote interface. 331 # Allowable values are as follows: 332 ncacn_ip_tcp ; connection-oriented, TCP over IP 333 ncadg_ip_udp, ; datagram, UDP over IP 334 ncacn_nb_tcp, ; connection-oriented, NetBIOS over TCP 335 ncacn_spx, ; connection-oriented, Novell SPX 336 ncadg_ipx ; datagram, Novell IPX 338 security-level = string L O 339 Off 340 # The security-level attribute is optional. It signifies the 341 # security mechanisms that are active with the computer's service 342 # provider. 343 On, Off 345 ---------------------------template ends here------------------------- 347 contact="Michael Day" 349 security considerations= 350 The Desktop Management Interface does not yet have a standard 351 security scheme. Some attributes may not be secured. Information 352 about remote access points to the DMI service provider may 353 present a security risk if the RPC mechanism is not adminstered 354 properly. 356 6. The CIM Service Type 358 The "cim" service type provides information about the computer's 359 support of the Common Information Model (CIM)[5]. CIM is a schema 360 description languate, meta-schema, and core schema published by the 361 Desktop Management Task Force. 363 The service:sysman:cim service template is as follows: 365 ---------------------------template begins here----------------------- 366 type = service:sysman:cim 367 version = 0.0 368 language = en 369 description = 370 The "cim" concrete service type provides information the 371 availibility of Common Information Model services on the computer. 372 For more information see http://www.dmtf.org 374 url syntax= 375 url-path = (cim-major cim-minor cim-revision om-vendor 376 om-major om-minor om-revision 377 [remote-interface] [access-point]) 378 cim-major = ";cim-major =" 1*DIGIT 379 cim-minor = ";cim-minor =" 1*DIGIT 380 cim-revision = ";cim-revision =" 1*alpha-num 381 om-vendor = ";om-vendor =" 1*alpha-num 382 om-major = ";om-major =" 1*DIGIT 383 om-minor = ";om-minor =" 1*DIGIT 384 om-revision = ";om-revision =" 1*alpha-num 385 remote-interface= ";remote =" 1*alpha-num 386 access-point = ";access-point =" 1*safe-char 387 ; The fields beginning with cim-major and ending with 388 ; access-point defined as attributes, below. 390 cim-major = integer X 391 # The cim-major attribute is required and signifies the major 392 # version of the Common Information Model Schema Description 393 # Language that is supported on the computer. This attribute SHOULD 394 # be included in service request predicates. Allowable values are 395 # as follows: 396 1, 2 398 cim-minor = integer X 399 # The cim-minor attribute is required and signifies the minor 400 # version of the Common Information Model Schema Description 401 # Language that is supported on this computer. This attribute SHOULD 402 # be included in service request predicates. 404 cim-revision = string L X 405 # The cim-revision attribute is required and signifies the 406 # revision of the Common Information Model Schema Description 407 # Language that is supported on this computer. This attribute 408 # SHOULD be included in service request predicates. 410 om-vendor = string L X 411 # The om-vendor attribute is required and signifies the vendor of 412 # the CIM object manager (CIMOM) that is present on the computer. 413 # This attribute SHOULD be included in service request predicates. 414 # 415 # NOTE: There is an important convention for representing 416 # vendor strings. See section 9. 418 om-major = integer X 419 # The om-major attribute is required and signifies the major 420 # version of the CIM object manager (CIMOM) that is supported on the 421 # computer. This attribute SHOULD be included in service request 422 # predicates. 424 om-minor = integer X 425 # The om-minor attribute is required and signifies the minor 426 # version of the CIM object manager (CIMOM) that is supported on the 427 # computer. This attribute SHOULD be included in service request 428 # predicates. 430 om-revision = string L 431 # The om-minor attribute is required and signifies the revision 432 # version of the CIM object manager (CIMOM) that is supported on the 433 # computer. 435 remote-interface = string L O 436 # The remote-interface attribute is optional and signifies the 437 # network interface to the CIM object manager (CIMOM). Examples 438 # of expected values include be "DCE-RPC, "IIOP," or "DCOM." 440 access-point = string L O 441 # The access-point attribute is optional and signifies the network 442 # service access point to the CIM object manager (CIMOM). Examples 443 # of expected values include "TCP/IP," and "IPX." 445 ---------------------------template ends here------------------------- 447 contact="Michael Day" 449 security considerations= 450 CIM security is derived from the CIMOM and the attributes defined 451 in the CIM schema being accessed. Adminstrators should take care to 452 understand the security attributes of the CIM schemas and the 453 characteristics o their CIMOM before publishing information about 454 remote access to CIM data. 456 7. The SNMPv1 Service Type 458 The "snmpv1" service type provides information about Simple Network 459 Management Protocol version 1 services that are supported by the 460 computer. 462 The service:sysman:snmpv1 service template is as follows: 464 -------------------------template begins here----------------------- 465 type=service:sysman:snmpv1 466 version=0.0 467 lang=en 469 description= 470 The 'service:sysman:SNMPv1:' URL provides information about the 471 SNMPv1 manageability of a given host. Namely, if this URL exists 472 for a host (denoted by the in the URL,) the host 473 supports SNMPv1. 475 url-syntax= 476 url-path = ( [port-list] [comm-string] [oid-list]) 477 ; None of the attributes listed in the URL path 478 ; are required. They MAY be included. 479 port-list = ";ports=" port-list 480 ports = port / port "," ports 481 ; See the Service URL production rule. 482 ; This field is defined as an attribute, below. 483 comm-string = ";read-community-string=" 1*uchar 484 ; See the Service URL production rule. 485 ; This field is defined as an attribute, below. 487 ports=integer M L O 488 161 489 # This attribute must be included if the service:URL does not 490 # contain transport protocol information. It lists all UDP ports on 491 # which SNMP Agents are listening. 493 read-community-string=string L O 494 # The read community string may be included as an attribute of 495 # a service:network-managment:snmp: URL. This is useful in 496 # cases where the community string is PUBLIC and ease of access 497 # to the SNMP Agent is desired. See the 'security considerations.' 499 --------------------------template ends here------------------------ 501 contact="Erik Guttman" 503 security considerations= 504 The read-community-string MUST only be included if the value 505 of this string is considered to be public. If this attribute 506 is included, absolutely anyone may access the SNMP Agent and 507 get information from it. This may be desirable in some cases. 508 If this string is considered confidential information, the 509 read-community-string MUST NOT be included in the URL path 510 nor in service registrations of the URL made through SLP or 511 other protocols. 513 8. Other Security Considerations 515 In addition to specific security considerations list above, each of 516 these service types inherit the security considerations of the 517 "service:" URL scheme as specified in [2]. 519 9. Domain Scoping for Manageability 521 When a site activates SLP administrative scoping, this can cause 522 problems for management applications that use SLP for discovery. 524 The problems are associated with visibility of published services. 525 Specifically, if a management application is not part of an 526 administrative scope, it will not be able to discover management 527 services that are within that scope. 529 Management applications sometimes have a peculiar need to "see" and 530 "hear" everything that exists in a computing environment, and this 531 need extends to service location. 533 Therefore, whenever SLP administrative scoping is in place, there 534 should also be a service-specific scope established for the 535 "service:sysman" type, for example "systems-management". 537 With a systems-management scope in place, all UAs and SAs that 538 support the "service:sysman" type will need to be configured to 539 use that scope to advertise and discover management services. SLP 540 supports scope lists, meaning that UAs and SAs can be members of 541 more than one scope. In addition, the SLP DHCP discovery options 542 will support an optional scope list. 544 This will allow for management applications to have global vision 545 even when administrative scoping divides the computing environment 546 into disjoint scopes. 548 10. Core Rules 549 This document uses the following core rules in its grammar 550 definitions: 552 alpha-num = ALPHA / DIGIT / "-" / "." 553 safe-char = as defined in [2] 554 DIGIT = as defined in [7] 555 ALPHA = as defined in [7] 556 HEXDIG = as defined in [7] 557 CHAR = as defined in [7] 559 11. Vendor Strings 561 In order to allow programmatic searching on the vendor attribute, 562 there must be a convention for representing vendor strings. 564 To illustrate the problem, imagine a vendor attribute is registered 565 as follows: 567 "vendor=Acme Widgets, Limited" 569 Subsequently, three separate service requests are issued: 571 (1) SrvRqst: "vendor=Acme" 572 (2) SrvRqst: "vendor=Acme Ltd." 573 (3) SrvRqst: "vendor=Acme Widgets, Limited" 575 Only the third request above will succeed. 577 One solution to this problem is to have a list of allowable values 578 for vendor names. However, this is unrealistic because it limits 579 vendors to a predefined small set. 581 The better solution is to use a simple convention for representing 582 vendor names: 584 Vendor names SHOULD be represented by using the proper or 585 trademarked name of the vendor with no embellishments. 587 For example: 589 Sun Microsystems, Wind River Systems, 590 International Business Machines, Amazon.com, 591 Digital Equipment Corporation, Hewlett-Packard 593 The convention is to omit qualifiers such as "Inc.," "Ltd.," 594 and so on, unless those qualifiers are part of the vendors 595 trademarked or proper name. While this convention is not 596 foolproof, it should allow programmatic matching of vendors 597 in almost all cases. 599 12. Acknowledgments 600 This document benefited from the insights and work of Andrea 601 Westerinen, John Keith, John Kilfoil. Erik Guttman was a contributing 602 author of the systems management templates. 604 13. References 606 Request For Comments (RFC) and Internet Drafts documents are 607 available from and numerous mirror sites 609 [1] E. Guttman, C. Perkins, J. Veizades, M. Day, 610 "Service Location Protocol version 2.02," Internet 611 Draft (work in progress), January 1998. 613 [2] C. Perkins, E. Guttman, J. Kempf, "Service Tem- 614 plates and 'service:' Schemes, version 7" Internet 615 Draft (work in progress), February 1998. 617 [3] P. Leach, R. Salz, "UUIDs and GUIDs" Internet Draft 618 (work in progress), February 1998. 620 [4] Desktop Management Interface Specification 2.0 - 621 http://www.dmtf.org/ 623 [5] Desktop Management Task Force, "Common Information 624 Model Specification," version 2.0e, December 1997. 625 http://www.dmtf.org 627 [6] T. Berners-Lee, R. Fielding, and L. Masinter, "Uni- 628 form Resource Locators (URL): Generic Syntax and 629 Semantics," RFC1738 as amended by RFC1808 and 630 updated by draft-fielding-url-syntax-09.txt, May 631 1997. (work in progress). 633 [7] D. Crocker and P. Overell. Augmented BNF for 634 Syntax Specifications: ABNF. RFC 2234, November 635 1997. 637 14. Author's address 639 Michael Day 640 Intel 641 734 East Utah Valley Drive, ste. 300 642 American Fork, UT 84003 643 USA 645 Phone: +1 801 763-2341 646 Fax: +1 801 756-8349 647 EMail: michael.day@intel.com