Re: [babel] [netmod] NULL value for uint16

[Jürgen Schönwälder <[e-mail]>]

On Wed, Sep 15, 2021 at 01:01:11AM +0200, Carsten Bormann wrote:
> > If BBF already
> > defined to use -1, so be it.
> 
> That works for me and is consistent with the information model in 9046.
> 
> What I find not so great is the side effect of going from uint16 to int32.
> 
> I don’t see a big difference between
> Optional-uint16 = uint16 / -1
> and
> Optional-uint16 = uint16 / empty
> 
> I do not like
> 
> Optional-uint16 = int32

YANG leaves the bits business to the encodings. In YANG, you can of
course use

   type int32 { range -1 | 0..65535 }

and then its left to the encodings. Im XML/JSON, -1 is 16 bits and
65535 is 40 bits - and the name of the leaf is likely worse. I am too
lazy to lookup what the CBOR encoding would do with the range...

> > The alternative is to not instantiate the leaf if there is no value
> > and to accept that a client can't tell the difference between 'there
> > is no value' and 'the value has been suppressed by authorization'.
> 
> Interesting.  I wasn’t aware that this cannot be distinguished in YANG.

I have to correct what I wrote. Its the leaf that is suppressed, not
the value.

In XML, if <foo/> does not exist, the client gets nothing. If <foo/>
does exist (and it's value is empty in this example) and authorization
rules say 'don't tell the client', the client gets nothing. A client
not getting <foo/> can't decide whether there is no <foo/> because
<foo/> does not exist or authorization prevented access to <foo/>.

Authorization is not part of YANG. NACM started as an extension to
NETCONF in order to control access to data. Initially the acronym NACM
expanded to the 'NETCONF Access Control Model', RFC 6536.  The revised
NACM also works with RESTCONF (and likely other protocols) and hence
the acronym now expands to the 'Network Configuration Access Control
Model', RFC 8341.
 
> But an “empty” would be present if it is chosen, no?

You grant or restrict access to <foo/> and it does not matter what
type <foo/> has or which value <foo/> has (if it is a leaf) or whether
<foo/> is the root of a deeply nested tree (if it is a container).  If
a client has no permissions to read <foo/>, then <foo/> is silently
omitted.

Things are different if a client attempts to create/write/delete
<foo/>, in this case the client will get an explicit authorization
failure error. For the details, see RFC 8341.

/js

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