Subject: Open Issues

From: Evan Hughes <[email-masked]>
Date: Wed, 14 Jun 2000 14:51:53 -0400 (EDT)

Does anyone feel there are any open research issues with SLP? 

e

---

From: Kevin Arnold <[email-masked]>
Date: Wed, 14 Jun 2000 12:22:44 -0700

Actually, I have an issue with the spec but I don't know that there is
anything we can do about it now:

By having the PRList (Previous Responder List) be a set of strings, we have
limited the number of services that can get on that list per MTU.  Here at
Apple, it can be a common occurance to have a large number of SA's
responding to a service:service-agent request (hundreds, if not in the
thousands) and the UA's PRList gets filled up quite fast so its easy to have
SA's repeatedly responding to the request as their IP address will never be
on the PRList.

Since we are populating this PRList with IPv4 dotted decimal addresses
anyway, it seems that just having the 32byte address would be much more
efficient and allow for a much longer PRList.

Now this may be quite a corner case and we are working to implement a DA to
help nullify this issue, I just wanted to put out my $0.02

Kevin

--Kevin Arnold
--Senior Software Engineer
--Network Services Location (NSL) Technical Lead,
--Service Location Protocol (SLP) products,
--NetFinder, and Personal NetFinder products
--Service Discovery Group,
--Apple Computer

> From: Evan Hughes <[email-masked]>
> Date: Wed, 14 Jun 2000 14:51:53 -0400 (EDT)
> To: [email-masked]
> Subject: Open Issues
> 
>

---

From: Bob Bohanek <[email-masked]>
Date: Wed, 14 Jun 2000 15:05:16 -0500

> SA's repeatedly responding to the request as their IP address will never be

I will second Kevin's comments on this.  I have talked with serveral people
that are looking at an SLP implementation with IP multi-casting turned on at
the router level, and again we are talking about thousands of SA's
responding to a request.  Unless a DA implementation is used at a location,
then this would limit its usefulness, which may be the answer, but...

Just my less then $0.02   :-)

Slainte,
Bob
*******************************************************************
Robert Bohanek, USNA '90 (SS)
Systems Engineer, Apple Computer, Inc.
e-mail: [email-masked]

snail mail:
15050 Cedar Ave. South #116, Box 315
Apple Valley, MN  55124

Phone:
(651) 463-3497 (work)

Apple Web Sites:
http://www.apple.com
http://www.apple.com/education (Education Home Page)

"Honor is what no man can give you and none can take away.  Honor is man's
gift to himself." - Liam Neeson in the motion picture "Rob Roy"

********************************************************************

---

From: Erik Guttman <[email-masked]>
Date: Wed, 14 Jun 2000 22:21:09 +0200 (MET DST)

> we are talking about thousands of SA's

Bob,

This is when you need to deploy a DA.  Otherwise, you will only succeed
in finding the 100 or so servers which respond first.  Note you can do
better than a 100 or so if the SAs really implement the random delay 
before responding - then the UA input queues won't get overflown as
quickly.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 14 Jun 2000 22:39:18 +0200 (MET DST)

Evan,

The main issues for SLP right now are:

  . Further interoperability testing
  . Moving the protocol specification to draft standard
  . Finishing work on the SLPv2 for IPv6 document and the
    Service template to LDAP schema specification.  These
    two documents are the only things preventing the SVRLOC
    WG from going to 'dormant' status.

These are not research topics.

My open issues list is:

 1. Naming

     SLP, DNS SRV RRs, DHCP options and LDAP directories can all
     be used to configure the location of services.  How can their
     divergent name spaces be unified?

 2. Automatic Scope configuration

     How do we standardize the use of nested administrative scopes
     for automatic scope configuration?  RFC 2608 leaves the details
     open.  This is not really a 'research topic' so much as an open
     work item - the research element is that nested admin scopes
     have not yet been deployed.

 3. DA to DA communications

     See Weibin Zhao's work: http://www.cs.columbia.edu/~zwb/project/slp/

 4. Simplification

     SLP could be simplified.  This would make it possible to implement
     it with fewer resources (making SLP more applicable to tiny devices).
     See:

       http://www.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2bis-00.txt

 5. bootstrapping security

     In order to have secure service discovery, there has to be some easy
     way of distributing keys.  But how do you find the key distribution
     centers, certificate servers, etc.?
 
 6. Unique services

     SLP current equates the locator with the identity of a service.
     This is very weak:  Some services have multiple locations or their
     locators change over time.  There should be a persistent id which
     can be used by clients to find the same service again.  Right now
     that can be done by 'attributes' - say a 'persistent name' attribute.
     This has to be worked out and standardized - right now it would be
     on a service by service basis - standardized in their 'service 
     template.'

 7. Convergence

     There are several very similar service discovery protocols today:
     Microsoft's SSDP, BlueTooth SDP, IETF's SLP.  These should converge.

I'll send more if any occur to me.

Erik