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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
