Re: [yang-doctors] Style question from individuals working on IEEE YANG

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: Schönwälder, Jürgen <[e-mail]>
> Sent: 15 January 2020 21:19
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Martin Bjorklund <[e-mail]>;
> scott.mansfield=[e-mail]; [e-mail]
> Subject: Re: [yang-doctors] Style question from individuals working on
> IEEE YANG
> 
> On Wed, Jan 15, 2020 at 02:24:28PM +0000, Rob Wilton (rwilton) wrote:
> > Hi Martin, Juergen,
> >
> > For clarification, are you saying that you think that all operational
> lists should have a corresponding size leaf?
> 
> No. That was never my intention. If the size of a list is something that
> is needed frequently, then we should create a generic query mechanism,
> e.g., a get-leaf-count operation that returns the number of leafs in a
> subtree or something like that. (Note that there is also a subtle but
> important difference between leafs that exist and leafs that are
> accessible; it should actually be the number of leafs accessible; not sure
> this is what IEEE used to define).

The access control is an interesting consideration.

Another theoretical option would be a query parameter to add list size annotations.  This could seemingly work well for a CBOR or JSON encoding, but wouldn't necessarily work well for the XML encoding of YANG - in hindsight I wish that the XML encoding of YANG had included a tag to identify the entire list, rather than just tags for each element in the list.


> 
> > Note - I agree that they are unneeded and unhelpful in configuration.
> 
> It could also be helpful in configuration. I just wanted to make sure that
> configuration sizes and operationally used sizes can differ.

For configuration, I didn't want the problem of clients potentially providing conflicting values for the list size vs the number of entries configured.  E.g. configuring that the list has 10 entries, but then only providing 9.  I.e. I think that the number of list entries is implicit by counting the configured entries.


> 
> > Or for operational lists that are likely to be small (e.g. perhaps less
> than a dozen entries) then omitting a size leaf may be appropriate, i.e.
> forcing the client to request and count the list entries if a count is
> required.
> 
> Yes, it is a decision the modeler has to take. And this is why the size
> leaf really gets into conflict with fine grained access control since the
> result of retrieving foo-size and counting all of foo may not be the
> same...
> 
> If such sizes are needed frequently, then having something like a get-
> leaf-count operation is likely much less pain.

My hunch is that that they are potentially useful for:
 - lists that could potentially hold a large number of entries
 - Potentially fast changing data structures (e.g. counts of entries in various routing/forwarding tables, interface counts, etc).
 - resource usage (hardware or software)

I.e. I think that they are probably the exception rather than the rule.

Thanks,
Rob


> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>