Subject: RE: A propoosal for SLP evolution

From: Peter Ford <[email-masked]>
Date: Thu, 4 Feb 1999 23:30:39 -0800

The core issues we have been trying to address is the introduction of a new
mandatory directory access protocol (what we sometimes affectionately call
SLP DAP). By having 2+ DAP protocols and 2+ representation mechanisms(slp's
service templates and LDAP schemas) we may end up with separate camps of how
devices on minimal networks should interoperate.

In this process we have attempted to split the current SLP document into 2
parts - the base discovery part and the SLP DAP part.  This has proven to be
more challenging than expected.

Erik and Charlie have diligently worked on this with us and I would like to
thank Erik and Charlie for their patience in this attempt.  In essence what
we are looking for is to drop features in the base SLPv2 spec.  It appears
that this goal is difficult to meet in light of the current state of the
document and process. It is our understanding that the document can be
simplified between the PS and DS stages.

Erik has suggested a few appendices to clarify usage of SLPv2 in the event
that there is a desire to use an LDAP DS in place of a DA and to only use
SA<->DA for service type to URL resolution. We of course would like to see
people only use that minimal subset.  Future implementations should be AS
SIMPLE AS POSSIBLE and people working on SLPv2 to drive for 100%
compatibility with LDAP schema.  (my bias is to USE LDAP ... :-)).  

cheers,

peter

---

From: "John Strassner" <[email-masked]>
Date: Fri, 5 Feb 1999 07:33:02 -0800

Peter,

though I share your concern about having multiple access methods,
there are certain cases where SLP has a pronounced advantage over
LDAP. For example, some devices do not have IP addresses, or an easy
way to hardwire them in, when they are first installed. Using LDAP is
impossible in such cases. However, SLP presents a lightweight, simple,
and efficient means of communicating with the device.

I don't think that the decision is as simple as saying that SLP and
and DAP both provide directory access capabilities. That's similar to
saying that we should never use BOOTP because we have DHCP.

Finally, many devices (e.g., cable access devices, ISDN routers, etc.)
have very constrained resource requirements. SLP works quite well in
such situations, where its implementation requirements and support are
considerably less than LDAP.

In conclusion, I do not think that we should remove features from the
SLP specification. Rather, I think we should come up with a BCP
document that specifies how the two can peacefully coexist in a
network.

regards,
John
-----Original Message-----
From: Peter Ford <[email-masked]>
To: [email-masked]' <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]' <[email-masked]>
Cc: Ye Gu <[email-masked]>
Date: Thursday, February 04, 1999 11:32 PM
Subject: RE: A propoosal for SLP evolution

---

From: "Roger Holm" <[email-masked]>
Date: Fri, 05 Feb 1999 17:59:43 -0700

All,

For the last week or so I have watched with interest the discussion, and concern for some, with respect to SLP and its supposed encrouchment on the DAP world.  I would like to make some observations about this matter before it closes.  I have a hard time accepting the notion that SLP and its backend database can be considered a Directory Service by any current notions of what a Directory Service is.  SLP does not define a new name space, but rather provides a mechanism through which services, defined by their capabilities and attributes, can be known and discovered in a local network environment.  There is no heirarchy of services or relationship defined between instances of services.  There are groupings of services defined by scopes, but this is provided only to allow better scaling of Directory Agents in larger network environments.  Which services are in which scopes is determined arbitrarily by the system administrator.   All of the services known through SLP must be cons!
idered "public access" type services because there is no mechanism in the SLP protocol to restrict access to the service registrations to select clients based on some authentication or identification criteria.  The fact that there are templates that define the syntax and semantics of service information stored and retrieved through SLP is merely a formalization of methods to promulgate the information necessary to share service information.  This is akin to defining the format of DHCP options.  You have to know the format of the information before it is useful.  Because it is lacking in so many of the areas that make a real directory service interesting and useful, I can't see the concern for, or reason to, portray SLP as a directory service with an associated access protocol.  SLP was defined and designed to facilitate the advertisement and discovery of service information in localized areas of a network environment.  No more and no less.  As such,  the protocol and its assoc!
iated data structures are adequate.  Beyond this it has minimal us
the more sophisticated services such as LDAP.  When the LDAP server is located through whatever means (SLP, DNS, local configuration), then speak LDAP to the LDAP server.  Therefore I see no reason to persue breaking up the current definition to factor out the storage and retrieval of service related information, now or later.    

I also don't see the support of SLP as mandatory.  I think it makes sense to support it because of the plug and play capabilities it brings to services in the network.  But there are always the standard technologies like DHCP and DNS to point the way to services that are available in the network.  SLP just adds to the list of those technolgies that give you a hint as to what services are available in the network and how to access them.

Having said all of this, I suggest that we follow Erik's proposal and get SLPv2 approved as it stands.  I also believe that any further attempts along the line of breaking out any part that is construed to be akin to a Directory Service is unnecessary in the future.

Perhaps I am missing something here, and if so I would sincerely like to be enlightened.

Roger Holm
Novell, Inc.
[email-masked]

>>> Peter Ford <[email-masked]> 02/05/99 12:30AM >>>

cheers,

peter