Subject: Also: RFC2610bis

From: Erik Guttman <[email-masked]>
Date: Wed, 20 Sep 2000 09:55:55 +0200 (MET DST)

I want to collect a list of issues with RFC 2610.  If there are
enough of them, we should issue a draft rfc2610bis and advance
it to Proposed Standard to obselete the old, flawed document.

We have already discussed changes to RFC 2610:

 . The MANDATORY bit MUST be set to 0.

This simplifies the scope assignment rules immensely and it is 
hard to justify overriding local static configuration if it exists.

Stuart Cheshire brings up further issues with RFC 2610:

> When we talked on the telephone, I thought you were very clear that DHCP 
> option 79 gives a list of scopes to register in, and SAs MUST register in 
> ALL scopes in that list.
> 
> However, reading RFC 2610, I don't think this is made clear:
> 
> >   option provides an assignment of scope for configuration of SLP User
> >   and Service Agents.
> 
> This says that the option gives the list to be used by User AND Service 
> Agents.
> 
> >   The scope list is a comma delimited list which indicates the scopes
> >   that a SLP Agent is configured to use.

All we say in RFC 2610 is that option 79 specifies the list of scopes
to configure UAs and SAs with.  You have to look at RFC 2608 to find 
out what you do with that configuration:

Section 6, "Required Features", Page 13:

   A UA MUST issue requests with one or more of the scopes it has been
   configured to use.
   ...
   The SA MUST register all its services with any DA it discovers, if
   the DA advertises any of the scopes it has been configured with.

> Again, doesn't specify which kind of agent? What about DAs? Are they 
> configured from this list? Can they ignore it? Can they ignore it if the 
> 'mandatory' byte is set? A DA is a kind of "SLP Agent", right?

It was believed, at the time of writing RFC 2610 that DAs would not be
configured automatically - they would be assigned scopes as static 
configuration.
 
> >   A SLP Service Scope Option which indicates a Length of 1 (in other
> >   words, omitting the <Scope List> string entirely) validly configures
> >   the SLP User Agent to use "User Selectable Scopes."
> >
> >   Note that this configuration is tantamount to removing all
> >   centralized control of the scope configuration of hosts on the
> >   network.  This makes it possible for every User Agent to see every
> >   service.  This may not be desirable as users may not be able to or
> >   desire to decide which services are appropriate for them.
> 
> This strongly implies that the Service Scope Option gives the list of 
> scopes a UA can browse, not the list for an SA to register in.
> 
> Did I misunderstand you?

No.  When the scope list is empty in option 79, the UA or SA is told 
to build up a list of scopes however it can.  For example, listening
to DAAdverts and using the scopes in them, or for a UA, requesting
SAAdverts to determine the list of scopes they support.

There are some problems with this approach:  Say a SA does DA discovery
(or gets a list of DAs from DHCP Option 78) and aggregates a list of
scopes available on the network.  Which scopes should the SA support?
All of them?  That's not a very good idea - we have scopes for grouping
services together, not lumping them all together.  Some of them?  Then
there has to be some mechanism for a user or administrator to do that
selection.  

A further problem is what if a host discovers a scope on the network
and that scope is no longer supported?  For example, a UA on a network
with no DAs can multicast a request for "service:service-agent" and 
get back a set of SAAdvert messages.  Using these messages, the UA can
build up a list of supported scopes.  One SA, in scope "command center",
goes down after a few minutes.  Requests to this scope will find no
services.  Should the UA retain this scope configuration in this case?

All that being said, allowing flexibility to the implementor of hosts
is very important.  All we say is - if DHCP option 79 is used, it will
configure UAs and SAs with a list of scopes they have to use.  UAs MUST
use one or more of them in requests, SAs MUST use them all for registering.
If option 79 is 'empty' we leave it open which of the remaining mechanisms
the host uses to configure the scope list, and how some subset of that
list is selected.

Should we say more?  Is the set of rules we've agreed to in SLPv2bis
sufficient, or does it need to be updated?

http://www.ietf.org/internet-drafts/draft-guttman-svrloc-slpv2bis-01.txt

   3.5 Scope Configuration

        3.5.1. Deprecate MANDATORY flags in RFC 2610.

        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].

        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.

Erik