Hi -
On 2021-09-10 9:57 AM, Andy Bierman wrote:
On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn
<randy_pres...@alumni.stanford.edu
<mailto:randy_pres...@alumni.stanford.edu>> wrote:
Hi -
On 2021-09-10 9:42 AM, Andy Bierman wrote:
> Hi,
>
> Maybe the use of [null] in RFC 7951 is confusing people
> https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
<https://datatracker.ietf.org/doc/html/rfc7951#section-6.9>
> <https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
<https://datatracker.ietf.org/doc/html/rfc7951#section-6.9>>
Are you suggesting that the type of this leaf should be a
choice of unit16 and empty? At least that wouldn't
have the ambiguity under access control Jürgen described.
No, but the access control issue applies everywhere so it is usually ignored
and assumed that the client can view all the server data. The client
could be
blocked from viewing the empty, so this choice does not help.
It removes the ambiguity. With the current design, a client cannot
distinguish between no-value-yet and blocked. With a choice, the
client can tell the difference. Whether that distinction matters
is a judgement call, and I understand the perspective that it's
easier to just ignore it in clients, regardless of how that might
affect the validity of the decisions they make.
I was just guessing at the source of the confusion that YANG has a null
value.
It does: empty. But just as in better-known syntaxes like ASN.1 one
still needs to use a choice type to make "null" a possibility beyond
the range of values represented by the other basic types. (A corner
cases might be things like empty strings, though I'd argue that
a zero-length string is quite distinct from no-string-at-all.)
Randy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
