Minutes: Service Location Protocol Working Group
IETF Munich -- 11 August 1997
-----------------------------
Minutes taken by Tom Taylor <taylor@nortel.ca>

Chairman: Erik Guttman, Sun Microsystems
Agenda
------
1. Documents from the Working Group (20 minutes)
2. New URL scheme/template draft (15 minutes)
3. Presentation: Wide-Area Service Location (30 minutes)
4. Registry for templates (5 minutes)
5. Modifications to Service Location Protocol (20 minutes)
6. New charter, plans (10 minutes)

1. 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.

(b) API

The API document has been reworked and changes added. A draft will be put
out within the next month. Sun are using the API themselves, but Erik would
like independent confirmation of the document's completeness and usability.

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 and 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

draft-ietf-svrloc- Contents
------------------ --------
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

advertising-02.txt
------------------
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.

discovery-02.txt
----------------
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.

ipv6-01.txt
-----------

Comments have been solicited and received. A new draft will be issued soon.
There is very little left to do on this draft.

2. 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', ie. 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>.

3. 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.

4. Registry For Templates
----------------------
Erik asked if mature templates could be registered with IANA. The response
from an IANA representative was that this can 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) whom 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.

5. 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 verion 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.

6. 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 differing 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...