Subject: Re: [netmod] config lists without keys (Y09) / non-unique leaf-lists (Y57)

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 2 Nov 2015 04:46:06 +0000

Hi,

Earlier today Mach and I were asking Lada if we could have a config list w/o keys for our use case and he pointed us to this thread.

This is exactly what we need. For some lists we don't need to operate on individual list members. We don't need to inject a member in front of another remember. All we need is to specify a list of entries, which could even be non-unique.

For example, we may want to configure a label stack used in a nexthop. The same label value could be used in different positions of the stack so the label itself could not be used as key. Typically we'd want to specify the entire stack from sctrach, and if a change is needed it'd be replaced entirely, or at most we may add/remove a label at the top or bottom of the stack.

With the current requirement of a key for a config list, we'd need to assign an artificial ID as the key for the list. That is really cumbersome and does not provide any value.

Hope this can be accepted and supported in the tools soon.

Thanks.
Jeffrey

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Nov 2015 09:21:39 -0800

On Sun, Nov 1, 2015 at 8:46 PM, Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi,
>
> Earlier today Mach and I were asking Lada if we could have a config list
> w/o keys for our use case and he pointed us to this thread.
>
> This is exactly what we need. For some lists we don't need to operate on
> individual list members. We don't need to inject a member in front of
> another remember. All we need is to specify a list of entries, which could
> even be non-unique.
>
>

This seems like a design decision you made in your implementation,
not a decision that is inherent in the data model design.
Some simpler apps might choose to replace everything in order
to change 1 leaf, and a more complex app might choose to patch
the data and only send the leaf that needs to be changed.

bulk-only operations are more appropriate for leaf-list than list.
I could see data-model decisions to limit a leaf-list to bulk operations,
but not a list.

Andy

> For example, we may want to configure a label stack used in a nexthop. The
> same label value could be used in different positions of the stack so the
> label itself could not be used as key. Typically we'd want to specify the
> entire stack from sctrach, and if a change is needed it'd be replaced
> entirely, or at most we may add/remove a label at the top or bottom of the
> stack.
>
> With the current requirement of a key for a config list, we'd need to
> assign an artificial ID as the key for the list. That is really cumbersome
> and does not provide any value.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>