Subject: Re: SA daemon

From: [email-masked]
Date: Wed, 9 May 2001 11:12:45 -0700 (PDT)

Hi -

> From: Erik Guttman <[email-masked]>
> Message-Id: <[email-masked]>
> Date: Wed, 9 May 2001 09:41:21 +0-200
> To: "James Kempf" <[email-masked]>, <[email-masked]>,
>         <[email-masked]>
> Subject: Re: SA daemon
..
> Jim Kempf <[email-masked]> wrote:
> >I suppose we could look into standardizing the intra-machine protocol if
> >there was enough interest, but without a major customer requesting the
> >change, it is unlikely that any change will be made in Solaris SLP at
> >this point.
> 
> The IETF focusses on interoperability on the wire.
..

However, it has proven useful in some cases for the IETF to
specify (potentially) intra-machine protocols.  The AgentX work
(RFC 2741) is an appropriate example here.

> Application portability, that is binary compatibility of
> applications to libraries sharing the same API, is not an
> area of focus for the IETF.  Some APIs have been published
> by the IETF - for service to the community, but these are
> rarely standardized.  The SLP API is an example of an 
> 'informational' status API.  Aside from the GSSAPI and LDAP
> APIs I do not know of any other standards track APIs published
> by the IETF.

Standardizing (potentially intra-system) protocols is not
the same thing as standardizing an API.

> The kind of interoperability being discussed is entirely 
> different.  How do binary components, within a system, 
> communicate?  
..

This does not require API standardization.  AgentX works
quite well with no standard API.

>               This standardization occurs within desktop
> environments and operating systems - for example Gnome
> Bonobo components, OLE objects or drivers within an OS.  
> Even there, things get dicey.  Drivers and libraries 
> export a few very simple, standard features which can be 
> accessed through common administration applications,
> controlled by scripts, etc.  But the specialized behavior
> of the libraries (all optimizations, differentiators, 
> and so on) require vendor specific application utilities.

But do any of these arguments apply in this case?

> That is why, for instance, when you buy a printer for
> Windows, it often comes with its own print monitor and 
> job control utility (which makes use of bells and whistles
> added to the standard printer driver).

Is this a bug or a feature?

> I do not think this is a fruitful direction for us to 
> pursue.  I'll send another email with ideas about where
> I suggest directions for work on interoperability.
..

So the plan is to give up and effectively require systems
to either run multiple SLP daemons or build all applications
with the same vendor's library?  The SNMP community went
through that phase a decade ago.  We learned our lesson.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------