Subject: Scope and DA configuration backwards?

From: James Kempf <[email-masked]>
Date: Fri, 10 Sep 1999 11:15:25 -0700 (PDT)

Mikael Pahmp's note about scope and DA configuration prompted me to thinking
more about the topic, and I think that it is exactly backwards.

Typically, configuration is done such that a local configuration
overrides a global one. For example, with X Windows, the local .xinitrc
file overrides the global one. Same with .login files in Unix. There
is no need to put some kind of indicator in the global configuration
to indicate that the local configuration takes precedence. This
allows individual configuration of particular users or machines to be
made without requiring every user or machine sharing the global configuration be 
locally configurated.

With SLP scopes and DAs, it's exactly backwards. Unless the global
mandatory byte is set in the DHCP option, the global configuration
always overrides the local one. And if the byte is set, then every
local machine must be configured.

It would seem to me as if we could simplify SLP scope and DA
configuration by changing it around as follows:

	static configured takes precedence over DHCP and no configuration
	DHCP takes precedence over no configuration
	Mandatory bytes are ignored
	
Obviously we can't make changes in this now, but perhaps we can clean
it up before it goes to draft standard.

		jak

---

From: "Roger Holm" <[email-masked]>
Date: Mon, 13 Sep 1999 11:37:22 -0600

Having struggled through all of the SLP scoping issues with SLPv1, which is even less clear on the use of scopes than SLPv2, we (at Novell) developed a DA/scope configuration policy similar to what you have suggested in this e-mail.   When we delivered our first implementation of SLPv1, RFC2610 had not been approved so we implemented the current draft of RFC2610 at the time.  In this draft (which ended up being quite different than RFC 2610) there was not a mandatory byte for scopes but there was a mandatory flag in the  DA option (option 78).  Our interpretation of the mandatory bit (and now mandatory byte in RFC 2610) was that, if set, the DHCP information took precedence over static configuration.  Otherwise, static configuration took precedence over DHCP configuration information.  We are now extending our current scoping/DA configuration policy to support RFC2610 as follows:  

1) DHCP configuration with the mandatory byte set takes precedence over static configuration, 
2) static configuration takes precedence over DHCP configuration without the mandatory byte set,
3) DHCP configuration without the mandatory byte set takes precedence over dyanimically  discovered scopes and DAs,
4) dynamically discovered DAs and scopes are used in the abscence of the above

It seems to me that this gives you the best of both worlds.  If an administrator wants absolute control, they set the mandatory byte to override all static configuration.  Otherwise, they can distribute scope and DA configuration information through DHCP without the mandatory byte set which then allows local configuration to override the global configuration as needed.  This approach has been acceptable to our customers who use DHCP extensively to configure their SLP nodes.

In my implementations of SLP for the Microsoft platforms (Win9x,WinNT) what I have described above holds strictly true for the configuration of DAs and generally true for scopes.  Applying the precedence rules indicated above to determine which DAs to use is very straightforward.  But scopes are an animal of a different sort.   In order to provide the plug-n-play capabilities afforded by SLP with minimal user configuration I have adopted the following philosophy concerning the use of SLP.  Each SLP node (any system with a UA, SA, or both) participates in an SLP community defined by its known scopes.  Unless configured otherwise, SAs and UAs use the same scope list for advertising and locating services through SLP.  This is based on the assumption that any service made known through SLP is of interest to everyone in the SLP community.  The model works well for the small "mom and pop" shops where plug-n-play is extremely important and valuable.  We have found this to be very tru!
e for NetWare 5 and our small business products.  I believe it is also true for devices that ordinarily don't and shouldn't require customer configuration to operate in the network such as printers, embedded devices, etc.  

As a result of this approach, the administrative task of controlling the dissemination and discovery of service information then focuses on controlling the scope list available to SAs and UAs.   In a native, unconfigured setup, SLPv1 UAs and SAs would operate unscoped and SLPv2 UAs and SAs would use the DEFAULT scope.  Larger installations may want to better control the scopes available to an SLP node and thus customize the node's SLP community. The mechamisms we have discussed above can all be used independenty or in combination to accomplish this.  But in general, I think the SAs and UAs would still use the same scope lists to again promote and preserve plug-n-play as much as possible.  This allows the SAs and UAs to determine the scope list for the environment at run time and to operate without any user intervention or setup at the device.  It is also possible that, depending on the type of SLP system (i.e., server vs. client vs. device), greater control may be warranted on!
 a per system basis where services should be registered.  We have had customers that wanted to establish a heirarhcy of scopes (e.g. global services vs. local services) or to limit a specific service to a specific scope or set of scopes.  This requirement is mostly at server type systems where there are fewer of them and which normally require system configuration anyway.  For these customers we have provided static configuration mechanisms that allow the adminatrator to control what service types are registered in what scopes.  

Now back to the point about scopes being a animal of a different sort.  Scopes can be obtained from a variety of sources.  Therefore, an SLP node's community (as defined by its scopes) is also determined by a variety of sources (configuration, DHCP, DAs) and is a composite of all sources.  This becomes particularly apparent when one considers a multi-homed SLP node that is connected to totally separate networks.  On one network, the scopes may be configured through DHCP while on another network the scopes are discovered from the DAs it is configured to use on that network.  Not all scopes are applicable to all networks, yet the SLP node's community consists of all scopes from all networks.  So the heirarchy suggested above is not so cut and dried as it is for which DAs on a given network you will use.  As a result of all of this, I tend to view all scopes from all sources equal from the prespective of an API or user of SLP.  It is then up to the SA or UA to register services w!
ith the proper scopes on the correct network, or issue SLP requests for the correct scopes on the appropriate network.  This is the current scheme I have settled on and implemented to minimize the configuration of SLP nodes (particularly workstations and devices) .  

We (Novell) know from our own experience and working with customers that having to configure each SLP node is not acceptable (particularly workstations and devices) .  As a result, I have settled on and implemented the configuration precedence scheme I have described  above for scopes and DAs.  Of course, this was done mostly through experience with SLPv1, so if there must be a dramatic change for SLPv2 this could be changed, but I will need further convincing.

Hope my experience at least adds some food for thought.

Roger Holm
Novell, Inc,
[email-masked]

>>> James Kempf <[email-masked]> 09/10/99 12:15PM >>>

	

		jak

---

From: Mikael Pahmp <[email-masked]>
Date: Mon, 13 Sep 1999 21:48:57 +0200

Roger, thanks for this thorough information, again. Please see my comments and questions below.

/Mikael

> -----Original Message-----
> From: Roger Holm [mailto:[email-masked]]
> Sent: den 13 september 1999 7:37 
> To: [email-masked]; [email-masked]
> Subject: Re: Scope and DA configuration backwards?
> 
> 
> Having struggled through all of the SLP scoping issues with 
> SLPv1, which is even less clear on the use of scopes than 
> SLPv2, we (at Novell) developed a DA/scope configuration 
> policy similar to what you have suggested in this e-mail.   
> When we delivered our first implementation of SLPv1, RFC2610 
> had not been approved so we implemented the current draft of 
> RFC2610 at the time.  In this draft (which ended up being 
> quite different than RFC 2610) there was not a mandatory byte 
> for scopes but there was a mandatory flag in the  DA option 
> (option 78).  Our interpretation of the mandatory bit (and 
> now mandatory byte in RFC 2610) was that, if set, the DHCP 
> information took precedence over static configuration.  
> Otherwise, static configuration took precedence over DHCP 
> configuration information.  We are now extending our current 
> scoping/DA configuration policy to support RFC2610 as follows:  
> 
> 2) static configuration takes precedence over DHCP 
> configuration without the mandatory byte set,
> 3) DHCP configuration without the mandatory byte set takes 
> precedence over dyanimically  discovered scopes and DAs,

In the case where scopes are not configured at all but DAs are, do you decide the SA's/UA's scopes as those of the configured DA's or do you resolve to DEFAULT or empty scope?

> 
> It seems to me that this gives you the best of both worlds.  
> If an administrator wants absolute control, they set the 
> mandatory byte to override all static configuration.  
> Otherwise, they can distribute scope and DA configuration 
> information through DHCP without the mandatory byte set which 
> then allows local configuration to override the global 
> configuration as needed.  This approach has been acceptable 
> to our customers who use DHCP extensively to configure their 
> SLP nodes.
> 
> In my implementations of SLP for the Microsoft platforms 
> (Win9x,WinNT) what I have described above holds strictly true 
> for the configuration of DAs and generally true for scopes.  
> Applying the precedence rules indicated above to determine 
> which DAs to use is very straightforward.  But scopes are an 
> animal of a different sort.   In order to provide the 
> plug-n-play capabilities afforded by SLP with minimal user 
> configuration I have adopted the following philosophy 
> concerning the use of SLP.  Each SLP node (any system with a 
> UA, SA, or both) participates in an SLP community defined by 
> its known scopes.  Unless configured otherwise, SAs and UAs 
> use the same scope list for advertising and locating services 
> through SLP.

Are you using DA and SA discovery for both UAs and SAs to determine these scopes?
Couldn't you just have used 'DEFAULT'/empty scope?

> This is based on the assumption that any 
> service made known through SLP is of interest to everyone in 
> the SLP community.  The model works well for the small "mom 
> and pop" shops where plug-n-play is extremely important and 
> valuable.  We have found this to be very true
> for NetWare 5 and our small business products.  I believe 
> it is also true for devices that ordinarily don't and 
> shouldn't require customer configuration to operate in the 
> network such as printers, embedded devices, etc.

I agree on that for small networks, where as for large networks, the administrator should be able to provision which users see which of the small devices. I believe the future will be full of small devices. At least that is what Axis lives for.

> 
> As a result of this approach, the administrative task of 
> controlling the dissemination and discovery of service 
> information then focuses on controlling the scope list 
> available to SAs and UAs.   In a native, unconfigured setup, 
> SLPv1 UAs and SAs would operate unscoped and SLPv2 UAs and 
> SAs would use the DEFAULT scope.  Larger installations may 
> want to better control the scopes available to an SLP node 
> and thus customize the node's SLP community. The mechamisms 
> we have discussed above can all be used independenty or in 
> combination to accomplish this.  But in general, I think the 
> SAs and UAs would still use the same scope lists to again 
> promote and preserve plug-n-play as much as possible.  This 
> allows the SAs and UAs to determine the scope list for the 
> environment at run time and to operate without any user 
> intervention or setup at the device.  It is also possible 
> that, depending on the type of SLP system (i.e., server vs. 
> client vs. device), greater control may be warranted on
> a per system basis where services should be registered.  We 
> have had customers that wanted to establish a heirarhcy of 
> scopes (e.g. global services vs. local services) or to limit 
> a specific service to a specific scope or set of scopes.  
> This requirement is mostly at server type systems where there 
> are fewer of them and which normally require system 
> configuration anyway.  For these customers we have provided 
> static configuration mechanisms that allow the adminatrator 
> to control what service types are registered in what scopes.  

From this, together with our experience I conclude the following:

Administrators
- want to provision which users see which services (e.g. to
  reduce user's overload of information in large networks).
- want to override global DHCP configuration with local static
  configuration (e.g. to handle exceptions to the rule).
- want to override local static configuration with global DHCP
  configuration (e.g. when deploying DHCP the first time).
- want to assign DA addresses and turn off DA Discovery for
  UAs/SAs on non multicast-enabled networks.
- don't want to do configuration (e.g. small networks, in the
  home). UAs should automatically detect all SAs.

> 
> Now back to the point about scopes being a animal of a 
> different sort.  Scopes can be obtained from a variety of 
> sources.  Therefore, an SLP node's community (as defined by 
> its scopes) is also determined by a variety of sources 
> (configuration, DHCP, DAs) and is a composite of all sources. 
>  This becomes particularly apparent when one considers a 
> multi-homed SLP node that is connected to totally separate 
> networks.  On one network, the scopes may be configured 
> through DHCP while on another network the scopes are 
> discovered from the DAs it is configured to use on that 
> network.  Not all scopes are applicable to all networks, yet 
> the SLP node's community consists of all scopes from all 
> networks.  So the heirarchy suggested above is not so cut and 
> dried as it is for which DAs on a given network you will use. 
>  As a result of all of this, I tend to view all scopes from 
> all sources equal from the prespective of an API or user of 
> SLP.  It is then up to the SA or UA to register services
> with the proper scopes on the correct network, or issue SLP 
> requests for the correct scopes on the appropriate network.  
> This is the current scheme I have settled on and implemented 
> to minimize the configuration of SLP nodes (particularly 
> workstations and devices) .  

You've certainly thought this through. Sounds like a solid work.

> 
> We (Novell) know from our own experience and working with 
> customers that having to configure each SLP node is not 
> acceptable (particularly workstations and devices) .  As a 
> result, I have settled on and implemented the configuration 
> precedence scheme I have described  above for scopes and DAs. 
>  Of course, this was done mostly through experience with 
> SLPv1, so if there must be a dramatic change for SLPv2 this 
> could be changed, but I will need further convincing.
>