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

[Randy Presuhn]

Hi -

On 2021-09-27 11:35 AM, Andy Bierman wrote:



On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn 
> wrote:


Hi -

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

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.


NETCONF and RESTCONF do not have "row skew" problems.
They return subtrees, not individual varbinds like SNMP.


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


Retrieving a "table row" in SNMP is much more complicated when some
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
client is allowed to view, including augmenting nodes.


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.


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.

...

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Mon, Sep 27, 2021 at 10:42 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> Hi -
>
> On 2021-09-27 10:13 AM, Andy Bierman wrote:
> ...
> > 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.
>
> 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.
>
>
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.

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


> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Randy Presuhn]

Hi -

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


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Mon, Sep 27, 2021 at 9:21 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> 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:
> 1) leaf was filtered out due to AAA rules
> 2) leaf wasn't returned because it is not-applicable/not-available
>
>

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.


> Jason
>

Andy


>
> > -Original Message-
> > From: netmod  On Behalf Of STARK, BARBARA
> > H
> > Sent: Tuesday, September 14, 2021 9:52 AM
> > To: 'tom petch' ; 'Juergen Schoenwaelder'
> > ; 'Mahesh Jethanandani'
> > 
> > Cc: 'Babel at IETF' ; 'netmod@ietf.org'  >
> > Subject: Re: [netmod] [babel] NULL value for uint16
> >
> >
> >
> > > 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,
> > > >
> > > > 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?
> > >
> > > 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.
> > >
> > > 
> > > 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 mak

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

[Sterne, Jason (Nokia - CA/Ottawa)]

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  On Behalf Of STARK, BARBARA
> H
> Sent: Tuesday, September 14, 2021 9:52 AM
> To: 'tom petch' ; 'Juergen Schoenwaelder'
> ; 'Mahesh Jethanandani'
> 
> Cc: 'Babel at IETF' ; 'netmod@ietf.org' 
> Subject: Re: [netmod] [babel] NULL value for uint16
> 
> 
> 
> > 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,
> > >
> > > 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?
> >
> > 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.
> >
> > 
> > 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
> 
> Hi Tom,
> Thanks for making this an issue! I think it's important that

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

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 15 September 2021 00:53

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



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
> > 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  does not exist, the client gets nothing. If 
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  can't decide whether there is no  because
 does not exist or authorization prevented access to .

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  and it does not matter what
type  has or which value  has (if it is a leaf) or whether
 is the root of a deeply nested tree (if it is a container).  If
a client has no permissions to read , then  is silently
omitted.

Things are different if a client attempts to create/write/delete
, 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

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  does not exist, the client gets nothing. If 
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  can't decide whether there is no  because
 does not exist or authorization prevented access to .

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  and it does not matter what
type  has or which value  has (if it is a leaf) or whether
 is the root of a deeply nested tree (if it is a container).  If
a client has no permissions to read , then  is silently
omitted.

Things are different if a client attempts to create/write/delete
, 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Mahesh Jethanandani]

Hi Martin,

> On Sep 14, 2021, at 11:17 AM, Martin Björklund  wrote:
> 
> Mahesh Jethanandani  > wrote:
>> Hi Juergen,
>> 
>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
>>>  wrote:
>>> 
>>> On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
>>> 
 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.
>>> 
>>> 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.
>> 
>> 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' | .
> 
> 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.

That would mean something like this:

type union {
  type empty;
  type uint16;
}

Right?

> 
> Yet another alternative could be to not instantiate this leaf when the
> 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.

> 
> 
> 
> /martin
> 
> 
> 
> 
> 
>> 
>>> 
>>> 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
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>> 
>> Mahesh Jethanandani
>> mjethanand...@gmail.com

Mahesh Jethanandani
mjethanand...@gmail.com





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

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.

On Tue, Sep 14, 2021 at 08:36:12PM +0200, Carsten Bormann wrote:
> On 14. Sep 2021, at 19:17, Jürgen Schönwälder 
>  wrote:
> > 
> > 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.
> 
> 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
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 14. Sep 2021, at 19:17, Jürgen Schönwälder 
 wrote:
> 
> 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.

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Björklund]

Mahesh Jethanandani  wrote:
> Hi Juergen,
> 
> > On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
> >  wrote:
> > 
> > On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
> > 
> >> 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.
> > 
> > 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.
> 
> 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' | .

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





> 
> > 
> > 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
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Acee Lindem (acee)]

All,

From: netmod  on behalf of Mahesh Jethanandani 

Date: Tuesday, September 14, 2021 at 1:38 PM
To: Juergen Schoenwaelder 
Cc: Babel at IETF , "STARK, BARBARA H" , 
"netmod@ietf.org" 
Subject: Re: [netmod] [babel] NULL value for uint16

Hi Juergen,


On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:


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.

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.

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?

“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



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

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

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Mahesh Jethanandani]

Hi Juergen,

> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
>  wrote:
> 
> On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
> 
>> 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.
> 
> 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.

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?

> 
> 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
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

Mahesh Jethanandani
mjethanand...@gmail.com





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

From: STARK, BARBARA H 
Sent: 14 September 2021 14:51

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

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.



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 

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

[STARK, BARBARA H]

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

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

> > /js
> >
> > On Mon, Sep 13, 2021 at 12:49:33PM -0700, Mahesh Jethanandani wrote:
> > > [Bringing in babel WG, instead of maintaining two threads]
> > >
> > >
> > > Hi Juergen,
> > >
> > >
> > > > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder
> >  wrote:
> > > >
> > > > On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> > > >
> > > >> and it references an RFC that says:
> > > >>
> > > >>  This is a 16-bit unsigned 

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

[Juliusz Chroboczek]

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

rom: netmod  on behalf of STARK, BARBARA H 

Sent: 13 September 2021 21:59

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,
>
> 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?

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.


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



> /js
>
> On Mon, Sep 13, 2021 at 12:49:33PM -0700, Mahesh Jethanandani wrote:
> > [Bringing in babel WG, instead of maintaining two threads]
> >
> >
> > Hi Juergen,
> >
> >
> > > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder
>  wrote:
> > >
> > > On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> > >
> > >> 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.
> > >
> > > 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.
> >
> > There are five definitions in the Babel YANG model
>  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.
> >
> > >
> > > In YANG, we tend 

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

[STARK, BARBARA H]

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,
> 
> 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?

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.
 
> /js
> 
> On Mon, Sep 13, 2021 at 12:49:33PM -0700, Mahesh Jethanandani wrote:
> > [Bringing in babel WG, instead of maintaining two threads]
> >
> >
> > Hi Juergen,
> >
> >
> > > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder
>  wrote:
> > >
> > > On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> > >
> > >> 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.
> > >
> > > 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.
> >
> > There are five definitions in the Babel YANG model
>  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.
> >
> > >
> > > 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.
> >
> > This YANG model reserves the value of 0 to indicate that these leafs are not
> set or the particular attribute is not enabled.
> >
> > Thanks.
> >
> > >
> > > 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.

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