Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote:
> Hi,
> 
> So after the various meetings and discussions this week, I think that the
> most important thing for IETF to do is to publish reviewed YANG models
> quickly, with the understanding that it is better to publish imperfect
> models than to end up not publishing any models at all.  This is with the
> understanding that these models could be fixed by subsequent RFCs if
> required.
> 
> So, I effectively support Acee's solution (2).  But to state this more
> precisely, I would suggest that the specific guidance should be:
> 1) IETF Models MUST NOT have a split for applied configuration leaves.  All
> IETF models that have not been turned into RFCs must be modified to remove
> any applied configuration nodes.  Any models that have this convention in
> RFCs should be revised to follow a consistent intended/applied convention
> for IETF models.  [The justification here is that IETF standard models have
> to be able to assume that the applied configuration will be available via a
> separate applied configuration (or operational state) datastore or
> equivalent mechanism.]

Are there any published models that have "applied configuration
nodes"?  What is actually an "applied configuration node"? Perhaps an
example helps: Are you trying to suggest that

  /if:interfaces-state/if:interface/ipv4/address/ip

is now made illegal and we have right now no way to represent
operationally used IP addresses? That sounds somewhat broken to me.

> 2) All IETF Models MUST put "derived state and statistics" into a separate
> namespace from the configuration (i.e. top level "feature" and
> "feature-state").  The two trees must be as structurally similar as
> possible, sharing the same paths, node names (except the top level node),
> using the same lists keys where appropriate, etc.*

Not sure what exactly drived state is. And even then, why MUST derived
state and statistics be in a separate tree? And can we please avoid
'feature' and 'feature-state' since YANG uses the term 'feature' in a
very different sense.

> 3) Both of these rules should be written into rfc6087bis.  We should then
> get this guidelines document finished as quickly as possible at the highest
> priority, and use that as the definitive guideline for the modules that the
> working groups are working on.
> 
> * Note, I chose this option not because I think that it is elegant (because
> I don't) but because it seems to me that it is the only pragmatically option
> that we have available.  The alternatives appear to be: (i) we wait another
> year before publishing any models (if ever), or (ii) we publish models that
> no-one can use today without violating the existing RFCs, or (iii) we end up
> with a hybrid mess without any consistency.

I do not see how the proposed rules achieve the goals you stated. Again,
examples may help:

  /if:interfaces-state/if:interface/ipv4/address/ip

This can be implemented today. It may not be necessary anymore some
time in the future if we have a revised datastore model plus matching
solutions. The upgrade path from this is, however, extremly simple:
We change the status of the definition of this object to deprecated.

Bottom line: I think we should continue to follow the model used by
the ietf-interfaces model and the ietf-ip model until we have a better
solution in place (and subsequently we can deprecate objects that
became redundant).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>