Subject: [netmod] NULL value for uint16

From: tom petch <[email-masked]>
Date: Fri, 10 Sep 2021 11:56:22 +0000

Does NULL have any meaning for a leaf of type uint16?

Looking at a leaf of type uint16 the description says that 
'This metric will be NULL (no value) ..'

Some languages differentiate  a 'never been set' state from e.g set to zero or some other value but for me, YANG does not have that concept.  Rather the leaf does not exist which  will be reflected by the protocol accessing the leaf.

I see no NULL at least in this context in RFC7950.

Tom petch

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 10 Sep 2021 14:14:30 +0200

I guess the description should be worded as

  "This leaf does not exist if ..."

instead of talking about NULL, a concept that does not exist in the
YANG language and the protocols.

One subtle point with the "does not exist" approach is that a client
cannot reliably distinguish between 'a leaf does not exist' and
'access to a leaf was denied by an authorization policy'. In practice,
though, most authorization policies tend to be rather coarse grained.

/js

On Fri, Sep 10, 2021 at 11:56:22AM +0000, tom petch wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Sep 2021 14:18:12 +0200

> 'This metric will be NULL (no value) ..'

Without the context, I'd guess it means that the value isn't set and has
no default. As you wrote, YANG has no NULL.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: tom petch <[email-masked]>
Date: Fri, 10 Sep 2021 16:06:14 +0000

From: Jürgen Schönwälder <[email-masked]>
Sent: 10 September 2021 13:14

<tp>

Juergen, Lada

Thank you for the prompt responses.  This is an I-D that has been to the IESG although the announcement has yet to appear, which makes me coy about saying which it is:-)  My inclination is to let sleeping dogs lie and see what comes out of the RFC Editor (probably the same as went in: but if you think it significant enough, I would flag it to the WG Chair:-(

Tom Petch

/js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 10 Sep 2021 18:18:54 +0200

The RFC editor is not going to fix this, for them it is beyond
editorial. For me it makes sense to report this, let alone to spread
the word that there is no NULL in YANG land. Sure, things like this
should be catched earlier but things are as they are and a late fix
is still better than publishing questionable examples.

/js

---

From: tom petch <[email-masked]>
Date: Fri, 10 Sep 2021 16:26:30 +0000

From: Jürgen Schönwälder <[email-masked]>
Sent: 10 September 2021 17:18
To: tom petch
Cc: [email-masked]
Subject: Re: [netmod] NULL value for uint16

<tp>

OK will do.

Tom Petch
/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Sep 2021 09:42:14 -0700

Hi,

Maybe the use of [null] in RFC 7951 is confusing people
https://datatracker.ietf.org/doc/html/rfc7951#section-6.9

Andy

On Fri, Sep 10, 2021 at 9:26 AM tom petch <[email-masked]> wrote:

> > Thank you for the prompt responses.  This is an I-D that has been to the
> IESG although the announcement has yet to appear, which makes me coy about
> saying which it is:-)  My inclination is to let sleeping dogs lie and see
> what comes out of the RFC Editor (probably the same as went in: but if you
> think it significant enough, I would flag it to the WG Chair:-(
> >
> > Tom Petch
> >
> > /js
> >
> > > Some languages differentiate  a 'never been set' state from e.g set to
> zero or some other value but for me, YANG does not have that concept.
> Rather the leaf does not exist which  will be reflected by the protocol
> accessing the leaf.
> > >

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 10 Sep 2021 09:47:14 -0700

Hi -

On 2021-09-10 9:42 AM, Andy Bierman wrote:
> <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.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Sep 2021 09:57:25 -0700

> 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.

I was just guessing at the source of the confusion that YANG has a null
value.

Randy
Andy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 10 Sep 2021 10:33:21 -0700

Hi -

On 2021-09-10 9:57 AM, Andy Bierman wrote:
> 
> 
> On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi -
> 
>      > <https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
>     <https://datatracker.ietf.org/doc/html/rfc7951#section-6.9>>
> 
> and assumed that the client can view all the server data. The client 
> could be

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 

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 Sep 2021 13:40:03 -0400

Tom,

okay, you made me look...

The full text is

          leaf received-metric {
            type uint16;
            description
              "The metric with which this route was advertised by the
               neighbor, or maximum value (infinity) to indicate the
               route was recently retracted and is temporarily
               unreachable. This metric will be NULL (no value) if the
               route was not received from a neighbor but instead was
               injected through means external to the Babel routing
               protocol. At least one of calculated-metric or
               received-metric MUST be non-NULL.";

and it references an RFC that says:

       This is a 16-bit unsigned integer;
       if the data model uses zero (0) to represent NULL values for
       unsigned integers, the data model MAY use a different data type
       that allows differentiation between zero (0) and NULL.

So, in context I read it as saying NULL = 0

While I think the phrasing *is* problematic if the definition of NULL 
was expected to be yang, the reference points to a relevant definition 
of NULL.  So, in this context, I'm not sure I see a substantive issue 
that *needs* to be fixed.  I do think this is something for the yang Drs 
to keep an eye out for  and perhaps avoid possibly confusing language in 
the future.

Lou (as contributor)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 10 Sep 2021 22:09:02 +0200

>       that allows differentiation between zero (0) and NULL.

We are talking about RFC 9046? RFC 9046 repeats this sentence several
times but I find it difficult to infer the intended meaning. If 0 is a
legal value, you can't have it represent "NULL" at the same time.

In YANG, we tend to not instantiate leafs that do not have a value.
Anyway, if a YANG author wants to report a special value to indicate
that there is no value, then you have design for it and reserve and
set aside a special value from the number space or use a union.

RFC 9046 uses the same text for things like sequence numbers. Skimming
RFC 8966, it seems sequence numbers are 16-bit integers:

   Sequence numbers (seqnos) appear in a number of Babel data
   structures, and they are interpreted as integers modulo 2^(16).

The text in the context makes me believe they are an unsigned 16-bit
integers. If so, there simply is no way to use 0 to indicate that a
sequence number is absent. The problem really might be the text in RFC
9046.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Sep 2021 10:17:48 +0200

> I was just guessing at the source of the confusion that YANG has a null

This shouldn't be too confusing, as that "null" in JSON encoding is also wrapped in an array. This was done exactly because otherwise some programming languages (JavaScript) don't make distinction between null values and missing properties.

Lada

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Sep 2021 10:25:11 +0200

> On 2021-09-10, at 22:09, Jürgen Schönwälder <[email-masked]> wrote:
> 
> We are talking about RFC 9046?

Well…

SECDIR Last Call Review (of -11): Has Issues 
RTGDIR Last Call Review (of -11): Ready 
GENART Last Call Review (of -11): Ready 
RTGDIR Early Review (of -03): Has Issues 
OPSDIR Last Call Review - due: 2020-10-27

(Don’t want to point at specific people, because I’m much worse when it comes to finishing my reviews.)

> RFC 9046 repeats this sentence several

Note that the document provides an information model, which yet has to be translated into YANG or some other data modeling language.

(Which once again points to the danger of making up information modeling schemes as you go.  Section 1.2 does not define NULL, but clearly, it defines optional properties, and one can infer that NULL is their way to talk about an absent optional property.)

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Mon, 13 Sep 2021 09:12:57 +0000

From: Jürgen Schönwälder <[email-masked]>
Sent: 10 September 2021 21:09

<tp>

Lou, Juergen,

Thank you for doing my homework for me.  I should have dug deeper before my first post but it was late on Friday afternoon and I was having a really bad time with webmail and a replacement PC that only wants to do Social Media, (or so it still seems to me - I have just had another battle).

Anyhow, you are spot on with what I was alluding to.   I missed RFC9046 in Last Call unfortunately.  It is Informational which is one problem I see but do think that this reference to Null is another.  For me, the wording starts assuming that the concept of Null exists in  a language and can be represented as distinct from zero which is fine in some languages.  My first post was checking out  my understanding that YANG is not such a language which you have confirmed for me.  I then read RFC9046 as requiring a different approach, such as a union so, for me, RFC9046 is fine until the DDL is YANG, then treating zero as Null is wrong,, a different approach is needed, so it is the data model I-D that is at fault IMHO.  I have posted to the WG list but see no follow up as yet.

Tom Petch

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 13 Sep 2021 12:49:33 -0700

[Bringing in babel WG, instead of maintaining two threads]

Hi Juergen,

> On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder <[email-masked]> wrote:
> 

There are five definitions in the Babel YANG model <https://www.ietf.org/archive/id/draft-ietf-babel-yang-model-11.html> that use NULL to represent a special meaning.

With ‘babel-route-received-metric’, and ‘babel-route-calculated-metric’ values use NULL or 0 to represent that a route was NOT received. A non-zero value indicates that a route was received and subsequently advertised.

With ‘babel-expo-mcast-hello-seqno’, and ‘babel-exp-ucast-hello-seqno’ a value of NULL or 0 is used to represent that a multicast, or unicast hello packets respectively are NOT expected or processing of multicast/unicast packets is not enabled. Although not explicit stated, it also means that the sequence number cannot be a 0.

Finally, with ‘babel-ucast-hello-seqno’ a value of NULL or 0 is used to represent a unicast hello is not being sent. A non-zero value reflects the current sequence number in use for unicast hellos. Again, although not explicit, it also means that the sequence number cannot be a 0.

> set aside a special value from the number space or use a union.

This YANG model reserves the value of 0 to indicate that these leafs are not set or the particular attribute is not enabled.

Thanks.

> sequence number is absent. The problem really might be the text in RFC

Mahesh Jethanandani
[email-masked]

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 13 Sep 2021 22:04:55 +0200

Hi Mahesh,

management interface usually do not change protocol semantics (for the
simple reason that protocol engines do not necessarily know which
management interfaces control them and their peers).

Does the Babel RFC reserve the special sequence number 0? If not, does
this document formally update the Babel RFC to reserve the sequence
number 0? And will implementations and deployments follow on or will
we see "old" and "updated" implementations in the wild causing
operational trouble?

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 13 Sep 2021 20:59:37 +0000

I seem to be coming into this discussion in the middle, so I hope I'm understanding where things are. Comments in-line.

> we see "old" and "updated" implementations in the wild causing

Yes, the Babel RFC makes it clear that 0 is a valid value that must not be confused with NULL.
I have no idea what conventions exist for a YANG model to distinguish between 0 and NULL in such cases, but merely expressed that the distinction must exist. Whatever conventions exist within YANG to make this distinction can be used. It sounded from Tom's email that several conventions exist for handling this. Under no circumstances should this YANG model allow the valid value of zero to be repurposed to mean NULL.
 
> > > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder
> <[email-masked]> wrote:
> > >
> > There are five definitions in the Babel YANG model
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-
> babel-yang-model-
> 11.html__;!!BhdT!w6VP0VXwBo8HQB7xl29xPqAxO7zHbtal44Pwbxrh6lIs8a04rPj
> 0rzZ_DACdBQ$ > that use NULL to represent a special meaning.
> >
> > With 'babel-route-received-metric', and 'babel-route-calculated-metric'
> values use NULL or 0 to represent that a route was NOT received. A non-zero
> value indicates that a route was received and subsequently advertised.
> >
> > With 'babel-expo-mcast-hello-seqno', and 'babel-exp-ucast-hello-seqno' a
> value of NULL or 0 is used to represent that a multicast, or unicast hello packets
> respectively are NOT expected or processing of multicast/unicast packets is not
> enabled. Although not explicit stated, it also means that the sequence number
> cannot be a 0.
> >
> > Finally, with 'babel-ucast-hello-seqno' a value of NULL or 0 is used to
> represent a unicast hello is not being sent. A non-zero value reflects the current
> sequence number in use for unicast hellos. Again, although not explicit, it also
> means that the sequence number cannot be a 0.
> >
> > >
> > This YANG model reserves the value of 0 to indicate that these leafs are not
> set or the particular attribute is not enabled.
> >
> > Thanks.
> >
> > >

RFC9046 text is intended to allow and encourage data models to do whatever they need to do to ensure they can distinguish between a value of 0 and a NULL value. For example, in BBF TR-181 data model, we use a signed integer for these parameters, where "-1" means "null value" and 0 to 2^16 represent actual values. This use of -1 and a signed integer to convey NULL for an unsigned integer is a convention that has long been defined in TR-181 data modeling rules. OTOH, Babel implementations written in languages like C *are* able to distinguish between a zero-length variable and a zero-value variable -- so their GUIs have no difficulty with this distinction and can simply use an unsigned integer. 

Different data modeling languages are likely to each have their own mechanisms for handling this -- which means it would have been improper for RFC9046 to be proscriptive about *how* a data model should distinguish between null and 0. Therefore, the text in RFC9046 merely states that although the native variable is a 16-bit unsigned integer, it must be possible to indicate null as something distinct from 0. RFC9046 does not dictate how that should be accomplished. The data model needs to ensure this distinction exists using whatever method makes sense or whatever convention exists for that data modeling language. 
Barbara

---

From: tom petch <[email-masked]>
Date: Tue, 14 Sep 2021 09:11:10 +0000

rom: netmod <[email-masked]> on behalf of STARK, BARBARA H <[email-masked]>
Sent: 13 September 2021 21:59

<tp>
Barbara,

Apologies for making a mess of raising this issue; I am struggling with webmail and a PC that has a mind of its own such that I cannot send e-mails where I want to or even when I want to:-(

Anyhow, I agree that the Information model makes it clear the NULL and zero are different.  YANG has no concept of NULL; some languages do, YANG does not.  This raises  number of possibilities.

One is to deviate from the Information Model and treat zero as NULL but I would not expect that to be acceptable.

Another it to modify the range by making uint16 into int16 and making a negative value represent NULL in this model.  Again, I would not expect that to be acceptable but you could make it a int32 or uint32 with a range restriction such that one value means NULL..

Another is to make the objects a YANG union of uint16 and something else.  YANG has a built-in type 'empty' which has no value(!) and so a union of uint16 and empty is probably the closest YANG gets.  A similar approach is a union of uint16 and boolean.  My YANG is not up to the merits of the two approaches.  I have never been comfortable with 'empty' but there is plenty of it about in the IETF. By the same token, almost all models have a union in the shape of an ip address which is a union of ipv4 address and ipv6 address; a union is something I am comfortable with.

I do not know of an exact parallel to what you want to do.  I do see 'null' as one value of the text string in an enumeration which is fine for enumerations!  I also see the choice/case construct used with one case having a YANG type 'empty' which is perhaps the closest if you do not want to use a union. 

HTH

Tom Petch

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 14 Sep 2021 13:29:27 +0200

>> the Babel RFC makes it clear that 0 is a valid value that must not be
>> confused with NULL.

This is true for both seqnos and metrics.  A route with metric 0 is
perfectly valid, and in fact the value 0 is the default for a directly
connected prefix.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 14 Sep 2021 13:51:36 +0000

> I seem to be coming into this discussion in the middle, so I hope I'm
> understanding where things are. Comments in-line.
> 
> > Hi Mahesh,
> >
> I have no idea what conventions exist for a YANG model to distinguish between
> 0 and NULL in such cases, but merely expressed that the distinction must exist.
> Whatever conventions exist within YANG to make this distinction can be used. It
> sounded from Tom's email that several conventions exist for handling this.
> Under no circumstances should this YANG model allow the valid value of zero to
> be repurposed to mean NULL.
> 
> <tp>
> Barbara,
> 
> Apologies for making a mess of raising this issue; I am struggling with webmail
> and a PC that has a mind of its own such that I cannot send e-mails where I want
> to or even when I want to:-(
> 
> Anyhow, I agree that the Information model makes it clear the NULL and zero
> are different.  YANG has no concept of NULL; some languages do, YANG does
> not.  This raises  number of possibilities.
> 
> Another it to modify the range by making uint16 into int16 and making a
> negative value represent NULL in this model.  Again, I would not expect that to
> be acceptable but you could make it a int32 or uint32 with a range restriction
> such that one value means NULL..
> 
> Another is to make the objects a YANG union of uint16 and something else.
> YANG has a built-in type 'empty' which has no value(!) and so a union of uint16
> and empty is probably the closest YANG gets.  A similar approach is a union of
> uint16 and boolean.  My YANG is not up to the merits of the two approaches.  I
> have never been comfortable with 'empty' but there is plenty of it about in the
> IETF. By the same token, almost all models have a union in the shape of an ip
> address which is a union of ipv4 address and ipv6 address; a union is something I
> am comfortable with.
> 
> I do not know of an exact parallel to what you want to do.  I do see 'null' as one
> value of the text string in an enumeration which is fine for enumerations!  I also
> see the choice/case construct used with one case having a YANG type 'empty'
> which is perhaps the closest if you do not want to use a union.
> 
> HTH
> 
> Tom Petch

Hi Tom,
Thanks for making this an issue! I think it's important that we get it right.
This is something Mahesh and I have discussed several times (and we still apparently didn't get it right).
As I mentioned, BBF TR-181 uses int with range 	-1:65535 with -1 meaning NULL. So I certainly have no issue with that approach. The language in RFC9046 was intended to make sure this approach was allowed, since this is how it's done in TR-181.
I guess I am a bit surprised to learn that YANG doesn't seem to have a preferred way to handle this. Unfortunately, given my considerable lack of YANG expertise, I can't recommend the "right" way to model this in YANG. I can only insist that the model be able to express a value in the range 0 to 2^16 and NULL value for these parameters. 
Independent of the fact that the words in RFC9046 don't seem to have expressed this perfectly clearly, that is absolutely the intent of those words. I apologize that the RFC9046 words don't seem to be sufficiently clear. 

Since you do mention the possibility of using -1 for NULL, I'd like to understand who might find this approach unacceptable? The language in the information model was definitely intended to express the acceptability of using this approach from a Babel WG perspective (because I knew that's how it would be done in TR-181). Would this be unacceptable to people with YANG expertise? I think my preference would be to use this approach, since it would provide additional consistency between the TR-181 and YANG models.

Thanks again for raising this issue.
Barbara

> RFC9046 text is intended to allow and encourage data models to do whatever
> they need to do to ensure they can distinguish between a value of 0 and a NULL
> value. For example, in BBF TR-181 data model, we use a signed integer for these
> parameters, where "-1" means "null value" and 0 to 2^16 represent actual
> values. This use of -1 and a signed integer to convey NULL for an unsigned
> integer is a convention that has long been defined in TR-181 data modeling
> rules. OTOH, Babel implementations written in languages like C *are* able to
> distinguish between a zero-length variable and a zero-value variable -- so their
> GUIs have no difficulty with this distinction and can simply use an unsigned
> integer.
> 
> Different data modeling languages are likely to each have their own mechanisms
> for handling this -- which means it would have been improper for RFC9046 to be
> proscriptive about *how* a data model should distinguish between null and 0.
> Therefore, the text in RFC9046 merely states that although the native variable is
> a 16-bit unsigned integer, it must be possible to indicate null as something
> distinct from 0. RFC9046 does not dictate how that should be accomplished. The
> data model needs to ensure this distinction exists using whatever method makes
> sense or whatever convention exists for that data modeling language.
> Barbara
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;
> !!BhdT!z9HMtl5ev04-D11rq22Qye-5_sscMd1C-
> sWwIDBqeMrQ2tPPXauYRZI_wB2KAA$

---

From: tom petch <[email-masked]>
Date: Tue, 14 Sep 2021 16:19:12 +0000

<at the end tp2>

From: STARK, BARBARA H <[email-masked]>
Sent: 14 September 2021 14:51

Hi Tom,

<tp2>

Barbara

I think that the TR-181 approach would be fine in YANG, using int32 in place of the current uint16 and adding a YANG range constraint and would have the advantage of consistency (assuming that all such leaves are currently uint16).

I tend to see the use of -1 to stand for something else as the sort of thing I had to do programming assembler or some such because the language did not have the constructs I wanted i.e. not quite nice.  YANG does have 'empty' and so I would see the use of choice/case, with 'empty' as one such, as used by other authors, as the more proper solution but that would be different to TR-181 (which I am not familiar with)..   Swings and roundabouts.   Juergen, Lada, Martin and co have greater expertise than I in YANG so I would defer to their judgement.

Tom Petch

p.s. I find RFC9046 clear:-)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 14 Sep 2021 19:17:29 +0200

> Since you do mention the possibility of using -1 for NULL, I'd like to understand who might find this approach unacceptable? The language in the information model was definitely intended to express…

If other data models use an extended integer range and -1 to indicate
a special case, then this may be a strong reason to do the same in the
IETF YANG data model. Consistency across data models is a value, in
particular for systems that may have to support multiple. While the
conversion of different notations no hard, its one more thing to
potentially get wrong.

If you were starting with a blank sheet of paper, then the YANG idiom
would likely be to use a union of a 16-bit integer and a special
(string) value, which might even be of type empty.

One of the reasons to have no common approach to these kind of
questions is to provide the flexibility needed to do the right thing
in different contexts. Of course, you may want to stay consistent in a
data model or a collection of related data model.

I skimmed RFC 8407 and it seems we do not have text discussion this
specific situation. Perhaps we should have text, perhaps I have
overlooked it. ;-) I think there are different patterns to choose from
to handle this situation with their various pros and cons.

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 14 Sep 2021 10:37:35 -0700

Hi Juergen,

> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 

I hear two suggestions on what the “other” construct should be in the union statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any pros/cons for either of the approaches?

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 14 Sep 2021 17:57:40 +0000

All,

From: netmod <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Tuesday, September 14, 2021 at 1:38 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Babel at IETF <[email-masked]>, "STARK, BARBARA H" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [babel] NULL value for uint16

Hi Juergen,

On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>> wrote:

“type empty” is cleaner than a boolean indicating whether or not a value is specified. In fact, it wouldn’t make sense to for a boolean to be in a union with the specified value.

Acee

/js

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Martin Björklund <[email-masked]>
Date: Tue, 14 Sep 2021 20:17:58 +0200 (CEST)

> I hear two suggestions on what the “other” construct should be in the union statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any pros/cons for either of the approaches?

'boolean' doesn't seem right, since that would mean that you could see
the values 'true' | 'false' | <uint16>.

If you want a union I suggest a union with one enum, perhaps:

  type union {
    type enumeration {
      enum null;
    }
    type uint16;
  }

But Jürgens point about using a solution that other data models use
makes sense.

Yet another alternative could be to not instantiate this leaf when the
value in the information model is null.

/martin

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Sep 2021 20:36:12 +0200

On 14. Sep 2021, at 19:17, Jürgen Schönwälder <[email-masked]> wrote:
> IETF YANG data model.

Any data model based on FORTRAN certainly will do.
Most other data modeling languages by now should have nullable/optional/Maybe types.

Going from the actual data type, uint16, to int32, just to accommodate the “not present” case, strikes me as a mistake.
(Which doesn’t mean that you may not want to do this in an implementation, after having validated the input data.)

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 14 Sep 2021 21:16:18 +0200

Carsten,

whatever you do, you will at the end need an extra bit. If BBF already
defined to use -1, so be it.

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'.

/js

PS: You can define a maybe-uint16 type as a union in YANG but yes
    there is no syntactic sugar to generalize this.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 14 Sep 2021 12:31:00 -0700

Hi Martin,

> On Sep 14, 2021, at 11:17 AM, Martin Björklund <[email-masked]> wrote:
> 
> Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Juergen,
>> 

That would mean something like this:

type union {
  type empty;
  type uint16;
}

Right?

> value in the information model is null.

I have never been very clear on what happens when the leaf goes from a defined value to null. In other words, how do you “un-instantiate” a leaf? Do you delete it?

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 14 Sep 2021 15:50:58 -0700

A related question.

> On Sep 14, 2021, at 12:31 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi Martin,
> 
>> On Sep 14, 2021, at 11:17 AM, Martin Björklund <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 

RFC 7950 says that the empty type cannot have a default value. The model had the value 0, which represented NULL as the default value for some of the attributes. With the suggested change, is there a way in the union for the empty type to be the default?

If not, I will have to use Martin’s suggestion above of using a null enumeration.

Thanks.

>>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
>>> 
>>> Mahesh Jethanandani
>>> [email-masked] <mailto:[email-masked]>
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Sep 2021 01:01:11 +0200

On 14. Sep 2021, at 21:16, Jürgen Schönwälder <[email-masked]> wrote:
> 
> Carsten,
> 
> whatever you do, you will at the end need an extra bit.

Sure.  There are 65537 values, so you need at least 16.000022 bits :-)

> If BBF already

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

> is no value' and 'the value has been suppressed by authorization'.

Interesting.  I wasn’t aware that this cannot be distinguished in YANG.

But an “empty” would be present if it is chosen, no?

Grüße, Carsten

> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 15 Sep 2021 01:53:19 +0200

> Optional-uint16 = uint16 / empty

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...

> 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

---

From: tom petch <[email-masked]>
Date: Wed, 15 Sep 2021 09:04:53 +0000

From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
Sent: 15 September 2021 00:53

<tp>

I am with Juergen here, and in a previous post, that if that is the way it is done in BBF, then that is a compelling reason to do the same.  

Also, you can create a typedef for it, in one place in the model with a description, both in the YANG and in the body of the I-D, and then use that type in all the places that it applies, which, for me, makes for a clearer, easier to understand model.

I suggested boolean but agree that it is clumsy, not quite right (although I have seen it somewhere).  I suggested choice/case because that is what others do but as before, following BBF is a more compelling argument.

It also addresses the problem of access control making it a challenge to know what is going on.  The one leaf, the one object, you get it or you do not.  Simple!

And if you want to save bits, then YANG is not for you; the design aim was text that anyone could read anywhere; if you want to save bits, then you need a compact binary representation:-)

Tom Petch
(who is on European time)

  > > The alternative is to not 

instantiate the leaf if there is no value

/js

---

From: tom petch <[email-masked]>
Date: Wed, 15 Sep 2021 10:58:50 +0000

Barbara

Top posting a slightly different question.

Belatedly doing my homework, I see that not all the NULL are uint16.  One, next-hop, is ip-address.  We have the options discussed for uint16 but could also use zero (or some other value) to mean NULL.  Zero is of course the way the default is commonly represented.

How is this handled in TR-181?  How would you like it handled in YANG?

Tom Petch

From: netmod <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 15 September 2021 10:04

<tp>

Tom Petch

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 15 Sep 2021 12:51:08 +0000

> Belatedly doing my homework, I see that not all the NULL are uint16.  One,
> next-hop, is ip-address.  We have the options discussed for uint16 but could also
> use zero (or some other value) to mean NULL.  Zero is of course the way the
> default is commonly represented.
> 

Hi Tom,
In discussion with Mahesh, he has indicated preference for union with a "null" enumeration to handle the uint16 cases. He's also indicated he would prefer to do that for the ip-address.
I see the YANG ip-address type is a union of ipv4-address and ipv6-address types, both of which are strings.
In BBF, there is the IPAddress datatype which is a string(45) with IPv4 and IPv6 formats allowed. There are also IPv4Address and IPv6Address datatypes that are defined as derivatives of the IPAddress datatype. An empty string is used for "unspecified or inapplicable addresses". Strings, unlike ints, have the luxury of being empty. 
I'm perfectly fine with Mahesh's choice to use the union with a "null" enum in all cases. It seems like a good solution. 
Thx,
Barbara
 
> > I don't see a big difference between
> I am with Juergen here, and in a previous post, that if that is the way it is done in
> BBF, then that is a compelling reason to do the same.
> 
> Also, you can create a typedef for it, in one place in the model with a
> description, both in the YANG and in the body of the I-D, and then use that type
> in all the places that it applies, which, for me, makes for a clearer, easier to
> understand model.
> 
> I suggested boolean but agree that it is clumsy, not quite right (although I have
> seen it somewhere).  I suggested choice/case because that is what others do but
> as before, following BBF is a more compelling argument.
> 
> It also addresses the problem of access control making it a challenge to know
> what is going on.  The one leaf, the one object, you get it or you do not.  Simple!
> 
> And if you want to save bits, then YANG is not for you; the design aim was text
> that anyone could read anywhere; if you want to save bits, then you need a
> compact binary representation:-)
> 
> Tom Petch
> > Interesting.  I wasn't aware that this cannot be distinguished in YANG.
> 
> > But an "empty" would be present if it is chosen, no?
> 
> Fax:   +49 421 200 3103         <https://urldefense.com/v3/__https://www.jacobs-
> university.de/__;!!BhdT!0lzj-
> SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1EFLdoxAw$ >
> 
> !!BhdT!0lzj-
> SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1Ew7T22Pw$
> 
> !!BhdT!0lzj-
> SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1Ew7T22Pw$

---

From: tom petch <[email-masked]>
Date: Wed, 15 Sep 2021 16:13:10 +0000

From: STARK, BARBARA H <[email-masked]>
Sent: 15 September 2021 13:51

Hi Tom,

<tp>

OK.

Two digressions.  One is that the RFC6991 YANG ip-address includes a zone, a string of indeterminate length and flexible syntax, both for IPv4 and IPv6 so when this is specified, I wonder if the author is aware of this and the -no-zone alternative which, on occasions, is more appropriate.

Second, left field. when I first posted, I had great difficulty in specifying the e-mail addresses I was sending to (still do:-(.  I included the document shepherd, and you because I knew what your address is and it is easy to type correctly:-)  The addresses I might have included, but did not,  were your fellow author (who is now on the thread); and the WG Chairs, the address for the I-D and perhaps the AD.  I trust that these others will be involved when needed.

Tom Petch

Thx,
Barbara

> Sent: 15 September 2021 00:53

<snip>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 27 Sep 2021 16:20:56 +0000

Hi all,

Reserving a "magic value" like -1 may be workable, but it doesn't feel like a terribly good fit into YANG. The rest of the range of integer values are valid and it seems odd to just tack on a "-1".

Why not just make the absence of the leaf mean "not applicable" or "not available" or whatever you are thinking of encoding as "null" ?

I've seen discussions where an SNMP MIB (which uses magic values like -1 or 0) was mapped to YANG and the result was simply to map the -1 (or 0) to the "absence of the leaf" (especially for read only state).

If it really is critical to distinguish these two cases (which I'm pretty doubtful of for an individual leaf like this), then I think at least an enum more distinctly separates the valid range from the special "not applicable" token:
1) leaf was filtered out due to AAA rules
2) leaf wasn't returned because it is not-applicable/not-available

Jason

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of STARK, BARBARA
> H
> Sent: Tuesday, September 14, 2021 9:52 AM
> To: 'tom petch' <[email-masked]>; 'Juergen Schoenwaelder'
> <[email-masked]>; 'Mahesh Jethanandani'
> <[email-masked]>
> Cc: 'Babel at IETF' <[email-masked]>; [email-masked]' <[email-masked]>
> As I mentioned, BBF TR-181 uses int with range 	-1:65535 with -1
> meaning NULL. So I certainly have no issue with that approach. The language
> in RFC9046 was intended to make sure this approach was allowed, since this
> is how it's done in TR-181.
> I guess I am a bit surprised to learn that YANG doesn't seem to have a
> preferred way to handle this. Unfortunately, given my considerable lack of
> YANG expertise, I can't recommend the "right" way to model this in YANG. I
> can only insist that the model be able to express a value in the range 0 to
> 2^16 and NULL value for these parameters.
> Independent of the fact that the words in RFC9046 don't seem to have
> expressed this perfectly clearly, that is absolutely the intent of those words. I
> apologize that the RFC9046 words don't seem to be sufficiently clear.
> 
> Since you do mention the possibility of using -1 for NULL, I'd like to
> understand who might find this approach unacceptable? The language in the
> information model was definitely intended to express the acceptability of
> using this approach from a Babel WG perspective (because I knew that's how
> it would be done in TR-181). Would this be unacceptable to people with
> YANG expertise? I think my preference would be to use this approach, since
> it would provide additional consistency between the TR-181 and YANG
> models.
> 
> > > respectively are NOT expected or processing of multicast/unicast packets
> is
> > not

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Sep 2021 10:13:59 -0700

On Mon, Sep 27, 2021 at 9:21 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi all,
>
> Reserving a "magic value" like -1 may be workable, but it doesn't feel
> like a terribly good fit into YANG. The rest of the range of integer values
> are valid and it seems odd to just tack on a "-1".
>
> Why not just make the absence of the leaf mean "not applicable" or "not
> available" or whatever you are thinking of encoding as "null" ?
>
> I've seen discussions where an SNMP MIB (which uses magic values like -1
> or 0) was mapped to YANG and the result was simply to map the -1 (or 0) to
> the "absence of the leaf" (especially for read only state).
>
> If it really is critical to distinguish these two cases (which I'm pretty
> doubtful of for an individual leaf like this), then I think at least an
> enum more distinctly separates the valid range from the special "not
> applicable" token:

IMO this is not a real problem.
There is an assumption that access control is setup correctly.
The NACM default is to allow all reads so explicit rules are needed
to remove access to config=false data nodes.

It is clearly better to omit nodes rather than return them with "not set"
indications.
This reduced the amount of data transferred which may matter to the
operator.

SNMP GetNext and GetBulk do not handle missing nodes well at all, so it
became
common practice to return 0 or -1, etc. to simplify client processing of
these operations.
None of the YANG-based protocols have this problem.

Andy

> > Cc: 'Babel at IETF' <[email-masked]>; [email-masked]' <[email-masked]
> >
> > > Yes, the Babel RFC makes it clear that 0 is a valid value that must
> not be
> > > confused with NULL.
> > > 0 and NULL in such cases, but merely expressed that the distinction
> must
> > exist.
> > > and a PC that has a mind of its own such that I cannot send e-mails
> where I
> > want
> > > One is to deviate from the Information Model and treat zero as NULL
> but I
> > > would not expect that to be acceptable.
> > >
> > > YANG has a built-in type 'empty' which has no value(!) and so a union
> of
> > uint16
> > > and empty is probably the closest YANG gets.  A similar approach is a
> union
> > of
> > > have never been comfortable with 'empty' but there is plenty of it
> about in
> > the
> > > IETF. By the same token, almost all models have a union in the shape
> of an
> > ip
> > > I do not know of an exact parallel to what you want to do.  I do see
> 'null' as
> > one
> > > value of the text string in an enumeration which is fine for
> enumerations!  I
> > also
> > > > values use NULL or 0 to represent that a route was NOT received. A
> non-
> > zero
> > > > value of NULL or 0 is used to represent that a multicast, or unicast
> hello
> > > packets
> > > > enabled. Although not explicit stated, it also means that the
> sequence
> > number
> > > > cannot be a 0.
> > > > >
> > > > represent a unicast hello is not being sent. A non-zero value
> reflects the
> > > current
> > > > sequence number in use for unicast hellos. Again, although not
> explicit, it
> > also
> > > > > This YANG model reserves the value of 0 to indicate that these
> leafs are
> > not
> > > > > > sequence number is absent. The problem really might be the text
> in
> > RFC
> > > > > > 9046.
> > >
> > > they need to do to ensure they can distinguish between a value of 0
> and a
> > NULL
> > > value. For example, in BBF TR-181 data model, we use a signed integer
> for
> > these
> > > rules. OTOH, Babel implementations written in languages like C *are*
> able
> > to
> > > distinguish between a zero-length variable and a zero-value variable
> -- so
> > their
> > > for handling this -- which means it would have been improper for
> RFC9046
> > to be
> > > distinct from 0. RFC9046 does not dictate how that should be
> accomplished.
> > The
> > > data model needs to ensure this distinction exists using whatever
> method
> > makes

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 27 Sep 2021 10:42:38 -0700

Hi -

On 2021-09-27 10:13 AM, Andy Bierman wrote:
...
> None of the YANG-based protocols have this problem.

In what way would "missing node" processing be substantially different
between the two protocol families?  In both cases the server locator
methods need to be able to be able to skip over "not present" instances,
and will get messy if the instrumented code has adopted the otherwise
tidier paradigm of row/instance-wise registration rather than a general
access method for all instances of the class.  For the client I can't
see any substantial difference at all between needs to happen to process
the results correctly.

That said, in my non-YANG experience it's a lot cleaner to generate code
to handle sentinel values (and a lot harder for implementers to ignore
them) than it is to assign ambiguous semantics to "missing data" cases.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Sep 2021 11:35:48 -0700

> see any substantial difference at all between needs to happen to process
NETCONF and RESTCONF do not have "row skew" problems.
They return subtrees, not individual varbinds like SNMP.
Retrieving a "table row" in SNMP is much more complicated when some
columns are unimplemented. A YANG subtree includes all the data the
client is allowed to view, including augmenting nodes.

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 27 Sep 2021 12:42:35 -0700

Hi -

On 2021-09-27 11:35 AM, Andy Bierman wrote:
> 
> 
> On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn 

That doesn't change anything for the client or the server.
In both cases the implementation needs to deal with missing values.
(If client code isn't looking at individual varbind index values in
the response to Get-Bulk or Get-Next and somehow assumes that
there's any assurance they'd belong to "the same row", the developer
has yet to earn the title of "rookie" and should be sentenced to
reviewing COBOL accounting software until they repent.)

> columns are unimplemented.

That is highly dependent on the tools one is using.  In the code
base I know most intimately, no special code (no code at all!) is
needed for unimplemented columns.  Where it gets interesting is
where there are "holes" in one or more columns - that is, the sets
of rows represented in the various columns making up a table do not have
the same index value tuples.  I see two main sub-cases:
where there is a user-provided locator function for rows or instances,
and where rows have been registered individually with the
infrastructure.  In the former case, "holes" are trivial - the
locator skips over any holes, because they don't exist.  The latter
case requires more developer work.

 From the perspective of generating code to grab values from
instrumentation according to a mapping defined in some IDL, there
should be little difference between SNMP-ish and YANG-ish protocols, 
particularly if the information models and the implementation
architecture of the instrumented code are reasonably coherent.
(I know that last bit is sometimes a big assumption.)

> A YANG subtree includes all the data the

That's essentially how subagent registration protocols like DPI, SMUX
and AgentX work.  Yes, the object-disoriented approach of Get-Next and
Get-Bulk means that lots of stuff irrelevant to the intent of the query
will fly around, both in the subagent protocol as well as the SNMP,
especially with quirky, fine-grained configurations of VACM.  But
that does not require the instrumented code to adopted a similarly
scattered implementation strategy.  The job of automatically-
generated glue code and infrastructure is to provide the adaptation
between the instrumented implementation, a hopefully somewhat coherent
information model, and the oddities of SNMP protocol.  If the developer
has to spend much time worrying about the quirks of a management
protocol, the tools aren't doing their job.

...

But back to the original issue: In cases like the one under discussion,
the information element in question is *not* absent in the
implementation.  Instead, it has a sentinel value chosen to
distinguish one or more interesting situations from the range of
"normal" values suitable for use in other calculations.  It seems to
me that using explicit sentinel values in the model (with explicit
labeling of their semantics) is a more accurate reflection
of both the typical implementation strategies as well as providing a 
more direct way to communicate the model semantics and avoids
introducing ambiguity.

Randy