FW: RFC3535 question/clarification

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

FYI

Thanks,
Bert 

-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: vrijdag 12 september 2003 5:55
To: nm-ws@ops.ietf.org
Subject: Re: RFC3535 question/clarification


Hi -

> From: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>
> To: <rja@extremenetworks.com>
> Cc: <bwijnen@lucent.com>; <nm-ws@ops.ietf.org>
> Sent: Thursday, September 11, 2003 9:11 AM
> Subject: Re: RFC3535 question/clarification
>

>
> >> Bert wrote:
>
> >> They are thinking to have 2 operations:
> >>
> >> - get-config - get-all
> >>
> >> The first would return just configuration data the second would
> >> return all data (config, state, possibly stats)
> >>
> >> Would that be sufficient separation?
>
> >>>>> RJ Atkinson writes:
>
> Ran> Speaking for myself only, I'd beg for adding the 3rd & 4th
> Ran> operations.  In particular, I suspect get-statistics is likely
> Ran> the most frequently used operation (e.g. every N minutes on a
> Ran> given interface or device).
>
> Ran> Proposed additions: - get-state - get-statistics
>
> Not sure what is being discussed at the interim, but I think it is
> valuable to be able to distinguish between config, state and
> stats. Whether this distinction is bound to different operations or
> communicated in another form is IMHO a design issue. In fact, I can
> envision situations where I want config and state but no stats in
> order determine why a box behaves as it does.
>
> But then, my understanding of these terms might be different from
> yours. ;-)
...

I'm agree with Juergen and Ran, and would like to remind folks of an
extremely useful concept from an ancient protocol and its SMI: attribute groups.
The idea is that one can associate a label with a particular
semantic ("statistics" or "configuration"), and that, in conjunction with a class
definition, (as well as in the definition of the group itself) one can say that
specific attributes of instances of a class are members of a particular group.

This concept is helpful at a protocol level: instead of building the
groupings into the protocol, one simply needs a way to say
"get <group-name>" , with the result containing the appropriate
attribute/value tuples (or however the bits and pieces are structured).
It also has the very nice property of accomodating those pieces of information
that arguably belong in more than one group, e.g., bits that are used for
both configuration and active control.

Randy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>