Subject: OpenSLP comments on SRVLOC workgroup recharter

From: Matt Peterson <[email-masked]>
Date: Tue, 05 Sep 2000 17:47:58 -0600

Yes, I support a rechartering the work group and I can commit to
continued review of the slpv2bis drafts.  

Before giving my opinion of the the slpv2bis-01 draft, it should be
mentioned that my opinion does not necessarily represent the opinion of
all OpenSLP developers.  Rather than discuss our differences on the
OpenSLP mailing lists, I have invited everyone interested to discuss
their issues on this mailing list.  The OpenSLP project will then
continue it's charter to create an RFC compliant SLPv2 implementation. 
This will include changes that are result of the rechartered workgroup.  

> 3.1 Service Request
>
>     3.1.1. Limit requests to at most 1 '&' logical operator.  Thus,
>     only requests of type (x=4) or (&(x=4)(y=3)) are allowed.
>
>     The result of these rules will be that SLPv2 search filters will
>     be compatible with LDAPv3 search filter, but not visa versa. A
>     compliant LDAPv3 search filter implementation will be able to
>     process LDAPv3-subset search filters, but a SLPv2 compliant
>     implementation will not be able to process an arbitrary LDAPv3
>     search filter.
>
>     Complicated logical queries for services have not proven useful.
>     Allowing conjunctions of required attributes has proven very
>     useful and is easy to implement.

YES!  I have been involved with SLP for several years and I have only
heard one or two requests from developers for increased SLPv2 search
filter support.  In fact, were it not for the interest and efforts of a
single isolated developer, OpenSLP would still not have plans to
implement search filters.  There just has not been enough interest from
the developer community.  

I know that there will be disagreements here, but let's face it,
developers look at SLP to locate services (period).  In my opinion,
besides taxing SLPv2 implementors, the added complexity of extensive
search filters blurs the line between SLP and a real Directory access
protocol.  In theory LDAP filters look good, but in reality they require
a lot of code to implement and will not be used that much.  SLP is
"Service Location Protocol" not a directory or data access (LDAP and
friends).

> 3.2 Attribute Request
> 
>       3.2.1. Eliminate attribute requests by type.  Attribute requests
>       will be by service URL only.

Yes.

>       3.2.2. Eliminate wild cards in attribute request search filters.
>
>       Attribute requests for service by type have proven difficult to
>       implement and interpret.  This feature should be deprecated.

Yes.  Usage of SLPFindAttrs() is usually found in situations where
developers already know what attributes they will be looking for.  In
the case of a service browser, requesting all attributes (empty search
filter) is usually what is desired anyway.

> 3.3 DA Discovery

>        3.3.1. Recommend that DAs do mesh enhancement [7].

>      Mesh enhanced DAs add very little complexity to DAs.  If even one
>      is present in a given scope, a SA does not need to keep track of
>      other DAs in that scope.  Forwarding to the mesh enhanced DA will
>      effectively cause a registration to be forwarded to all DAs in
>      that scope.

Agreed. 

> 3.4 Transport
>
>        3.4.1. Propose a new Exclusion List Extension.  This could be
>        used instead of PR Lists.
>
>      An Exclusion List tells a SA or a DA not to respond to the
>      requester (identified by their address, source port number and XID
>      of the request) for a some period of time.  This scales to far
>      more hosts than a PR list, since successive requests can be
>      issued.
>
>      One problem is that some authentication is required in order to
>      prevent a trivial denial of service attack.
>
>      Another problem is that not all SAs and DAs will support this
>      option unless it is required.  In that case, PR lists would still
>      be needed.

I do not support the Exclusion List Extension for the reasons listed,
but also because DAs and scopes already offer a scaleability solution . 
I do not think we could expect SLPv2 to scale in pure multicast or
broadcast operation even with exclusion lists.

> 3.5 Scope Configuration
>
>        3.5.1. Deprecate MANDATORY flags in RFC 2610.

Yes, Please.

>        3.5.2. Use nested scopes in MADCAP [5] for scope config.  SAs
>         and DAs join all groups at the top of each nested scope
>         (address range).  They advertise all scopes by the name
>         received in the MADCAP Nested Scope Option [6].

O.K.

>        3.5.3. The simplified scope configuration list would be in
>         decreasing order of preference
>                Pref   Feature                           Requirement 'mode'
>                 1)    static configuration of scope list  MUST
>                 2)    static configuration of DAs*        MUST
>                 3)    dhcp configuration                  SHOULD
>                 4)    dhcp configuration of DAs*          SHOULD
>                 5)    MADCAP / scope configuration        SHOULD
>                 6)    dynamic discovery (DAAdverts)**     MAY
>                 7)    dynamic discovery (SAAdverts)**     MAY
>                 8)    Use of the scope "default"          MUST
>
>      The higher item on the list always takes precedence over the lower
>      items.  If no other configuration is supplied, a SLP Agent is
>      configured with the scope list "default".
>
>      * If a scope list is not configured (by through static configuration
>        or DHCP) but a list of DAs is, the SLP Agent MUST unicast a
>        SrvRqst for "service:directory-agent" to each of the DAs on the
>        list.  The SLP Agent is configured with the scope list which is the
>        union of all scopes supported by the DAs which respond with a DAAdvert.
>        If a DA on the configuration list does not respond, the SLP Agent
>        SHOULD try to send it a SrvRqst again periodically (like every 30
>        minutes).  Once a DAAdvert is received, the scope list MAY be
>        expanded and the # of DAs known of by the SLP Agent increases.
>
>      **Dynamic discovery of scopes MAY be used by User Agents and
>        MUST NOT be used to configure Service Agent or Directory Agent
>        scope lists.

>      The problem with the current scope rules is that they are overly
>      complicated.  This is largely due to the 'MANDATORY' bit in the
>      SLPv2 DHCP Option [9].  A clarification of how to do scope rules
>      using the current specifications shows just how hard it is [10].

>      Further, when SLPv2 was published, the Administrative Scoping BCP
>      [4] was available, but further specifications were not.  Now, with
>      MADCAP and the MADCAP Nested Scope Option it is possible to define
>      specific automatic scope configuration behavior.

Looks good.

> 3.6 Service Deregistration

>        3.6.1. Eliminate wild cards in the tag list for selective attribute
>         deregistration.

Yes, Please.

> 3.7 String Matching

>        3.7.1. Eliminate the requirement to elide white space in
>         requests.  If white space is included unintentionally
>         on registration or requests - that is an error.  Use
>         the templates literally (just don't add unwanted space).
>         This effects every message - scope lists, tag lists,
>         attribute lists, queries, and so on.
>
>      Eliding white space allowed requests to be 'sloppy' and still
>      match strings in registered by other servers.  In practice this
>      does not seem to be a problem since strings can be trimmed before
>      being registered or before requests are sent.  Many strings are
>      will have extra white space due to manual entry anyway.

Yes.  A little care on the part of developers would save a lot of code
in the SA and DA.

Matthew Peterson
OpenSLP Project Maintainer