Editor's note: These minutes have not been edited. Mintes for the SVRLOC WG at the 37'th IETF Erik Guttman was made the cochair of the SVRLOC WG. We discussed the status of the latest draft of the Service Location Protocol (draft-ietf-svrloc-protocol-15.txt). It was felt by the IESG that there were sufficient changes that the draft must pass through last call again before going forward. It was also thought that the changes were well motivated, so we should take this step rather than going forward with draft 14. The bake off results were discussed. There are currently five implementations: Sun, Novell, IBM, and two independent ones, by a former student of the ENST Paris and a Linux based implementation which will go into the public domain soon. The bake offs were successful, particularly the better attended first bake off. There interoperability of all major functions was demonstrated, though some of the implementations lacked some of the required features (like attribute query selection for one and Service Type requests for another.) Directory Agents will become available shortly, connected to the internet, for on line interoperability testing. Details will be posted on a new SLP web site. Mailing list archives and information will be made available at this web site and an announcement of its availability will be posted to the mailing list. Two additional WG drafts have appeared recently; draft-ietf-svrloc-api-00.txt draft-ietf-svrloc-service-scheme-00.txt These were discussed, but few attending the meeting had read them. The comments were overall positive (the substantive remarks are summarized below.) It was clear that these must mature before being submitted to the RFC editor. The api will be submitted as an informational RFC when it is ready, while the service scheme document should be considered as a standards track document. API document - It was suggested that we include C++ bindings. The group felt it would be OK to omit the C++ bindings, leave this as an excercise for the reader. - It is important to clarify the refreshHint effects and leave this as an option the admin can overrule. Note that it has severe scaling and network bandwidth effects for a service to reregister with a remote DA every few seconds. - Several APIs include string parameters which must be interpreted. The alternative is to include data structures for these interfaces. Since these strings are basicly the same as are used in SLP, there were no serious objections to leaving the interfaces in their current (string based) form. - There have been many other comments on the mailing list which were not discussed. Service Scheme document - Delimiters in the "record" structured attributes should not be tabs. Semicolons have been suggested as an alternative. - Content descriptions for file services are problematic as they are impossible to create in any automatic way. The issue is that they will be inconsistently applied and quickly become inconsistent with the actual content of file servers. It would be better to limit the content to a text based name or description of contents for general file servers. Specialized (optional) descriptions might be used as a 'hint' for specific things, like installed software, but this should not be assumed to be complete or correct... - It was agreed it would be better to have 'high level' services in the service type name rather than particular protocols. This means that instead of 'lpr' one should have 'printer' with a protocol attribute 'protocol=lpr' for example. This would allow a single URL to represent more than one protocol (say the printer is accessible from multiple protocols.) The charter was discussed. The items in the charter are listed below, together with comments made about them. A new charter will be filed shortly. Status Goal DONE Form WG DONE Define problem 6/96 Define Mail Relay, DNS and Mailbox Service Types - This is satisfied by the service scheme draft: DONE DONE SLP over IPv6 - This is satisified by the IPv6 draft 6/96 SLP over other protocols - There is interest in doing this by the folks at Novell who are implementing SLP. There should be a draft out by 3/97 for this. It may include Appletalk, IPX and OSI network addressing and interoperability issues. - The goal should be pushed to 6/97 for a cleaned up draft of this proposal. 12/96 SLP Authentication - It was mentioned that we are trying to defer this issue to the Security Area rather than trying to create yet another application specific authentication framework. - Were we to do so, it was remarked, the way to do it would be to allow UAs to be configured so that they could determine if registrations were authorized by a certificate authority they implicitely trusted. - This matter should be discussed more on the mailing list. Should a mechanism be found within the protocol to support SLP specific authentication? If so, a new date and milestone must be determined for the charter. 3/97 SLP for finding client resources on a remote network. - There was interest in this proposal by some folks who are also doing Mobile IP. This needs to be pursued actively or removed from the charter. 7/97 Global SLP mechanism - The "Finding Stuff, locating netwoorking services" working draft of the IDS WG has moved to the SLP WG. This draft is already mature, and includes a way of using DNS to deliver service by type for a given domain, for a number of protocols which may provide the service type. Work remains to be done to fit this into the SLP framework but the goal date is quite achievable.