Subject: RE: Reactions to draft-guttman-svrloc-slpv2bis-00.txt ???

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 28 Jun 2000 19:38:43 -0700

Hi James et al,

Dumb question - should we really be taking features we think
are (on balance) a mistake in RFC 26xx and _deprecating_
them instead of just _deleting_ them from the subsequent
RFCs.

In MIBs at least, the IETF has three statuses for MIB objects
(although they usually come and go as whole tables):

current - implement this object - everyone else should be too
deprecated - need not implement - except for backward compatibility
obsolete - do NOT implement this previously deprecated object 

I think we believe some of the features to be 'pruned' from
SLPv2 in moving to Draft Standard are really 'obsolete' - we
don't want people to implement them and we don't want other
implementations to waste code and time looking for them.

After a MIB goes to Draft Standard (or a protocol, I thought)
you are NEVER to supposed to actually 'obsolete' an object
or group AND you are NEVER to supposed to define any new
objects which are MANDATORY (options are OK).  But a number
of MIBs have simply dropped objects (leaving only an ASN.1
comment as a trace) in moving from Proposed to Draft Std.

Now if I'm all wet, tell me why.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, June 28, 2000 12:00 PM
To: Erik Guttman; Michael Day; [email-masked]
Cc: [email-masked]; Terry Lambert; Evan Hughes
Subject: Re: Reactions to draft-guttman-svrloc-slpv2bis-00.txt ???

Re. PR lists, I think we ought to either drop them or keep them. The 
Apple experience seems to be that they are of limited utility, so
I think dropping is probably the best solution. Or, rather, deprecating
them.

		jak
>
>Thanks for the excellent discussion.
>
>Please don't take this email as a 'working group chair's wrap up.'
>Keep the discussion going!  This is just my take on the discussion.
>
>
>1. Limiting search filters to '='
>
>   Your arguments that this would limit the utility of SLP for load
>   balancing are very strong.  Does anyone continue to think that
>   this should be dropped from SLPv2 (as a *required* feature)?
>   I now think this requirement should not be dropped.
>
>
>2. PR lists
>
>   There are several options here to explore:
>
>     2.1. Keep PR lists
>     2.2. Drop PR lists
>     2.3. Drop PR lists but add exclusion lists (as an SLP extension)
>          with a digital signature
>     2.4. Change the interpretation of PR lists so that SLPv2bis and
>          forward SA and DA implementations will keep state so that 
>          they won't reply to the same source address/source port/XID 
>          for the next 10 minutes (say).
>
>   > > > >  - Eliminate PR list support. [3.4.1]   
>   > > >
>   > > >  Wouldn't this cause a lot of spurious responses?
>   > > 
>   > > In networks with few nodes, it doesn't matter if there are
>   > > spurious responses.  In networks with many nodes, the PR
>   > > lists don't work anyway.
>   > 
>   > ???
>
>   If there are < 10 services of type T, who cares if there are spurious
>   responses.  SLP messages are pretty infrequently used (boot/app start 
>   time) and multiplying them all by 10 doesn't add up to much on even 
>   1MB links.
>
>   If there are > 100 services of type T, PR lists don't adequately 
>   filter anyway.
>
>   So PR lists are really designed for suppressing repeated responses in
>   networks of 10-100 services of type T.  The thought was that the UA
>   would be overwhelmed by responses, not that there would be too many.
>   Even in the case of 100 services of type T, returning responses over
>   15 seconds to 3 successive multicast requests you have 3 multicast + 
>   100 unicast in the best case with PR lists and 3 multicast + 300 unicast
>   in the worst.  The question is:  Is the complexity of the variable
>   length headers and PR list handling code is worth saving those best
>   case 200 messages?
>
>   I think we could explore 2.4 above, as Mike Day suggested.  Existing
>   SLPv2 SAs and DAs would behave as expected (not replying if they are
>   on the PR list).  New SAs and DAs could filter out that request for
>   a period of time.  Then, a UA could issue a *different* PR list each
>   time and potentially suppress hundreds or thousands of responders
>   (provided they supported the new 'exclusion' rules).
>
>   Mike, can you comment on the success of PDS's exclusion lists?
>
>    
>3. Finding the 'best' service
>
>   This has been discussed in the past.  I think the thing to do is
>   to define a 'Best Server Extension' for SLP.  If the SLP SA or DA
>   supports it, the service reply will have only one service included
>   (and the 'Best Server Extension' so the UA will know it is the best
>   and not the only service.)  If the SA/DA doesn't support this option
>   then the UA can either get services & their attributes and grub
>   through them or do consecutive searches for the best one.  So we
>   wouldn't fix the legacy devices, but supply a forward path for
>   those which want better load balancing capabilities.
>
>
>Erik 
>---------------------------------------------------------------
> Public words and deeds have their own weight and significance 
> quite apart from private motives or secret calculation.
>   - Timothy Garton Ash
>

---

From: Erik Guttman <[email-masked]>
Date: Thu, 29 Jun 2000 12:06:02 +0200 (MET DST)

> them instead of just _deleting_ them from the subsequent

Actually that is what I am suggesting.  The deprecation idea
is only for the API to ease transition to the new protocol
functionality.  If we're going to drop any features, we will
simply delete them from SLPv2bis.

> implementations to waste code and time looking for them.

Agreed.
 
Erik