Re: [Rtg-yang-coord] Operational State Modeling

On Wed, May 13, 2015 at 3:35 AM, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, May 13, 2015 at 12:51:41AM -0700, Anees Shaikh wrote:
>>
>> Regarding compatibility with existing models, I really don't agree at all
>> that the existing RFC models should constrain what we do when trying to
>> meet the requirements of people trying to build real systems that use YANG
>> models.    With all respect to the authors of those few models (which we
>> leverage considerably in our models), YANG models are software code, and
>> should be treated as such IMO.  We don't say that software is "done" and
>> can't change -- it evolves and improves over time, sometimes in
>> non-backward-compatible ways.  And we don't issue a final version of
>> software without considerable experience using and testing it in production.
>>
>
> Standards and software are not the same. The value of standards is
> that they provide a stable basis. In other words, the value of
> standards is that they do not change every other day. Yes, you can
> rewrite standardized data models but the cost of doing so is high and
> hence the benefit of rewriting something must be high. I do not see
> this here - not even remotely.
>

+1

YANG already has a config-stmt to identify configuration nodes.
Extra non-presence containers throughout the data model
for "config" and "state" adds clutter and extra complexity.

Replication of data nodes increases implementation costs.
The association between "turn a config knob here" and
"observe a state change there" is usually more complex than
this draft supports.

> /js

Andy

> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord