Subject: WG ACTION: comments requested for slpv2bis final list of changes

From: Erik Guttman <[email-masked]>
Date: Tue, 19 Sep 2000 11:29:11 +0200 (MET DST)

***************************************************
   ***************************************************
   **                                               **
   **           FOR WORKING GROUP DECISION          **
   **        (Send responses by Oct. 3, 2000)       **
   **                                               **
   ***************************************************
   ***************************************************

There has been discussion of draft-guttman-svrloc-slpv2bis-01.txt.
I want to summarize and see if we can get consensus on the SVRLOC
mailing list.  Once we have this, Jim and I will produce the next
version of slpv2bis, which will be a protocol spec meant to fully
replace RFC 2608.

Final list of changes to RFC 2608:

 . Deprecate use of '!' and '|' in search filters - only
   as per draft-guttman-slpv2bis-01.txt, section 3.1

      filter   = '(' '&' <exprlist> ')'
      exprlist = <expr> | <expr> <exprlist>
      expr     = '(' <tag> <op> <val> ')'  
      tag      = as RFC 2254 excluding <extensible> rule
      op       = ibid 
      val      = ibid

   draft-zhao-slp-da-interaction-07.txt is in WG last call, close 
   to submission to the IESG for advancement to proposed standard

 . Deprecate attribute requests by type
   as per draft-guttman-slpv2bis-01.txt, section 3.2.1

 . Deprecate service deregistration tag list wildcards
   as per draft-guttman-slpv2bis-01.txt, section 3.2.2  

 . Recommend mesh enhanced support to DAs.
   as per draft-guttman-slpv2bis-01.txt, section 3.3

 . Deprecate rfc 2610 mandatory scope configuration rules
   as per draft-guttman-slpv2bis-01.txt, section 3.5.1

 . Use MADCAP scope configuration rules. 
   as per draft-guttman-slpv2bis-01.txt, section 3.5.2

 . Revise scope rules
   as per draft-guttman-slpv2bis-01.txt, section 3.5.3

 . Deprecate attribute tag list wildcards
   as per draft-guttman-slpv2bis-01.txt, section 3.6

 . Use literal string matching (not requiring elision of spaces)
   as per draft-guttman-slpv2bis-01.txt, section 3.7

Controversy on the list has lead me to the following opinions
(but please discuss this further if you disagree!)

 . Use of exclusion lists is not yet understood enough and is
   redundent given that we have previous responder lists.  
   Thus, it should be progressed as an OPTIONAL enhancement 
   not as a RECOMMENDED replacement for PR lists.

 . There is some support of full LDAP search filters (see
   http://www.srvloc.org/hypermail/0684.html) but we can
   take this up in another thread.  I think that after 
   clarification, Evan will agree with me on this one.

   It is not suggested to eliminate the '&' - only the '!'
   (which doesn't make much sense anyway:  I don't look for
   all the services which DO NOT support a particular feature,
   I look for the services which DO have the desired characteristics)
   and '|' which can readily be done by submitting a series of
   requests if previous ones fail, or sending them 'in parallel.'
   This is not efficient, but it is an odd thing to do anyway.
   Normally we look for a service which meets our requirements,
   and these requirements don't have exclusive conditions, like
   'has feature A and C' OR 'has feature B and D'.

Shortly after Oct 3, I will send a revised version of this list 
reflecting the consensus of the WG.  It is important to get your
comments in before Oct. 3.

Thanks,

Erik

---

From: Matthew Peterson <[email-masked]>
Date: Tue, 19 Sep 2000 04:26:22 -0600

> Erik Guttman wrote:

YES!

 
>    as per draft-guttman-slpv2bis-01.txt, section 3.2.1

YES
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.2.2

YES
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.3

Maybe, as long as this is a *recommendation* not a requirement.  I think
that it would be wise to be careful to standardize only the most
necessary characteristics of SLP DAs.  DAs will surely be implemented as
proprietary and specialized software or hardware appliances.  Hardware
and software vendors should be given as much latitude to optimize DAs
(including DA to DA communication) as possible.  Even if the mesh
enhancement is approved as a standard, I think that you will see DA
vendors use proprietary methods both to protect their market share and
to improve performance.  Since SLP is designed as an enterprise (not a
global) service location solution, it is *very* likely that
organizations will standardize on a single DA vendor -- in most cases DA
interoperability from various vendors will not be an issue.
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.5.1

YES
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.5.2

YES
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.5.3

YES
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.6

YES!
 
>    as per draft-guttman-slpv2bis-01.txt, section 3.7

YES
 
>    not as a RECOMMENDED replacement for PR lists.

NO! prlists need not be replaced with exclusion lists.  The only reason
for the changing prlists to exclusion lists is to be able to increase
the number of hosts that can be reached in multicast operation before
exceeding the MTU.   If you have a problem with a prlist that exceeds
the MTU for network traffic sake, _you_should_use_a_DA_ !!
 
>    'has feature A and C' OR 'has feature B and D'.

YES.  I agree with Erik in deprecating the '!' and '|' in LDAP search
filters. 

Matthew Peterson
OpenSLP maintainer
Caldera Systems, Inc
[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Tue, 19 Sep 2000 17:12:54 +0200 (MET DST)

> Maybe, as long as this is a *recommendation* not a requirement.  

That is the idea.  Note that the enhancement works if even ONE
DA in a scope supports it, and benefits *any* SA which supports
it; the enhancement is fully backward compatible with SLPv2.

> the MTU for network traffic sake, _you_should_use_a_DA_ !!

In defense of the exclusion list approach: 

 - It was extremely successful in widely deployed Intel products.

 - It would be a trailer instead of between the header and the
   payload - which is a lot more efficient and easy to implement.

 - There are scenarios where deploying a DA is not feasible and
   you have many services.  For example - imagine the middle of
   a 'core network' where there's a lot of infrastructure (switches,
   meters, hubs, etc.) all of which are *manageable* but have no
   user interface.  It makes no sense to use scopes there, and it
   would be best not to run any services either.  This is just the
   space where Intel's product really shined.

 - There is resistance to the use of scopes in environment where
   different incompatible network organization schemes are 
   already in place and there is a general hostility to imposing
   additional namespaces.

 - The advantage of the exclusion list approach is that it finds
   *all* not *a lot* of services using repeated multicast. That
   is, it has the *same semantics* as asking a DA for a list of
   services.  That symmetry is worth a lot.

I would really appreciate folks in the WG's opinion of Mike Day's
draft-day-svrloc-exclusion-00.txt.  Please post reviews of this
document to the mailing list.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Tue, 19 Sep 2000 18:56:44 +0200 (MET DST)

>    space where Intel's product really shined.

This wasn't clear - sorry.  What I meant to say was that you don't
want to run directory services (like DAs) where no 'hosts' should
be.  On the other hand, you want to be able to discover devices which
are running a management agent which are part of the network infra-
structure.  SLP using exclusion lists means you can use multicast
convergence and find all of them - without requiring a DA or scopes
to scale.  

This may sound like a far-fetched scenario, but there is a lot of
the network infrastructure out there which needs to be managed for
which this could be very useful.  Mike - do I have this right?

Erik