Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics

From: Randy Presuhn <[email-masked]>
Date: Fri, 3 Apr 2015 16:12:23 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Apr 3, 2015 3:08 PM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics
>
>On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn
><[email-masked]> wrote:
>> Hi -
>>
>>>From: Andy Bierman <[email-masked]>
>>>Sent: Apr 3, 2015 2:14 AM
>> ...
>>>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics
>> ...
>>>RESTCONF already has the 'content' query parameter that allows
>>>config, operational, or both.  This is good enough.
>>>It is trivial for you to add your own content filters to
>>>the RPC operations (if you want to prove that standards
>>>for more classifications are needed)
>>
>> I think you're setting a really low bar for "good enough,"
>> but recognize that this is a judgement call.
>
>
>>
>> As the number of aspects of interest grows, it becomes more
>> important that the models should have information allowing
>> their bits and pieces to be marked in some way so that
>> aspect-oriented operations become practical.  I'm not
>> suggesting that the route of the GDMO "PACKAGE" construct
>> is necessarily the way to go, but the need to be able to
>> factor definitions in this way has been recognized, if
>> not necessarily exploited, since at least the 1980's.
>>
>> Getting back to the start of this thread, there's an underlying
>> question of whether there should be some set of standardized
>> aspects, e.g. "statistics" or "performance", built into the
>> modeling environment (as config and operational, for example)
>> or whether the modeling language should provide a facility for
>> identifying new aspects, some of which might potentially
>> eventually be enshrined in standards-track specifications.
>>
>
>How are client tools expected to use the extra classifications?

They wouldn't have to.

>Do we expect operators and programmers to pick out
>the interesting child nodes for a given list or container,
>or do we expect applications to automatically select based
>on this extra classification?

I think one would see both, but obviously there's going to
be a point of diminishing returns to doing this sort
of thing.  Of course it'd be helpful for the folks
who believe they might  need something like this to spell
out just what they plan to do with it.

>Do we expect ETags for separate types of operational state to
>be maintained?  Caching data, pushing data, retrieval filters
>all need to be designed together to be efficient and useful.

Why do you say "separate" types?  If they were really separate,
a "structural" solution would probably be workable.  But the uses
of the various bits and pieces of information overlap, so a
given piece of data might fall into multiple classifications.

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 10 Apr 2015 10:17:19 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Apr 10, 2015 9:41 AM
>To: Andy Bierman <[email-masked]>
>Cc: Jürgen Schönwälder <[email-masked]>, Martin Björklund <[email-masked]>, Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
...
>Even if ephemeral config is declared as having higher priority,
>it can still happen that its combination with “normal” config
>is invalid.

That's an error in modeling, pure and simple.

>For example, running defines some RIBs, ephemeral defines
>other RIBs, each datastore satisfies all data model constraints

Model constraints do not completely define the behaviour of
anything other than "post-it" objects.

>but the joint list of RIBs may be invalid.

That's an error in defining how the "joint list of RIBs"
works, IMO.  An analogy would be a subroutine library.
Sure, all the modules might compile cleanly, and even
make it through lint, but that doesn't mean that, when
working together, there are no memory leaks.

> That’s why I think it is the combined effect of all
> “desired states” and other contributions to the operational
> state that have to be considered.

I think there's a conceptual sleight-of-hand here.
Certainly one would like configuration management
to result in systems that can always be brought to
to a desired state. But that's only true in an absolute
sense as long as the configuration management mechanism
effectively overrules all other inputs to the system.
As soon as one admits the possibility of information
sourced elsewhere overriding explicit configuration
data in determining the system state, one must retreat
to a less ambitious understanding of what "desired state"
really means.

Randy