NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
John Veizades <email@example.com>
Erik Guttman <firstname.lastname@example.org>
Internet Area Director(s):
Jeffrey Burgan <email@example.com>
Thomas Narten <firstname.lastname@example.org>
Internet Area Advisor:
Thomas Narten <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
Description of Working Group:
The Service Location Protocol is a decentralized, lightweight, scalable and extensible protocol for service discovery within a site. It allows but does not require centralized administration. Even when security, administrative policies or convenience require centralization (say in large enterprise deployments) the protocol requires very little administration. The protocol limits its use of multicast and broadcast as much as possible to conserve network bandwidth. Moreover, the protocol is extensible to arbitrary service advertisement and discovery and supports multiple languages and character set encodings.
The working group will document procedures for discovering services, and standardize "service:" schemes, which are definitions for resource and service URLs.
The focus of the working group will be on completing various documents that describe how to do service discovery and how to standardize service definitions which will be advertised and discovered.
· Interactions between Service Location Protocol and other enterprise naming and directory service protocols will be explored, defined, and standardized.
· Schemes for popular services will be discussed, and standardization efforts with other working groups explored as needed.
· Operational experiences and security procedures will be discussed and documented as best current practice.
· Service Type attribute definitions will be standardized by registering a 'Service Template' with IANA. This document will also describe how Service Types and Directory Schemas can be made interoperable. The Service Location Protocol can then be used to populate a directory service dynamically.
· An Application Programmers Interface has been developed to allow a uniform mechanism for applications to make use of Service Location Protocol functions, which will be supplied as an informational document.
· The Service Location Protocol itself will be revised and improved on, continuing it along the standards track.
Goals and Milestones:
Open discussion and determine if a working group should be formed.
Continue discussion trying to refine the problem statement and possible resolutions.
Define an authentication mechanism for Service Location.
Define a Service Discovery procedure for use in site as well as internet applications. Also define a mechanism for advertising services using DNS TXT records.
Submit an API for the Service Location Protocol to IESG for consideration as an Informational RFC.
Submit a service: URL and service template definition as an Internet-Draft.
Submit the modifications to SLP for implementing it on IPv6 to IESG for consideration as a Proposed Standard.
Submit a revised I-D of the Service Location Protocol reflecting implementation experience and working group consensus on open issues.
Review the status of the SVRLOC WG. Revise the charter or shut down.
· Finding Stuff (How to discover services)
· Service Location Modifications for IPv6
· Service Templates and service: Schemes
· An API for Service Location
· Advertising Services (Providing information to support service discovery)
· Defining White Pages and Yellow Pages Services
· Wide Area Network Service Location
· Conversion of LDAP Schemas to and from SLP Templates
· Definition of lpr: URLs for use with Service Location
Request For Comments:
Service Location Protocol
Minutes of the Service Location Protocol Working Group Meeting
Reported by Tom Taylor <firstname.lastname@example.org>
Chairman: Erik Guttman, Sun Microsystems
I. Documents from the Working Group (20 minutes)
II. New URL scheme/template draft (15 minutes)
III. Presentation: Wide-Area Service Location (30 minutes)
IV. Registry for templates (5 minutes)
V. Modifications to Service Location Protocol (20 minutes)
VI. New charter, plans (10 minutes)
I. Documents From the Working Group
The WG Chairman reviewed a number of documents produced by the Working Group. He expressed his concern that he had been unable to obtain responses for recent last calls except by direct solicitation, and hoped that this review would help to stimulate more comments.
(a) Service Location Protocol (SLP)
SLP was issued with known areas where it needs improvement. Erik has prepared a list of needed changes and submitted them to the list. The intention is that SLP be recycled quickly with the required updates.
The API document has been reworked and changes added. A draft will be put out within the next month. Sun is using the API, but Erik would like independent confirmation of the document's completeness and usability.
(c) Documents on hand
Draft-ietf-svrloc Contents Status
api-01.txt API document Forthcoming
protocol-17.txt SLP Now RFC 2165
service-scheme-02.txt Service templates Available
wpyp-00.txt White & yellow pages Available
Erik remarked that the white pages service is a particularly difficult test of the template schema. If the white pages service type can be supported, it is a good indication that abstract service types can be supported in the future.
(d) New drafts
lpr-scheme-00.txt Attribute space for printing services
template-conversion-00.txt Maps between SLP templates and directory schemas
wasrv-00.txt Wide area service (more info below)
(e) Last calls
No comments have been received on the list. The proposals concerned are derived from netfind, which is actually well deployed; service URLs are a new syntactic mechanism.
Disposition: one comment from the meeting, and general agreement that the document could proceed to RFC as an experimental protocol.
Erik pointed out issues he saw in the document. First, the "sites" approach does not differ significantly from the straightforward use of SRV records. It is essentially a naming convention for DNS. Second, the "ordering" of the discovery steps is not clear, so there would be no direct way to produce interoperability.
A meeting participant suggested that RMON should also be considered. The drawback to this is that it is a passive mechanism and won't discover inactive services. The suggestion was modified: use RMON to find services, then register them. The same participant also had a proposal to initially populate the registry using a specially prepared DNS. His complete presentation will be supplied to the list.
Disposition: refer discovery back to the list for more work, but it is very close.
Comments have been solicited and received. A new draft will be issued soon. There is very little left to do on this draft.
II. New URL Scheme/Template Draft
RFC 2165 provides URLs and templates for standardized (IANA) service types. The question now is how to add new types.
Erik provided a list of the remaining issues to be worked regarding templates. These issues include:
· clarification of the actions possible on the URL schema: GET, PUT, PROTOCOL, etc.
· coordination with IANA for production registry of templates
· How should the templates be 'vetted', i.e. reviewed for reasonableness and how to do this to avoid the pitfalls of intellectual property and trademarking.
· Final decisions need to be made about how to handle abstract service types.
A member of the audience questioned the service URL syntax, remarking that it had broken his parser. The parser expected a URL of the form service:<data spec>
Instead, RFC 2165 defines the URL as <url> ::= service:<srv type>://<addr spec>
The literal 'service' indicates the URL scheme for service location, and is the top of the name space for that scheme. The Area Director insisted a single top to the tree. The question then is why the term ":<srv type>"? Erik presented several reasons for this, including the ability to use an abstraction for <srv type>.
III. Presentation: Wide-Area Service Location
Presenter: Jonathan Rosenberg
Co-author: H. Shulzrinne
The special focus of the authors was on the location of internet telephony gateways.
SLP locates services in your administrative domain. It may be, however, that you want to locate a service elsewhere, and not necessarily its closest instance. Examples include the internet telephony gateway closest to the final call destination, or web sites for hotels in a given region. Protocol support is needed to do this.
The requirements listed for the wide area service location protocol include scalability, security (responding server authentication and non-repudiation of cost quotations), arbitrary constraints on attribute values, openness, and simplicity. The presenter reviewed current SLP limitations in the light of these requirements. He went on to propose extensions to relieve those limitations. All of these issues are open and were briefly discussed in the course of the WG meeting.
The first proposed extension was to provide for multicast registrations. This implicitly assumes lots of multicast routing support. The specific mechanism would be to map from service to multicast address, so that service registrations get sent to multicast groups. An issue was identified: Directory Agent billing for registration, versus reliability of multicast registration.
Scalability of this multicast registration mechanism would be achieved by having advertisers count the other advertisers sending to the same multicast group and adjust advertising frequency accordingly, in a similar fashion to RTCP. This has problems under transient conditions such as startup; an answer to that is being worked in avt. See draft-ietf-avt-reconsider-00.txt or .ps
The .ps version is recommended so the figures can be seen.
The scope of this listening procedure was an issue. An ISP might have to listen to a large number of multicast groups. To cut down on this burden, registration would still use local methods.
The second extension proposed by Rosenberg and Schulzrinne is the use of brokers as intermediaries between Directory Agents and would-be clients. Brokers would specialize in specific services, and would support service-specific location algorithms. To perform this function, they would listen only to the multicast address for the service in which they specialized. They would register themselves with Directory Agents using the current Service Location Protocol.
Instead of asking for a service directly, a client would ask a Directory Agent for the address of a broker in that service.
Issue: this is a new step compared with current procedure.
Another issue: if the Directory Agent does not understand a particular service, would it be able to provide a broker reference for that service? As a transitional arrangement or alternative to DA-provided references, the client could find brokers by other means such as URLs in web pages or magazine ads.
The presentation also covered extensions to the syntax and semantics of queries to the broker. The key point is that service information would be more complex and voluminous than svrloc has been dealing with. Erik directed that this issue be referred to the list: it needs a lot of thought.
Discussion moved on to security aspects. One potential problem is misrepresentation of costs by servers. This issue has already been addressed.
Disposition: pass the proposals to the list. Break specific elements into other drafts, so core problems can be isolated from less important ones. Priority should be given to the improvement of scalability: addressing the multicast and broker proposals.
NOTE: A BOF will be held in Washington DC in order to discuss the proposal for Wide Area Service Location and determine interest in forming a new working group to develop either an Experimental or Standards based protocol.
IV. Registry for Templates
Erik asked if mature templates could be registered with IANA. The response from an IANA representative was that this could be done. However, IANA can do syntax checks only, not checks of semantics. They would like a process (such as an expert reviewer designated by the Working Group) that they could call upon for the latter.
A brief discussion took place on whether template specifications should be RFCs. An argument against this is that it would be unsuitable for small, proprietary applications.
A completely different housekeeping item has to do with the allocation of IPv4 multicast addresses. Svrloc requires that a range of site-specific addresses be allocated in each site. The MBone draft doesn't quite say this. Quick resolution is needed.
Action: This is being pursued in collaboration with the MBONED WG.
V. Modifications to Service Location Protocol
Should changes to SLP mean that its version is incremented? Currently, implementations exist, but they have not been deployed. Erik's view is that the protocol should stay at version 1, but he will consult with the implementors.
Erik presented a list of fifteen required changes, two of which he emphasized as key.
· Directory Agent advertisements currently do not carry a digital signature.
· The "F" bit should be sent in the SrvReg message, not in the SrvAck to SrvReg. Race conditions result in the latter case.
VI. New Charter
Erik noted that a proposed new charter has been posted to the list. He identified the key problem being worked on by svrloc as the location of service by attribute match, assuming in general that multiple instances of the service exist with different attribute values. The work on hand is:
· Completion of the API
· Readying of a new Service Location Protocol draft
· Action on discovery, advertisement, IPv6, LDAP-SLP all to be completed by the end of the year.
A meeting participant wondered whether wide-area service location fits within this charter. Erik will check with the Area Directors and decide by around the end of September whether the topic lies within another Working Group's scope. If the decision is to do the work in svrloc, the first step is to divide the topic into sub-problems and select those to be worked on. (RESOLUTION: A BOF will be held in December to determine interest in Wide Area Service Discovery and to solicit proposals.)
Svrloc also needs to consider the relationship of the printer service work to the work being done in Working Group ipp -- there is a need for cross-pollination. The services provided in svrloc should essentially be viewed as bootstrapping other aspects of service provision.
The final thought was that the Service Location Protocol awaits deployment.
Wide Area Network Service Location - Overview and Motivation
SLP Proposed Clarifications
SLP Proposed Modifications
New DA Advert Format
Service: Scheme and Templates
go to list