Subject: SLP apps, deployment and interoperability

From: Erik Guttman <[email-masked]>
Date: Wed, 9 May 2001 09:48:00 +0-200

Prompted by the discussion on binary IPC compatibility 
(which I do not think we should work on), I made a list
of SLP application interoperability issues which could
use some attention.

 a. What attributes should common services advertise?
    Are these services being advertised by SLP right now?
    (NFS servers, mail servers, web proxies, printer 
    servers, ...)

 b. Do we have enough to build human interfaces (browsers/
    choosers) for those devices?  Is anyone building such
    interfaces (for windows, gnome, kde, etc.)

 c. How do we make deployment of a large set of SLP enabled
    devices easy?  Is RFC 2610 (using DHCP to configure
    DAs and Scope lists) sufficient?  Has anyone implemented
    this and deployed it?  The other options are
     i) just use default scope for everything (does not scale)
        use DAs only when they are discovered (does not work
        in networks without multicast routing)
    ii) get scope information from a static file (impossible
        to administer, especially over time).  Use a static
        file for DA locations. (same problems as for scope
        info.)
   iii) get scope information from domain name (forces an
        odd DNS naming convention & unnatural service 
        provisioning strategy).  Use SRV RRs to find DAs
        in this case?
    iv) discover scopes from DAAdverts (or SAAdverts) and 
        allow users to choose which of them they wish to
        advertise / discover services in.  Drawbacks here
        is it doesn't work in a network without multicast
        routing, it fails if there are no users/operators,
        and worst of all - the list of scopes can change as
        DAs come up or go down.
    Note DHCP doesn't help with deploying cryptographic keys
    for use with SLP authentication.  How can that be made
    easier to configure & deploy?

At this point we still need to test and improve basic
protocol interoperability.  Many products exist that use
SLP, but primarily in cases where a single vendor uses the
same implementation on both the client (discoverer) and 
server (advertiser) sides.  SLP is effective middleware.

It would be great to move to a situation where various clients 
were able to interoperably discover various services of the 
same type.  To achieve this we need templates for those services, 
apps which use its definitions to get configured & services which 
advertise according to the same definitions.  This is what we
need to make SLP into IP infrastructure, as opposed to middleware. 

What to do?

Let's start by publishing the templates we are using internally
in our products, so as to encourage others to share them.  All
one has to do, really, is send me an email with a template in it
(see RFC 2609 for the format for this doc).  I will check it and
submit it to the IANA registry if it is OK.  See the registry at

  http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/

If you are using SLP as middleware - you could write a brief 
description of what you are doing and send it to the srvloc list.  
This would educate other developers about potential applications
and potentially to joint work on templates and wider use of the
services you are advertising using SLP.

Let's work on interoperability by organizing interop tests in 
the next year and continue our work revising (reducing if possible) 
RFC 2608.

A tremendous boon would be available browser utilities for major
desktop environments for locating corresponding services which 
advertise using SLP.  

One area which would be exciting to develop in this regard is 
printer discovery.  HP, Lexmark and Axis (who sell many print 
servers which are enbedded in other company's network enabled 
products) all support SLP.  Unfortunately, in the case of HP and 
Lexmark, they support proprietary varients of SLPv1 but this can 
still be accomodated.  New printers, supporting IPP, will likely 
advertise using SLP, according to the printer template.  A
widely available, solid printer browser capable of finding these 
printers and configuring the environment to use them, for windows, 
kde, gnome, etc. would be a real hit and substantially benefit
printing usability.

Erik

---

From: Sean Kelley <[email-masked]>
Date: Wed, 9 May 2001 10:33:01 -0400 (EDT)

All,

	My initial worry was that SLP would have the
same issues as SNMP. SNMP has a well defined wire protocol.
However, only one process (an Agent) may bind to the SNMP port on
a given machine. If multiple processes would like to register
to handle different branches of the MIB served by the Agent, 
then the developer must rely on incompatible proprietary libraries 
from the major vendors to communicate to the Agent.

	SLP has a similar issue with a single SA daemon binding 
to the SRVLOC port potentially supporting multiple processes 
advertising services. Luckily, there is a viable way for  
the SA daemon to support SrvReg messages via an IPC mechanism. 
However,  the exact IPC interaction is not specified.

	With the C API, this isn't really a problem since the
C API is well specified and developer must re-compile/re-link 
against the appropriate SLP library corresponding to the SA
daemon running on a particular platform.

	The Java API is a little more difficult. First, there
isn't a requirement to recompile on different platforms. Second,
the specification of the API makes it difficult to write vendor
independant code and swap out implementations. RFC 2614 doesn't 
specify a package containing interfaces which are to be implemented 
by vendor specific code. Finally, I didn't find a Java implementation
which supports OpenSLP. This is why I was looking into interoperability
between client libraries and daemons.

	I would be interested to what the implications of
a slightly different Java API would be. For example (the
package was chosen for example purposes only):
	
package javax.slp;

public interface ServiceLocationManger {
	void init(java.util.Properties p) throws ServiceLocationException;
	Locator getLocator(Locale local) throws ServiceLocationException;
	Advertiser getAdvertiser(Locale locale) throws
		ServiceLocationException;
}

where the developer would do the following:

	String impl = "com.sun.slp.ServiceLocationManger";
	try {
		javax.slp.ServiceLocationManager m =
(javax.slp.ServiceLocationManager)Class.forName(impl);
		m.init(p);
		javax.slp.Locator l = m.getLocator(...);
	}
	catch (Exception ex) {
	}

This would let the developer swap out Java implementations to
correspond with the SA daemon running on the platform.

	Sincerely,

	Sean

Sean M. Kelley                  Solers, Inc. 
[email-masked]          1611 N. Kent St. Ste. 600
[email-masked]               Arlington, VA 22209
(703)526-0001                   #include <std_disclaimer.h>

---

From: Erik Guttman <[email-masked]>
Date: Wed, 9 May 2001 19:14:36 +0200 (MET DST)

> However,  the exact IPC interaction is not specified.

Actually, it isn't so bad at all, if you go a different direction
with the implementation architecture.  I have implemented SLP SAs
and UAs as a library (no central process, no IPC).  Every library 
does DA discovery separately (pretty wasteful, but still OK).
Each library acting as a SA fires up its own thread for listening.  
The only real limitations to this approach are

 - SAAverts get lost, since previous responder lists will filter
   out some of the SAs resident on a given host!

 - The SAs are limited to listening for and responding with UDP
   messages (so long attribute lists are not possible!)  You can
   only bind to one TCP socket with a given port # (like 427).
   This requirement makes for the *only* shared resource, but you
   can get around it by making sure all services support only very
   small attribute lists.  RFC 2608 fully supports this.

 - Consistent SLP configuration becomes more complicated when 
   there are lots of autonomous agents on a host.  

If implemented this way, a client which does SLP discovery or a
service which does stand-alone advertisement can come prepackaged
with its own library and not make any host configuration assumptions.

Erik

---

From: Matt Peterson <[email-masked]>
Date: Wed, 09 May 2001 14:32:47 -0600

Hi Erik,  

This is a good summary.  My responses are based on experience from
OpenSLP and Caldera Volution -- an SLP enabled application.

>     interfaces (for windows, gnome, kde, etc.)

The most useful projects will be those that provide KDE, Gnome, ActiveX,
etc. widgets that perform SLP browsing.  These widgets would be designed
to be embedded in other applications much like the file dialog is now. 
 
>         and worst of all - the list of scopes can change as

I consider DHCP to be the best way for configuring scopes.  OpenSLP will
use DHCP to configure scopes by the 1.0 release later this year.

>     easier to configure & deploy?

Even after having implemented SLPv2 authentication as specified by RFC
2608, I still question the need for SLPv2 and doubt that it will ever be
deployed.  Please search the srvloc mailing list archive for previous
discussions on this topic.   

It has been much more productive for us (and we own OpenSLP) to not to
expend the development resources to cryptographically establish trust of
SLP delivered information (the SLPv2 authblock stuff).  Rather, we have
spent the time implementing authentication and security via service
specific protocols -- which had to be done anyway whether we were used
SLP to discover the service or not.  

The biggest problem with SLP authentication is distribution of keys. 
Since there are very few standards in this area is impossible to write
an SLP implementation that will not be inherently inoperable with
another implementation.  Even when using the same implementation, it is
difficult to realize the "plug and play" benefits of SLP since manual
key configuration is necessary.

Anyway, I am not very concerned about the distribution of keys because I
am starting to doubt that anyone will ever use them.  The only
authentication related SLP problem I am worried about is anonymous or
unauthorized de-registration of a registered service.  This problem can
be solved without key distribution, and with out modification of the
protocol.  

Our solution (subject to debate on the OpenSLP mailing lists) will
likely become the default mode of operation for OpenSLP and the choice
for deployment of Caldera management products.  It is likely that a set
of "trimmed down" security features will be available in OpenSLP 0.9.x
later this month.  (Of course we will still offer the option of using
the full SLPv2 authentication that is already implemented).
 
Finally, the above is not just an opinion based on theoretical
situations.  It is a expression of experience with products that have
had specific requirements related to security of SLP enabled code.  I
have personally spent several weeks researching, designing and
prototyping solutions that meet what I consider to be standard security
requirements.  I even implemented SLPv2 security in OpenSLP just to make
sure I did not miss something.   Can you offer any real life software
product examples that contradict the position expressed above?  If so,
please send email or post to the list.

> server (advertiser) sides.  SLP is effective middleware.

Agreed.  One situation that I have noticed where this is not the case is
in mixing Apple's SLP on Macintosh with OpenSLP to created some Linux +
Macintosh interoperability produces.  Pretty cool actually.
 
> services you are advertising using SLP.

I have scheduled some time to write templates for all of Caldera's
services.
 
> the next year and continue our work revising (reducing if possible)

I was hoping that this would happen last year.  Eric, you announced such
an event, but it was canceled.  OpenSLP would benefit greatly from
interoperability tests with other implementations.  I am still quite
sure that Caldera would participate.
 
> kde, gnome, etc. would be a real hit and substantially benefit

At one time I submitted a patch to CUPS (IPP based printing software for
Unix operating systems).  Literally, the patch only took a half hour to
write and resulted in complete availability of  CUPS printing
information via SLP using the standardized printer service template.
Somehow we need to communicate how easy it is to add SLP features to
existing products.  

It seems like this sort of thing could be evangelized at developer
conference -- the problem is finding someone that has the time to submit
papers and attend.   

-- 
Matthew Peterson
Sr. Software Engineer
Caldera Systems, Inc
[email-masked]