Subject: Re: SVRLOC WG IMPORTANT: SLPv2 next step?

From: James Kempf <[email-masked]>
Date: Wed, 30 Aug 2000 10:21:52 -0700

Erik,

I certainly support rechartering, and I am prepared to work on reviews, and coauthoring
the 2614bis draft and 2608bis draft.

I support the change list, modulo the discussion on the list about things to drop.

		jak
>
>I posted mail 3 weeks ago requesting feedback on whether we
>should recharter the WG to move SLPv2 to draft standard.
>See http://www.srvloc.org/hypermail/0670.html
>
>I have so far received no response.  We will not pursue 
>broadening the charter unless there is a clear positive
>response.
>
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>         ***Please*** respond to the following three questions:
>
>         ONE:   Do you support rechartering the SVRLOC WG to
>                pursue advancing SLPv2 to Draft Standard?
>
>         TWO:   Will you actively work on reviewing drafts of 
>                SLPv2bis as they appear?
>
>         THREE: If Yes, what is your opinion of the change list in
>          
>  ftp://ftp.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2bis-01.txt
>
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>We can still work on advancing SLPv2 to draft standard
>without the SVRLOC WG.  What is needed is:
>
> (1) Reworking RFC 2608, as per
>
>     ftp://ftp.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2bis-01.txt 
>
> (2) Interoperability testing showing that every feature in the
>     updated document is interoperable between at least two 
>     independent implementations.  This has to be written up as
>     a formal interoperability report.
>
> (3) Writing a SLPv2 MIB and submitting it for advancement to
>     RFC
>
>It will be useful to revise the SLP API (RFC 2614) for consistency
>with the SLPv2 after revision of RFC 2608, so that any change to 
>the protocol will be surfaced at the API.  It is not clear whether
>any change will be necessary at this time (for backward compatibility).
>
>***If*** there is sufficient interest, Jim Kempf and I will publish
>an internet draft with a full update to RFC 2608.  
>
>Separately, ***if*** there is sufficient interest, I will pursue
>rechartering SVRLOC to complete this work.  
>
>In my opinion, the current discussion on the mailing list does not 
>show interest in rechartering SVRLOC, though it has been responsive 
>to revising RFC 2608.
>
>Erik
>
>

---

From: Evan Hughes <[email-masked]>
Date: Wed, 30 Aug 2000 16:34:02 -0400 (EDT)

On Wed, 30 Aug 2000, Erik Guttman wrote:
> So are you happy with the slpv2bis-01 draft?

  No:

With regards to section 3.1.1:

  I do not feel that the issues raised regarding the complexity of
implementing LDAPv3 search filters justifies the simplification of SLP
search facilities. My reasons follow:

 * I have implemented the LDAPv3 search filter for OpenSLP (which should
be included Any Day Now, see
http://www.nexus.carleton.ca/~hughes/filter.tgz for the implementation),
and found the task doable. Implementing the logical operators was the
easiest part, since the code for `&` is almost identical to `|`s. The only
difficulty I found was in implementing the "leaf" operators (=,=*,<=,>=)
since there are five types of variable. The implementation took roughly 3
days (plus another 5 for refactoring), but it must be noted that I am have
only moderate experience.

 * In order to implement the `|` or `!` operators, some form of recursion
on the filter string is necessary. Arbitrarily limiting the filter string
to contain one `&`, while allowing an unlimited number of `|`s is
nonsensical, as `&` will become a special case for parsing -- increasing
complexity. 

 * The removal of any operator limits SLP's applicability. Before causing
such a dramatic reduction in SLP's potential functionality, it should be
shown that the `&` operator greatly increases the complexity of filter
parsing. This has not been done. 

 * To say that "Complicated logical queries for services have not proven
useful" is more of a statement about the uses of SLP than on the
applicability of the operator itself. As SLP gains acceptance, more
complex uses of it will be found. As more complex uses are found, more
complex filtering will be necessary.

 * At some point during the discussion somebody mentioned the relative
complexity of each of the entities on the network. As far as I recall,
complexity was a spectrum, with UA/SA's being simple (possibly
computationally bound), and DAs being complex (possibly with greater
memory/processor resources). Removing the `&` weakens the role of the DA,
since any UA that wishes to use multiple `&`s will have to do client side
attribute checking. This does not follow with the aforementioned
resource model.

(I feel like I should get a t-shirt saying "Save the &". =)

 Before stating that the LDAPv3 filters make SLP difficult to implement,
it may be a good idea to find some supportive references. I was able to
code and then refactor the search filter in less than two weeks. 

 Further, I don't see the point of removing the eliding of
leading/trailing white space. Again, the code of eliding is relatively
simple, and it avoids pesky white-space errors. 

In general:

 Reducing SLP's functionality will only harm SLP's utilization. As it is,
SLP has not gained widespread acceptance (OpenSLP is the first opensource
implementation of SLP. This indicates that few oft-used services use
SLP). Weakening SLP's functionality condemns the protocol to disuse. 

 Consider the functionality in terms of amortization. Since searching will
usually be done in DAs, and DAs will be a "build once, use often"
application, the minimal cost of implementing a few useful features will
be averaged across many running DAs. But UAs, which require these search
filters, will be legion (there should be a UA in every web-browser, time
daemon, printer application, mail client, news client, networked game,
networked application, etc), meaning that there are going to be thousands
of people using SLP in UAs. 

 Does it make sense to favour the few DA developers, or the many UA
developers? Do you "simplify" (I still doubt any significant
simplification would result, but let's pretend =) the task of the
minority, only to condemn the many to hacks and work-arounds?

e

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 31 Aug 2000 09:50:29 -0700

Hi Eric,

YES - please recharter SLP WG to move SLP to Draft
Standard - presumably on the basis of 'slpv2bis' I-D.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 9:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: SVRLOC WG IMPORTANT: SLPv2 next step?

          

Erik

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 31 Aug 2000 10:01:42 -0700

Hi,

I think I agree with Evan below.

In IPP (Internet Printing Protocol), we're currently
considering using LDAPv3 String Search syntax to add
filters for Job and Resource objects.  Given the
discussion on the SLP WG mailing list, we're wondering
about choosing a profile (subset) of the full LDAPv3
filters.

Information that supports a reasonable implementation
cost for full LDAPv3 filters is important, so I've
cross-posted my reply to the IPP list.

Cheers,
  High North Inc

-----Original Message-----
From: Evan Hughes [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 1:34 PM
To: Erik Guttman
Cc: [email-masked]
Subject: Re: SVRLOC WG IMPORTANT: SLPv2 next step?

  No:

In general:

e