idnits 2.17.1 draft-guttman-svrloc-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** 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. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 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 228: '... and DAAdvert. is a SHOULD (as...' RFC 2119 keyword, line 273: '...SO subtags MAY the entire ...' RFC 2119 keyword, line 308: '...dition SLPv2 SAs MUST restrict themsel...' RFC 2119 keyword, line 329: '... - New DAs MUST support old feature...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 116 has weird spacing: '...Pv1 DAs tio...' == Line 117 has weird spacing: '...rom all tion...' == Line 131 has weird spacing: '...y be of are...' == Line 150 has weird spacing: '... in the acte...' == Line 154 has weird spacing: '...ticator aut...' == (18 more instances...) -- 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 (December 18, 2001) is 8164 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2165' is mentioned on line 43, but not defined == Missing Reference: 'RFC2608' is mentioned on line 45, but not defined == Missing Reference: 'AAA' is mentioned on line 334, but not defined == Missing Reference: 'TRIP' is mentioned on line 334, but not defined == Missing Reference: 'RFC2609' is mentioned on line 342, but not defined == Missing Reference: 'RFC2610' is mentioned on line 348, but not defined == Missing Reference: 'RFC2610bis' is mentioned on line 352, but not defined == Unused Reference: 'DIAMETER' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'IPTEL' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC 2608' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC 2609' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC 2610' is defined on line 435, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DIAMETER' -- Possible downref: Non-RFC (?) normative reference: ref. 'DMTF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPTEL' -- Possible downref: Non-RFC (?) normative reference: ref. 'JSR' == Outdated reference: A later version (-02) exists of draft-guttman-svrloc-rfc2608bis-01 -- Possible downref: Normative reference to a draft: ref. 'RFC2608bis' ** Downref: Normative reference to an Informational RFC: RFC 2614 ** Downref: Normative reference to an Informational RFC: RFC 2926 ** Downref: Normative reference to an Experimental RFC: RFC 3082 (ref. 'RFC3089') ** Downref: Normative reference to an Experimental RFC: RFC 3105 -- Possible downref: Non-RFC (?) normative reference: ref. 'SALUTATION' Summary: 12 errors (**), 0 flaws (~~), 23 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Erik Guttman 3 INTERNET DRAFT 4 Category: Standards Track 5 December 18, 2001 6 Expires in six months 8 Applicability Statement for 9 Service Location Protocol, Version 2 10 draft-guttman-svrloc-as-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Comments on this document should be sent to the SLP discussion list, 18 srvloc-discuss@lists.sourceforge.net. 20 Internet-Drafts are draft documents of the Internet Engineering Task 21 valid for a maximum of six months and may be updated, replaced, or 22 obsoleted by other documents at any time. It is inappropriate to use 23 Internet-Drafts as reference material or to cite them other than as 24 "work in progress." See http://www.ietf.org/ietf/1id-abstracts.txt. 25 Find shadow directories at http://www.ietf.org/shadow.html. 27 Copyright (C) The Internet Society (2001). All Rights Reserved. 29 Abstract 31 The Service Location Protocol provides a scalable framework for the 32 discovery and selection of network services. Using this protocol, 33 computers using the Internet need little or no static configuration 34 of network services for network based applications. This document 35 describes the domain for which the protocol applies, in short 36 networks under a common administration, compatibility issues among 37 different versions of the protocol and provides an overview to the 38 various IETF documents which concern the use of SLP. 40 1. Introduction 42 The Service Location Protocol has been published in three successive 43 versions. Service Location Protocol, Version 1 (SLPv1) [RFC2165] 44 contained excessive functionality, unclear language and errors. 45 Service Location Protocol, Version 2 (SLPv2) [RFC2608] broke binary 46 comptibility with this version of the protocol while retaining the 47 basic mechanisms and data elements. SLPv2 was designed have limited 48 compatibility with SLPv1 through the use of DAs which support both 49 protocols. 51 Significant implementation and deployment experience has informed the 52 current effort to revise SLPv2 so as to remove features which have 53 not been found essential or easy to understand. 55 2. Domain of Applicability 57 SLP is intended to function within networks under cooperative 58 administrative control. Such networks permit a policy to be 59 implemented regarding security, multicast routing and organization of 60 services and clients into groups which are not be feasible on the 61 scale of the Internet as a whole. 63 SLP has been designed to serve enterprise networks with shared 64 services, and it may not necessarily scale for wide-area service 65 discovery throughout the global Internet, or in networks where there 66 are hundreds of thousands of clients or tens of thousands of 67 services. 69 3. Backwards Compatibility 71 The Service Location Protocol has been published in two preceding 72 versions as a proposed standard: SLPv1 [RFC 2165] and SLPv2 [RFC 73 2608]. 75 SLPv1 contained certain errors and features which deployment 76 experience and interoperability testing showed required significant 77 revision. SLPv2 breaks binary compatibility with SLPv1. The basic 78 protocol operations are very similar. DAs have been successfully 79 produced which support both SLPv1 and SLPv2, provided that certain 80 features of SLPv1 are not used. 82 The current revision of SLPv2 retains binary compatibility, but does 83 deprecate some features. This has been done carefully to retain 84 investment in SLPv2 agents even while transitioning to SLPv2bis. 86 - Preserve investment in existing SLPv2 SAs and DAs 87 SLPv2 SAs and DAs implement a superset of the features of 88 SLPv2bis. There is therefore no reason to upgrade existing, 89 deployed SLPv2 DAs and SAs in order to interoperate with newly 90 deployed SLPv2bis agents. 92 - SLPv2bis reduces requirements on SAs 93 Many features of SLP have not proven essential for service 94 discovery. An important use of SLP is in embedded servers for 95 which the minimum feature set is critical given limited server 96 resources. 98 - SLPv2 UAs are compatible with SLPv2bis SAs if properly used 99 SLPv2 UAs implement a superset of functions supported by SLPv2bis 100 SAs. As long as UAs restrict their queries to those supported by 101 SLPv2bis, the UA can obtain the same answer from both SLPv2 and 102 SLPv2bis SAs. 104 3.1 Incompatibility Matrix 106 Incompatibility SLPv1 SLPv2 SLPv2bis 107 --------------- ---------------- ---------------- ------------------ 108 1) Unscoped Agents treat un- Treat unscoped As SLPv2 109 SLPv1 scoped as match- requests as 110 Requests ing all scopes. having 'DEFAULT' 111 scope. Recon- 112 figure SLPv1 UAs 113 if possible! 115 2) Unscoped Accept registra- SLPv2 DAs accept As SLPv2 116 SLPv1 DAs tions and re- only registra- 117 quests from all tions with >0 118 scopes. DA scopes. Re- 119 configure SLPv1 120 SAs if possible! 122 3) Language Tags may be only Tags may be 2 or As SLPv2 123 Tag Length 2 bytes long. more characters. 124 If >2 characters 125 SLPv1 UAs will 126 be unable to 127 discover those 128 services. 130 4) Service Service types Abstract types As SLPv2 131 Types may only be of are allowed, as 132 the form 'service:x:y'. 133 'service:x' or These cannot be 134 'x'. ??? returned to 135 SLPv1 UAs. 137 5) Message SLPv1 header. SLPv2 header. Exactly as SLPv2. 138 Header Not compatible. 140 6) Monolingual If not set, No monolingual As SLPv2. 141 bit complicated bit support 142 rules apply exists in SLPV2. 143 toward ignoring 144 language tag 145 matching for 146 queries. 148 7) Character Character SLPv2 supports As SLPv2. 149 Encoding encoding is the UTF-8 char- 150 explicit in the acter set only. 151 SLPv1 header. 153 8) URL auth- Indicates a URL This flag is not The flag is not 154 enticator auth block supported. 0 or supported. Auth 155 flag follows. more auth blocks blocks are not 156 supported. supported at all. 158 9) Attribute Indicates an The flag is not The flag is not 159 Authentica- attribute auth- supported. 0 or supported. Attr 160 tor flag enticator block more auth blocks auth blocks are 161 follows. may follow not supported. 162 attributes. 164 10) Dialect Reserved. Set SLPv2 has no Exactly as SLPv2. 165 field to 0. dialect field. 167 11) Multicast This flag is not This flag indi- As SLPv2. 168 Flag present in SLPv1 cates rules to 169 follow in the 170 case of an error 171 or zero results 172 (do not reply). 174 12) Fresh Flag When this flag When this flag FRESH flag must be 175 is present in a is present in a set, overwriting 176 SrvAck, DA tells SrvReg, the reg- existing regs with 177 the SA a SrvReg istration over- the same URL (in 178 is new, not wri- writes existing the same language). 179 ting over an ex- registrations If not set, the 180 isting entry. with the same result is the 181 URL. When ab- INVALID_UPDATE 182 sent, reg adds error. 183 incrementally to 184 existing regs. 186 13) Use of XID XID in unsol- XID is set to 0 As SLPv2. 187 icited DAAdverts for unsolicited 188 are used to in- DAAdverts. 189 dicate DA reboot Otherwise XIDs 190 state. are nonzero. 192 Incompatibility SLPv1 SLPv2 SLPv2bis 193 --------------- ---------------- ---------------- ------------------ 195 14) Messsage SLPv1 defines SLPv2 redefines Exactly as SLPv2. 196 Formats formats for all message 197 framing of formats. 198 messages. 200 15) Error Codes Defines 0-7 Adds 9-15 No longer send 5-7 201 as these concern 202 SLP authentication 204 16) Authentica- Algorithms are All algorithms No algorithms are 205 tion blocks defined for redefined for defined for cal- 206 calculation of calculation of culation of 207 digests. digests. digests. 209 17) Search SLPv1 defines a SLPv2 redefines SLPv2bis uses only 210 filters search filter search filter: a proper subset of 211 format, combin- use LDAPv3 fil- LDAPv3 search fil- 212 ing service type ters, without ters (which simp- 213 scope and filter extensible lifies SA implem- 214 matching rules. entation). 216 18) Scope as an SLPv1 defines SLPv2 defines As SLPv2. 217 Attribute scope as an scope separately 218 attribute of a as a modifier to 219 service. SLPv2 messages. 221 19) Reserved SLPv1 reserves SLPv2 does not As SLPv2. 222 strings SCOPE, SERVICE, reserve any 223 LOCAL, REMOTE, words. 224 TRUE and FALSE 226 20) Required SLPv1 requires UA send SrvRqst, As SLPv2 but 227 messages all messages. receive SrvRply AttrRqst/AttrRply 228 and DAAdvert. is a SHOULD (as 229 SA send SrvReg, most applications 230 SrvRply and SA- of SLP require 231 Advert, receive attributes). 232 SrvRqst, DA- 233 Advert & SrvAck. 234 DAs: no options. 236 21) Authentic- Use protected Use SLP SPIs, a Do not use SLP 237 tion scope config- separate field authentication. 238 uration. in messages. Omit SLP SPIs! 240 22) Multicast Use global Use one Admin As SLPv2. 241 group scope group(s), relative address 242 some never except for SLPv2 243 defined! for IPv6. 245 23) Wildcards Attribute re- As SLPv1. SLPv2bis does not 246 in attri- quests allow support wildcards 247 bute lists wildcards to be in tag lists of 248 the tag list. AttrRqst messages. 250 24) Attribute AttrRqst allows As SLPv1. SLPv2bis does not 251 Request by request for all support AttrRqst 252 service attributes of by service type. 253 type services of a Only AttrRqst by 254 given service service URL is 255 type. supported. 257 25) Scope Priority order Priority order A new, simplified, 258 configura- is given, but is given, but priority order is 259 tion rules not clear. very complex defined. Relies 260 because of RFC on fixes to RFC 261 2610 'MANDATORY' 2610. 262 flag, which is 263 not clear. 265 26) Elide Initial and As SLPv1. All strings are 266 spaces final spaces matched as is. 267 in strings are String matches 268 elided in all fail if messages 269 string fields. include extra 270 spaces. 272 27) Language SLPv1 presents SLPv2 states SLPv2bis states 273 Tag match only an ISO subtags MAY the entire tag 274 636 tag. be ignored. must match (with 275 case insensitive 276 matching). 278 3.2 Requirements for SLPv2 UAs to interoperate with SLPv2bis 280 In order to guarantee interoperability into the future, SLPv2bis UAs 281 will use a new API which do not expose features which have been 282 deprecated in SLPv2. 284 SLPv2 UAs have to restrict their use of certain feature which are 285 exposed, or they will only get results if there is a DA which 286 supports those features present in the network, or SAs with full 287 SLPv2 support. 289 These features include: 291 1. Do not use language tags with subtags unless that is really 292 desired. Note that English "en" does not match British English 293 "en-BR". Use 'en' if possible to represent English. 295 2. Send Attribute Requests by URL only (not by service type). 297 3. Do not include wildcards in tag lists in Attribute Requests. 299 4. Send only 'simple' search filters (no logical OR or NOT, only a 300 single comparison term or a conjoined list of comparison 301 terms.) 303 5. Do not be lazy about preceding and trailing white space. Only 304 include it in requests if it should be there. 306 6. Do not expect Authentication Blocks or SLP SPI strings. 308 In addition SLPv2 SAs MUST restrict themselves in the following ways: 310 1. Always set FRESH bit on registration. 312 2. Do not use language tags with subtags unless that is really 313 desired. Note that English 'en' does not match British English 314 "en-BR". Use 'en' if possible to represent English. 316 3. Do not send tag lists in SrvDereg messages. 318 4. Do not be lazy about preceding and trailing white space. Only 319 include it in attribute lists, for example, if it should be 320 there. 322 5. Do not send Authentication Blocks or SLP SPI strings. 324 3.3 Subtleties and Gotchas 326 The following topics need to be considered: 328 - Apps may require complex search filters. Describe options. 329 - New DAs MUST support old features. Specify them. 331 4. Other Documents Concerning SLP 333 Several IETFT working groups have defined ways to use SLP to 334 discover services. [AAA] [TRIP] [RFC3105] [RFC3049] [IPS] 336 External standards organizations and consortia are also specifying 337 how to use SLP. [SALUTATION] [IEEE] [DMTF] 339 The following RFCs augment the base SLPv2bis protocol 340 [RFC2608bis]: 342 [RFC2609] "Service Templates and service: schemes" - Standards 343 Track 344 Defines the Service: URL scheme and how to define and use 345 service templates. Service templates allow interoperability 346 through the use of common registered descriptions of services. 348 [RFC2610] "DHCP Options for Service Location" - Standards Track 349 DHCP option 78 configures SLP agents with DA addresses. Option 350 79 configures a SLP agent with a scope list. Note that this 351 document has been revised for republication, correcting some 352 errors found in the current document. [RFC2610bis] 354 [RFC2614] "An API for Service Location" - Informational 355 This document describes an abstract, C and Java API to expose 356 the functions of SLP to applications in a well known, protable 357 manner. This document will be revised to accomodate change in 358 SLPv2. The Java portion of the document will be published 359 externally as part of a JSR [JSR]. 361 [RFC2926] "Conversion of LDAP Schema to and from SLP Templates" - 362 Informational 363 This document describes conversion of schema to templates or 364 the reverse. 366 [RFC3059] "Attribute List Extension for the Service Location 367 Protocol" - Standards Track 368 This extension allows a UA to obtain the list of attributes 369 associated with a service advertisement in a SrvRply message. 370 This saves an extra round trip (AttrRqst/AttrRply) and elimates 371 a potential race condition where a service is discovered but 372 its attributes change or it is deregistered before its 373 attributes can be obtained. 375 [RFC3089] "Notification and Subscription for SLP" - Experimental 376 This mechanism allows scalable dynamic discovery of services, 377 through the use of multicast announcements in the form of 378 SrvReg messages, if there are subscribers. 380 [RFC3111] "SLPv2 Modifications for IPv6" - Standards Track 381 This document describes the few change in SLPv2 which are 382 required to support the protocol over IPv6. 384 [VENDOR] 385 This document updates SLPv2, describing the vendor extension 386 mechanisms. These provide an open ended set of practices which 387 will not generate name collisions in the future (so they are 388 safe). At the same time, this approach will not lead to 389 interoperability, so it is discouraged. 391 5. Security Considerations 393 This document describes the relation between different versions of 394 SLP. Where security features of the protocol have changed, this 395 has been noted. The most important 397 6. Acknowledgements 399 The author wishes to thank the contributions through the years of 400 the SVRLOC WG and the SRVLOC discussion list. I am grateful to my 401 employers who have supported this work: FTP Software, Peer Logic, 402 Oracle and Sun Microsystems. 404 References 406 [DIAMETER] 408 [DMTF] 410 [IANA] http://www.iana.org/numbers.html 412 [IEEE] 414 [IPS] 416 [IPTEL] 418 [JSR] 420 [mSLP] 422 [RFC 2165] Veizades, et. al, "Service Location Protocol", RFC 2165, July 423 1997. 425 [RFC 2608] E. Guttman, et. al, "Service Location Protocol version 2", 426 RFC 2608, June 1999. 428 [RFC2608bis] Guttman, E, Kempf, J., "Service Location Protocol, Version 429 2", draft-guttman-svrloc-rfc2608bis-01.txt, December 2001, a 430 work in progress. 432 [RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and 433 service: Schemes", RFC 2609, June 1999. 435 [RFC 2610] Perkins, C., Guttman, E., "DHCP Options for Service 436 Location", RFC 2610, June 1999. 438 [RFC 2610bis] Guttman, E., "DHCP Options for Service Location", draft- 439 guttman-svrloc-rfc2610bis-01.txt, September 2001. A work in 440 progress. 442 [RFC2614] Kempf, J., Guttman, E., "An API for Service Location", RFC 443 2614, June 1999. 445 [RFC2926] Kempf, J., et. al. "Conversion of LDAP Schema to and from SLP 446 Templates", RFC 2926, September 2000. 448 [RFC3049] Naugle, J., et. al., "TN3270E Service Location and Session 449 Balancing", RFC 3049, January 2001. 451 [RFC3059] Guttman, E., "Attribute List Extension for the Service 452 Location Protocol", RFC 3059, February 2001. 454 [RFC3089] Kempf, J., Goldschmidt, J., "Notification and Subscription for 455 SLP", RFC 3082, March 2001. 457 [RFC3105] Kempf, J., Montenegro, G., "Finding an RSIP Server with SLP", 458 RFC 3105, October 2001. 460 [RFC3111] Guttman, E., "SLPv2 Modifications for IPv6", RFC 3111, May 461 2001. 463 [SALUTATION] 465 [VENDOR] Guttman, E., "Vendor Extensions for SLPv2", draft-guttman- 466 svrloc-vendor-ext-07.txt, a work in progress. 468 Author's Contact Information 470 Erik Guttman 471 Sun Microsystems 472 Eichhoelzelstr. 7 473 74915 Waibstadt Germany 475 erik.guttman@sun.com