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

[Robert Wilton <[e-mail]>]

On 21/07/2016 19:40, Juergen Schoenwaelder wrote:
> 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"?
I'm not 100% sure.  I thought that there was a BGP model that was about 
to be published as an RFC standard that contains intended vs applied 
configuration split.  Possibly draft-ietf-idr-bgp-model-02.

>   What is actually an "applied configuration node"?
A config false node written in the schema with the sole purpose of 
indicating whether of not the configuration has been applied on the device.

For example, looking at the "bgp-common-neighbor-group-timers-config" 
grouping in draft-ietf-idr-bgp-model-02, then the uses statement 
instantiates it twice for the BGP peer group timers, once under a 
"config" (config true) container to hold the configuration, and also 
under "state" (config false) to solely represent whether the 
configuration has been applied.

>   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.
No, I'm not suggesting that.  I don't see that node as specifically only 
indicating whether the IP address configuration is applied, but instead 
represents the actual IP address in use by the system.


>
>> 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.
 From draft-ietf-netmod-opstate-reqs-04:

    Derived State:  This data represents information which is generated
        as part of the server's own interactions.  For example, derived
        state may consist of the results of protocol interactions (the
        negotiated duplex state of an Ethernet link), statistics (such as
        message queue depth), or counters (such as packet input or output
        bytes).


But in essence, I mean all config false nodes that are not "applied 
configuration nodes" (as per my example above).

>   And even then, why MUST derived
> state and statistics be in a separate tree?
My aim is to make the structure of the models consistent and 
predictable, with the specific aim of making it easier for tooling. If 
some IETF models are going to split configuration and state into 
separate trees (e.g. RFC 7723), then I'm suggesting that all IETF 
modules must have same structure.


>   And can we please avoid
> 'feature' and 'feature-state' since YANG uses the term 'feature' in a
> very different sense.
Yes, OK.

>
>> 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.
Potentially true.  But in the future, if we try to combine "foo-state" 
into "foo" for all IETF models then that would mean updating every 
published IETF YANG model.  Is that realistic?  I don't think that just 
changing some modules makes sense, neither does having two ways to do 
this.  I would rather have a single consistent approach that applied to 
all IETF (and hopefully other SDO) models.

>
> 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).
This is pretty much what I'm trying to say as well, but in a stronger 
way.  I.e. mandating that all IETF YANG models MUST follow this 
structure, and split config and state into two top level trees.

Rob

>
> /js
>