Re: [NGO] external module properties

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "David Harrington" <ietfdbh at comcast.net>
> To: "'Andy Bierman'" <ietf at andybierman.com>; "'NETCONF Goes On'" <ngo at ietf.org>
> Sent: Monday, April 28, 2008 11:27 AM
> Subject: Re: [NGO] external module properties
...
> It is important for an NMS to be able to tell which version of a data
> model is supported by a managed element, so when it makes changes to a
> configuration, it can make changes appropriate to the version
> supported.
> 
> On a side note, keep in mind that some managed elements may have
> multiple components, such as blades in a chassis, and the versions
> supported might differ, so a Netconf server might also need to know
> which version to use to perform validation.
...

This is a really important point to consider, and also a good reason why
something like "agent-capabilities" from SMI is probably not the answer.

There's a slightly different way of looking at the problem that might be
helpful.  One can introduce an abstraction I'll call a "compatibility class".
Two things are members of a compatibility class if they both have all the
characteristics of the compatibility class.  This lets of treat each version
of a class as distinct, and the compatibility class abstraction describes
the extent to which instances of the different versions of a class may
be managed in the same way.

Due to the asymetry of manager and agent requirements for tolerating
instance data from the "wrong" version, we might extend the notion
just a bit further.  Deliberately picking bad words, I'll call them the
"loose" and the "fussy" version compatibility classes.  The "loose" is
merely the union of the characteristics of all the versions, and the "fussy"
is the intersection.  Over time, as more features are added or deprecated
or obsoleted, exactly what each of these abstractions would entail will
change.  The ways in which they will change will be determined by what,
if any, rules exist controlling what can be changed from one version to
another of "the same" module.

The point of all this to encourage a little thought about what it *really* means
for instance data to correspond to various versions of "the same" specification.

Randy

_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo