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.