Subject: Re: SLP for Capabilities Discovery

From: Graham Klyne <[email-masked]>
Date: Thu, 22 Apr 1999 10:43:43 +0100

At 14:51 21/04/99 -0700, James Kempf wrote:
[...]
>
>Attached is an Internet draft showing how Service Location Protocol (SLP)
>could be used for resource capabilities discovery on the Internet.

[...]
>   The danger in defining a new protocol specifically for discovering
>   resources on the Internet is that, like DNS, the protocol would
>   probably be deployed internally as well.  Developers would then have
>   the opportunity to use the protocol to perform service discovery on
>   the client side by downloading resources and inferencing over them
>   rather than using protocols such as Service Location Protocol (SLP)
>   or Lightweight Directory Access Protocol (LDAP) that inference on
>   the server side.

I am concerned that this may reflect a fundamental misunderstanding of the
goals of RESCAP.  Resource *discovery* is not a goal;  rather, it is
determination of capabilities associated with a known resource.

Your reference to server side inference seems to suggest a discovery mode,
which in turn requires some kind of *searching* protocol rather than a
*resolution* protocol.   Again, the original goals were to avoid the
complications of searching.

That said, the proposal seems in other respects to satisfy the expectation
of starting with DNS and switching to some other protocol to retrieve the
information associated with a resource.  It may be that the localized
searching element in this case is not a major complication (I don't know
SLP sufficiently well to comment).

I have a concern about the DA discovery procedure you describe, which you
characterize as:

>   This procedure exactly parallels current practice for finding
>   Internet addresses of servers offering services such as FTP, NTS, and
>   the World Wide Web (WWW), namely a conventional name that resolves to
>   the machine address or a list of DNS SRV RRs for machines offering
>   the service.

The practice of using conventional (but not mandatory) names seems fine
when human interaction is involved, and the occasional failure can be
worked around.  But for rescap (which I see as something that must be
wholly automated) I think a more definitive approach is required.  It may
be that mandating the use of DNS SRV RRs is within scope for this work.

#g

------------
Graham Klyne
([email-masked])

---

From: Michael Day <[email-masked]>
Date: Thu, 22 Apr 1999 19:28:42 -0600

And it's somehow a better idea to make two tools do the same job instead of
one tool? 

Your assertion that SLP and RESCAP are in very different spaces is not
obvious to me with the information I have at hand. I don't discount the
possibility that you are correct, but it's kind of hard to accept terse
dismissals with no accompanying justification. 

Mike Day

-----Original Message-----
From: Keith Moore
To: James Kempf
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: 4/22/99 7:07 PM
Subject: Re: SLP for Capabilities Discovery 

SLP is not a candiate solution for RESCAP.  They are in very
different spaces and it would be a Bad Idea to try to make
the same tool do both jobs.

Keith

---

From: Michael Crawford <[email-masked]>
Date: Thu, 22 Apr 1999 19:04:12 -0700

Ouch!  This sounds almost religious rather than logical.  Why reinvent the
wheel if there is an existing round object to suit the need.  I'd much
prefer 
extending an existing protocol and expand our mind rather than build
something from scratch.  The existing protocol has the advantage of prior
acceptance of many (if not all) of its tenets, and in some cases is already 
in place.  The advantage is that a simple modification is likely to be
faster
and easier for the real world community to make to an existing protocol than

to add a whole protocol.  Conceptually at least, it seems worth exploring.
If its dumb, we'll find ourselves writing hacks and exceptions that get
larger than the goal item, and we can reject then.  It's a little early to
reject SLP,
especially on the grounds it is a open end wrench instead of a socket
wrench.

> From:	Keith Moore [SMTP:[email-masked]]
> Sent:	Thursday, April 22, 1999 6:07 PM
> To:	James Kempf

---

From: James Kempf <[email-masked]>
Date: Fri, 23 Apr 1999 09:22:34 -0700 (PDT)

>
>
>> introducing a new protocol for
>> RESCAP introduces the possibility that it could be misused as yet
>> another service discovery protocol, even though it wasn't designed
>> to be.
>
>sure.  but surely that doesn't justify misusing a service discovery
>protocol as a resolution protocol.
>

If the primary objection is to the service discovery component of
SLP, then the SrvRqst message could be dropped and just the
AttrRqst message used. This would not satisfy those who would
like to see SLP connected to the Internet, but there are other
possible solutions for that.

>in general, anytime there's not a tailor-made solution to a problem, 
>the Internet has a tendency to adapt/misuse/abuse any protocol that 
>does something even vaguely isomorphic to the problem.  But the fact
>a new protocol also has the potential for misuse, should not stop us 
>from defining new protocols.
>

I agree that the potential for misuse shouldn't stop new protocols
from being designed. But, on the other hand, I think it is important
to discuss potential misuses beforehand, and look for possible
solutions to preventing them, rather than face the unfortunate
consequences afterwards. 

		jak

---

From: James Kempf <[email-masked]>
Date: Mon, 26 Apr 1999 08:59:41 -0700 (PDT)

Paul,

Thanx for your reply.

> >Slight modifications in protocol usage, not inconsistent with the
> >standard protocol, and some naming conventions are proposed to allow
> >SLP to fit into the Internet environment.
>
>I'm not convinced that this is the case. According to RFC 2165, SLP is
>specifically designed to be used in local area networks, not the global
>Internet. Although you provide a method for changing the latter, it is
>not at all clear that the rest of the protocol will withstand such a
>change. 

This is a legitimate question, and something that needs to be considered.
The draft I sent out attempted to remove those parts of the protocol
that were intranet specific. Whether or not that succeeded is the 
question.

As I indicated in my email, we have a prototype with some of the
modifications listed in the draft running (i.e. "running code"). If it looks 
like there is interest in the working group, it would take a week or so to add 
the rest of the modifications to bring the prototype up to what the draft 
proposes. 

Given that RESCAP is designed for the Internet, a single point implementation
may not be enough to determine whether the proposal is feasible. 
Again, if there's interest in the working group, we could look at
a wider-scale test using the prototype.

>Given the thin current deployment of SLP, and given that all of
>the deployment heavily relies on the parts that need to be taken out to
>make this useful for rescap, it is premature to assume that such a
>fundamental change will work.
>

Sure, but one could make the same argument about a new RESCAP
protocol, even more so. Given that it was new, it would have
no deployment at all, not even the thin current deployment of SLP.

> >Abstract
> >probably be deployed internally as well.
>
> From the start, the abstract misstates the purpose of rescap. rescap is
>not for discovering resources, it is for resolving attributes of known
>resources. This is (I think) pretty clear from the charter. Maybe it
>should be made clearer in the John's requirements draft. SLP is really
>for discovering services, but rescap isn't.
>

Thank you for the editorial comment. I will modify the draft to remove
this misstatement (and the others indicated in the email, which
have been elided).

> >Developers would then have
>Arguing that "clients can misuse a protocol" does not lead to
>"therefore don't create the protocol". If it did, we would never have
>gotten HTTP. Using a rescap protocol to do service discovery would
>indeed be stupid and wasteful.
>

The arguement is not that a new protocol shouldn't be created. It is
simply that there is a potential problem. Even if SLP or another
protocol is rejected, the problem will still remain and needs to
be addressed, IMHO. It could be as simple as a section in
the new protocol draft that stated, clearly and unambiguously,
that RESCAP was NOT for service discovery.

Perhaps another argument in this vein, which I failed to bring up
but will in the next draft, is that service developers already
have two potential intranet choices for capabilities discovery,
SLP and LDAP. Adding a third one means they have to incorporate
yet another protocol stack if they want to discover capabilities
on the Internet. Giving people choices is good, but
at some point one has to question the wisdom of adding yet
another choice with minor differences from existing solutions.

This one is harder to address with directions in the specification
to protocol developers. If the protocol is lightweight enough, then
perhaps service developers won't mind, but it would certainly
be good to hear from them first.

> >An added benefit of this design is that Internet
> >clients can perform service discovery as well as simple resource
> >discovery.
>
>Warning, Will Robinson! These are two unrelated items. No one doing
>resource capability queries needs to do service discovery at the same
>time. If I'm asking "what are the MUA capabilities of
>[email-masked]?" I don't need to know anything about any service. It
>sounds like you're using this extension of SLP to get it more widely
>deployed.
>

Feedback I'm getting is that anything involving service discovery
is suspect. Therefore, the next draft will propose eliminating
the discovery aspect, so only the AttrRqst message remains. This
will make the proposal *only do capabilities discovery* on the
Internet side.

> >6. Security
> > . . .
> >Again, as is typically the case in SLP, the design contains no
> >provision for privacy or encryption of the information exchange
> >between the DA and UA. Should privacy be required, a security
> >association should be set up and IPSec [7] used.
>
>I'm sorry, but I think this is a non-starter. There is no defined way
>for an application client to determine whether or not IPsec is or is
>not in place, much less if it is being used to encrypt traffic. The way
>that RFC 2165 got around this was to say "Because the objective of this
>protocol is to advertise services to a community of users,
>confidentiality might not generally be needed when this protocol is
>used in non-sensitive environments." But rescap is specifically *not*
>limited to a community of users, so saying "no confidentiality" is not
>acceptable.
>

A legitimate point. Again, if there's interest from the working group,
we can look at ways to add privacy. 

Incidently, RFC 2165 is out of date (and is, in any event, not what
in the draft is based on). The IESG recently approved SLPv2,
please check draft-ietf-svrloc-protocol-v2-14.txt for the definitive
specification of SLPv2.

> >9. Requirements Analysis
> > . . .
> >   Granularity
> >
> >      SLP allows subsets of attributes to be fetched, and allows
> >      the full set to be fetched without knowing the entire set of
> >      attribute tags.
>
>I don't know SLP well enough to evaluate this, but I don't see in
>section 20.2 of RFC 2165 how to include particular attributes in the
>request. You didn't include any examples in your draft of requests for
>specific attributes.
>

Again, please see the most up-to-date version of the protocol
specification for more information about how to do this.

		jak