Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces

On Fri, Dec 14, 2018 at 9:53 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@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.
>
>
>
> 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.
>
>
>

I think NMDA says the "type" leaf is mandatory in <intended> not <running>.
I agree that YANG could be a lot more expressive about the auto-magic
server behavior
between <running> and <intended>. Any YANG client will see "mandatory true"
and
assume a value needs to be provided.

> Jason
>

Andy

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>