Subject: Re: A propoosal for SLP evolution

From: Erik Guttman <[email-masked]>
Date: Thu, 28 Jan 1999 14:15:55 +0100

Folks,

During the course of the IETF last call, I received comments on SLPv2
from Peter Ford and Ye Gu at Microsoft.  These comments concerned the use 
of SLPv2 as both a discovery and directory protocol.  During the weeks 
which followed I attempted to arrive at a position whereby we could 
satisfy the comments which Peter Ford had made and preserve the work 
which had been arrived at through the efforts of the SVRLOC WG.

The position we arrived at through private discussion must now be reviewed
by the SVRLOC WG.  Only with concensus of the WG will any action be taken.
So, following discussion on the mailing list, if there is interest in the
proposals made by Microsoft and outlined here, we can issue new drafts.

The proposal is (please correct me if I'm wrong, Ye and Peter):

  * Issue two documents for the specification of SLPv2:  One with the base
    specification the other with AttrRqst and SrvTypeRqst.  The latter 
    document would clearly indicate that these messages are optional in 
    SLPv2.

  * Go to working group last call.  If there are no objections, proceed
    to IETF last call.  If there are no show stoppers there, proceed to
    IESG for balloting and advancement to Proposed standard.

This involves a change to the protocol:

  * Currently DAs MUST support AttrRqst and SrvTypeRqst.  The suggestion
    is to say DAs MAY support AttrRqst and SrvTypeRqst.

To support this change, the following protocol modifications should be 
entertained:

  * Text in the base spec would be removed to a separate draft.

  * SA support for AttrRqst and SrvTypeRqst is currently OPTIONAL.  If
    the SA receives one of these requests the SA returns a MSG_NOT_SUPPORTED
    error.  The change would be that DAs would also be return this error if 
    they received a message they don't understand.

  * DAs and SAs would include an attribute in their SAAdvert and DAAdvert
    respectively listing the optional messages they support.

       "(SLPv2OptionalMessages=6,9)" 

    Indicates that the agent supports both AttrRqst and SrvTypeRqst messages.

  * If a UA issues an AttrRqst or SrvTypeRqst and there is no DA in its 
    scope which supports these message types, the UA would have to multicast
    the request to SAs.

  * In order to support discovery of all services without the SrvTypeRqst
    message, wildcarded service types in service requests would be supported.

Analysis of the proposal:

  Advantages:

    1. This proposal reduces the number of requirements for DAs.

    2. Support for SrvTypeRqst and AttrRqst are currently optional
       for SAs and mandatory for DAs.  This is inconsistent.  Making
       support for the messages optional on DAs makes operation of the
       protocol consistent whether DAs are present or not on the network.

    3. Clients may use different mechanisms for directory lookup of
       attributes: SLPv2 is only one possibility among others.  Support
       for SLPv2 attribute and service type retrieval may not be required
       by some implementors who nonetheless wish to support Directory
       Agents.

    4. The result of this reworking of the protocol is more inclusive:
       It achieves consensus by incorporating the IETF last call comment
       of a major vendor.

  Disadvantages:

    1. We need to review and prepare new documents.  This will require
       time which will postpone conclusion of the SLPv2 standardization.

    2. Making Attribute Request and Service Type Request optional for DAs
       may mean that UAs will have to multicast requests which they otherwise
       would have unicast to a DA.  This may negatively impact the scalability
       of SLPv2.

Please post any questions, comments or concerns you have to the working 
group mailing list.  I regret that conversations leading to this point have
been held privately, but I assure you all parties worked to find a solution
which could be as little disruptive to the current specification as possible
and yet to meet the expressed concerns.  

If what I've outlined is agreeable, we can issue the new documents very 
shortly.  If its not, please let the WG know.

Erik Guttman
SVRLOC WG Chair

---

From: James Kempf <[email-masked]>
Date: Thu, 28 Jan 1999 09:29:24 -0800 (PST)

Erik,

It is certainly encouraging to see a major vendor like Microsoft consider
support for SLP. So it is worthwhile seriously examining the suggested changes, 
especially if it looks like accepting them will lead to Microsoft wholeheartly 
embracing the protocol, implementing it in their products, and throwing their 
considerable marketing resources behind it. 

However, I have some concerns about the nature of the suggestions.

The first concern is that there are currently products based on SLPv1 from major 
device manufacturers that use the two protocol requests which would be
declared optional. The example I am most familiar with is HP's Webjet Admin.
This is used for administering HP network-enabled printers and thin print 
servers. These devices are designed to be used in an enterprise setting,
where scalability is of concern. If the enterprise was using an SLP
implementation having DAs that didn't implement these two messages,
the performance of these tools would likely be extremely poor.

The second concern is that some groups defining service types, using
the service type template definition procedure outlined in 
draft-ietf-svrloc-service-scheme-XX.txt, are arranging the definitions
so that an AttrRqst would be required in order to access the
service. An example is the IPP group. The template proposed for
IPP would have a single service URL and an attribute that contained
all the protocols supported by the printer. In order to access the
printer, the client would have to request the attribute to determine
which protocol to use. Even though the service scheme draft explicitly
states that the service URL should contain everything the client needs
in order to contact the service, the IPP group felt that having a
printer advertise a service URL for each protocol it supported would
be too much of an administrative burdern, since network printers these
days often support 10 or more protocols.

Protocol negotiation, as in the above example, is one area where people
are defining service type templates that require AttrRqst in order
to access the service. The other is in negotiating security. If a particular
service supports multiple security protocols, an attribute is used to
list those and the client must obtain the attribute in order to use
the service. Both these cases are examples of where additional information
is needed before the client can actually open a socket and talk to the
service. In both cases, there are alternative solutions, namely either
advertising multiple service URLs with different service types, or
embedding the attribute information into the service URL, but the
groups defining the service types have felt that these alternatives
are not acceptable.

So the message I've taken from this is that people seem to feel, based
on SLPv1, that the directory service aspects of SLP are a convenient
and easy way to obtain attribute information. For SAs, our experience has been 
that supporting AttrRqst and SrvTypeRqst is not particularly burdensome, given 
that the attribute information must be maintained anyway for doing a SrvRqst 
query. For UAs, given that location is being done via SLP, the
experience with existing products and with groups doing service type
definition seems to indicate that they prefer using SLP for simple
directory services (rather than another protocol) since they are using
SLP for discovery anyway.

The proposed partitioning of the protocol would seem to be moving
against these trends in how people are using SLP.

		jak

---

From: "Roger Holm" <[email-masked]>
Date: Thu, 28 Jan 1999 12:11:58 -0700

All,

I agree with James assessment of the use of attributes for both locating service information efficiently by narrowing the search criteria based on attribute information and using attributes to provide the small amount of extra information that is sometimes required to access and utilize a service in the best possible.  In our use of SLPv1 in NetWare 5 we take advantage of both of these uses of SLP attributes.  Having implemented SLPv1, I also agree with James that the difference in implementation between the current proposal and what has been suggested would be minimal with a great loss in capability.  Having said that though, I am also aware of the temptation of enhancing the directory capaibilities of SLP to become more on the scale of LDAP, Novell Directory Service, Active Directory, etc., and I am not in favor of this.  I believe that SLP currently has just about the right amount of capability to allow relatively efficient lookup and access of network services.  So perhaps!
 some wording in the RFC to suggest that the use of attribute information be limited to information useful in finding and utilizing a service would be appropriate.  

We had many long discussions at Novell about the relationship of SLP with our directory service (NDS) and basically determined that SLP should be used in the role of finding the service (in this case NDS) and not trying to compete with or substitute for it.  And in pragmatic terms, the SLP protocol is so simple in its capabilties that it could never support the real value that a full blown directory service provides.  We have positioned SLP as one of several ways (DNS, DHCP, etc) to locate not just our directory service, but other network serivces in the network.  So in short I am definitely against making the Attribute Request and ServiceType Request optional. 

I believe that there was some discussion also about allowing a DA to support more than one access protocol (e.g., LDAP) to store and retrieve service  and attribute information.   One concern I would have with this is the potential pressure to enhance the capabilities of SLP to match the more robust capabilities of the new access protocols.  This I would not personally be in favor of.  In my experience it usually works best to clearly define the function and purpose of a protocol/service and keep it in that space.  Simple and efficient while doing the job can't be beat.   In my opinion, SLP is all about efficient service location and any changes or modifications should be made with only that purpose in mind.   Use SLP to locate the service and then use the access protocol defined and designed for the use of the service.  I am not absolute in my position about this, but would have to persuaded with some major benefits to be excited about it.

Of course, these comments are my own opinion and do not necessarily represent Novell's official position on this subject.

Roger Holm 
Novell, Inc.
[email-masked]

>>> James Kempf <[email-masked]> 01/28/99 10:29AM >>>
Erik,

		jak

---

From: Michael Day <[email-masked]>
Date: Thu, 28 Jan 1999 14:01:27 -0700

Erik, all:

I think the change requests are reasonable and will work just fine. However,
I'm not certain I understand the reasons for the changes.

It is difficult to draw a hard line between a directory protocol and a
discovery protocol - there are some nice overlaps that, I believe, make it
easier to write good applications. 

However, two of the things I look at to distinguish between a directory
protocol and a discovery protocol are:

- schema support: SLP's schema is exceedingly simple, while a DAP must be
able to support rich schemata.

- identity: identity is a necessary element of a DAP, but is also
necessarily _absent_ from a discovery protocol. That is, for discovery I
must be able to locate services without establishing my identity. However,
for a DAP, identity-based authentication must be part of the protocol.

Based on the items above, I don't think we are in danger of creating a DAP
by accident, so to speak. I think SLP is simple enough to preclude its use
when a DAP is indicated.

Also, I believe an SLP implementation without an attribute request would be
limited disproportionately to any benefits of simplification. The attribute
request is a useful, probably necessary, element of the protocol.

Mike

Michael Day
Co-Founder & Chief Technology Officer
Madison River Technologies, Inc.
voice: (801) 802-0706 ext. 14
mobile: (801) 368-4585
FAX: (801) 802-0652
mailto:[email-masked]
Send a text message up to 150 characters to:
[email-masked]

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Thursday, January 28, 1999 6:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: A propoosal for SLP evolution

Folks,

    Indicates that the agent supports both AttrRqst and SrvTypeRqst
messages.

  * In order to support discovery of all services without the SrvTypeRqst
    message, wildcarded service types in service requests would be
supported.

  Advantages:

  Disadvantages:

    2. Making Attribute Request and Service Type Request optional for DAs
       may mean that UAs will have to multicast requests which they
otherwise
       would have unicast to a DA.  This may negatively impact the
scalability
       of SLPv2.

Erik Guttman
SVRLOC WG Chair

---

From: [email-masked] (Reynolds Franklin NRC/Boston)
Date: Thu, 28 Jan 1999 16:34:44 -0500

>for a DAP, identity-based authentication must be part of the protocol.

Generally speaking I agree with you, but I am not completely convinced
that identity is necessarily absent from all discovery protocols. For
example, aren't the DHCP people working on a secure version that
only responds to requests if the request contains sufficient information
to authenticate that the client is authorized to use the service?

Franklin Reynolds
Nokia Research Center

---

From: Michael Day <[email-masked]>
Date: Thu, 28 Jan 1999 15:14:10 -0700

True, you can add authentication to discovery protocols, but to do so you
also need what amounts to a directory service (and a pki is that is not part
of the directory service). Authentication requires identity, which resides
in the directory. 

So I agree with you - identity can be part of discovery. But the identity
comes from the directory, not the discovery protocol. 

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, January 28, 1999 2:35 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: A propoosal for SLP evolution

Franklin Reynolds
Nokia Research Center

---

From: "Todd Rupper" <[email-masked]>
Date: Thu, 28 Jan 1999 15:26:36 -0700

Erik,

We have products dependant on the AREQ & STREQ.  Without this functionality, I see little value in SLP. 

Todd.

---

From: Ira McDonald <[email-masked]>
Date: Thu, 28 Jan 99 18:34:48 EST

Hi Franklin,

Yes, at the direction of the IESG, the DHCP people are working
on exactly that - secure mutual authentication of identity.
If you pick up your boot vector from a (compromised) DHCP
server, you are in very big operational trouble.

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc