Hi, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com> wrote: > 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.
Yes, unusual, but "safe" in the sense that a client that doesn't have code for this special case will just see the "mandatory true" and provide a value for the type as well. > 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. Right, but again this only happens for clients that know this special rule. > 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). In general, my reply is "no, that is not fine". The reason for this unusual design is that most existing systems code type-info into the name of an interface ("ethX", "ge-X/Y/Z", "GigabitEthernet-X/Y" etc), and having to provide the type in the name and in a special leaf would just be redundant and error prone. The thinking at the time was that the interface model that we designed had to adapt to how existing systems behave. > 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. Yes. But as long as this special handling is optional in the client I think it is ok. > 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'. Both these cases assume that the type can be derived from the name. > 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. The rule of thumb is to avoid server created config as much as possible. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod