Hi all,
Cross posting because I'm not sure whether this is more of interest to NETCONF
clients or a general YANG & datastore question.
In IETF Interfaces there is a leaf 'type'. Here is a snippet of the model:
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"The type of the interface.
When an interface entry is created, a server MAY
initialize the type leaf with a valid value
This says that although the leaf is mandatory, a NETCONF client creating a new
interface does not have to specify/provide that leaf. That strikes me as the
first unusual point.
Secondly -> this also means that a NETCONF client may send a config with
elements X, Y, and Z, but then later read back the config to see X, Y, Z and T
(e.g. type). But they never configured the type leaf.
Shouldn't most clients generally assume that what they write, they read back
(unless there are 'choice' or 'when' statements involved of course, but that
are part of the YANG and any auto-clearing behavior from those would be
expected)?
Or does 'anything go' / 'market decides' when it comes to behavior like this
explained in 'description' statements?
Is it just fine that some NETCONF servers auto-magically create some (extra)
data nodes inside a list entry that a client created? (would like to see
opinions from multiple people on this - especially client developers).
I would think that each and every magic creation/deletion/changes done by a
server (i.e. that aren't part of the YANG, except perhaps part of a
human-readable (non-machine parsable) 'description' statement) would require
some special handling code on the client (or app above the client) side.
I can imagine several alternatives to the way it was modelled above:
1) NMDA approach: make the leaf optional. If the operator doesn't set that
leaf, then reading the conventional datastores doesn't return that leaf. But
reading the operational DS could return the actual system selected value.
2) separate config & state leafs for 'type': make the leaf optional. If the
operator doesn't set that leaf, then reading the conventional datastores
doesn't return that leaf. But have another state leaf called 'oper-type'.
I'm not proposing to re-open the IETF Interface model. Just using it to ask
questions about server created config data and explore alternatives.
Jason
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
