Re: [netmod] NULL value for uint16

[Jürgen Schönwälder]

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.

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

-- 
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] NULL value for uint16

[Lou Berger]

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)

On 9/10/2021 12:06 PM, tom petch wrote:


From: Jürgen Schönwälder 
Sent: 10 September 2021 13:14

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.



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

On Fri, Sep 10, 2021 at 11:56:22AM +, tom petch wrote:

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
___
netmod mailing list
netmod@ietf.org
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 

___
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] NULL value for uint16

[Randy Presuhn]

Hi -

On 2021-09-10 9:57 AM, Andy Bierman wrote:



On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn 
> wrote:


Hi -

On 2021-09-10 9:42 AM, Andy Bierman wrote:
 > Hi,
 >
 > Maybe the use of [null] in RFC 7951 is confusing people
 > https://datatracker.ietf.org/doc/html/rfc7951#section-6.9

 > >

Are you suggesting that the type of this leaf should be a
choice of unit16 and empty?  At least that wouldn't
have the ambiguity under access control Jürgen described.



No, but the access control issue applies everywhere so it is usually ignored
and assumed that the client can view all the server data. The client 
could be

blocked from viewing the empty, so this choice does not help.


It removes the ambiguity.  With the current design, a client cannot
distinguish between no-value-yet and blocked.  With a choice, the
client can tell the difference.  Whether that distinction matters
is a judgement call, and I understand the perspective that it's
easier to just ignore it in clients, regardless of how that might
affect the validity of the decisions they make.

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


It does: empty.  But just as in better-known syntaxes like ASN.1 one
still needs to use a choice type to make "null" a possibility beyond
the range of values represented by the other basic types.  (A corner
cases might be things like empty strings, though I'd argue that
a zero-length string is quite distinct from no-string-at-all.)

Randy

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

Re: [netmod] yang-instance-file include-defaults leaf

[Andy Bierman]

On Fri, Sep 10, 2021 at 5:15 AM Balázs Lengyel 
wrote:

> See below as BALAZS4
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. szeptember 10., péntek 4:57
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Thu, Sep 9, 2021 at 6:19 AM Balázs Lengyel 
> wrote:
>
> Hello Andy,
>
> See below as BALAZS3.
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. augusztus 25., szerda 18:29
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
> Hi,
>
>
>
> Here is the latest text. It is inconsistent with RFC 6243, section 3.
>
> IMO the subsections should be cited instead of the copy-and-change
> approach.
>
> BALAZS3: The 6243 sections contain parts about “data retrieval”
> “capabilities” or “conceptual data nodes set by the server”
>
> These parts are not relevant for many of the instance data use cases, so I
> would like to stick with including text here.
>
>
>
>
>
>
>
> I guess I do not understand why the "with-defaults" leaf or at leaf
> "with-defaults-mode" typedef
>
> cannot be used. IMO this is bad practice.  Applications that already know
> how to deal
>
> with defaults according to RFC 6243 should be supported.
>
>
>
>
>
>  leaf includes-defaults {
>
>  type ncwd:with-defaults-mode;
>
>  }
>
>
>
> I do not see any text in this typedef that is server-specific.
>
> Andy
>
> BALAZS4:  While I generally agree that duplication is a bad practice, I
> avoided using ncwd:with-defaults-mode because:
>
> ·It references RFC 6243 
> ; Section 3 
>  which is full of 
> inappropriate references (server, data retrieval, capabilities)
>
> ·The typedef’s description is "Possible modes to report default 
> data." However, in a number of use cases (e.g., UC2 Preloading default 
> configuration data, UC7, U8) the data is not reported.
>
> ·report-all-tagged description contains “XML attribute” which is 
> incorrect if we use JSON encoding
>
> ·I prefer to use the 2119 term SHALL, SHALL NOT in the enum 
> descriptions.
>
> Is this acceptable?
>
>
>
>

The data type I suggested does not have any references to section 3.
It does not have any MUST,SHOULD,MAY text at all.
The JSON encoding in RFC 7951 supports attributes.

IMO this leaf will cause a lot of confusion for users.
includes-defaults looks like with-defaults but it isn't.
It uses the exact same enums as with-defaults, but they mean different
things.


Andy


>
>leaf includes-defaults {
>
>  type enumeration {
>
>enum report-all {
>
>  value 1;
>
>  description
>
>"All data nodes SHOULD be included independent of
>
>  any default values.";
>
>
>
> AB: should follow 6243, 3.1
>
>}
>
>enum trim {
>
>  value 2;
>
>  description
>
>"Data nodes that have a default defined and where
>
>  the actual value is the default value SHOULD
>
>  NOT be included.";
>
>
>
> AB: should follow 6243, section 3.2
>
>}
>
>enum explicit {
>
>  value 3;
>
>  description
>
>"Data nodes that have a default defined and where
>
>  the actual value is the default value SHOULD NOT be
>
>  included. However, if the actual value was set by
>
>  a NETCONF client or other management application
>
>  by the way of an explicit management operation the
>
>  data node SHOULD be included.";
>
>
>
> AB: should follow 6243, section 3.3
>
>}
>
>  }
>
>  description
>
>"As instance-data-sets MAY contain incomplete data sets,
>
>  thus any data node MAY be absent.
>
>
>
>  Providing the instance-data-set intends to contain a
>
>  full data set, this leaf specifies whether the data set
>
>  includes data nodes that have a default defined and
>
>  where the actual value is the same as the default value.
>
>
>
>  Data nodes that have no default values should always
>
>  be included.
>
>  Data nodes that have a default value, but the actual
>
>  value is not equal to the schema defined default
>
>  should always be included.";
>
>
>
>
>
> AB: The last paragraph should be removed or changed. Why are these nodes 
> special?
>
> Nodes that are actually present and do not contain the YANG default
>
> are not relevant to this object.
>
> BALAZS3: OK
>
>
>
>  reference
>
>"RFC 6243 : 
> With-defaults Capability for NETCONF";
>
>}
>
>
>
> The best way to 

Re: [netmod] NULL value for uint16

[Andy Bierman]

On Fri, Sep 10, 2021 at 9:47 AM Randy Presuhn <
randy_pres...@alumni.stanford.edu> wrote:

> Hi -
>
> On 2021-09-10 9:42 AM, Andy Bierman wrote:
> > Hi,
> >
> > Maybe the use of [null] in RFC 7951 is confusing people
> > https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
> > 
>
> Are you suggesting that the type of this leaf should be a
> choice of unit16 and empty?  At least that wouldn't
> have the ambiguity under access control Jürgen described.
>
>

No, but the access control issue applies everywhere so it is usually ignored
and assumed that the client can view all the server data. The client could
be
blocked from viewing the empty, so this choice does not help.

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


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] NULL value for uint16

[Randy Presuhn]

Hi -

On 2021-09-10 9:42 AM, Andy Bierman wrote:

Hi,

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



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

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

Re: [netmod] NULL value for uint16

[Andy Bierman]

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

> From: Jürgen Schönwälder 
> Sent: 10 September 2021 17:18
> To: tom petch
> Cc: netmod@ietf.org
> Subject: Re: [netmod] NULL value for uint16
>
> 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.
>
> 
>
> OK will do.
>
> Tom Petch
> /js
>
> On Fri, Sep 10, 2021 at 04:06:14PM +, tom petch wrote:
> > From: Jürgen Schönwälder 
> > Sent: 10 September 2021 13:14
> >
> > 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.
> >
> > 
> >
> > 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
> >
> > On Fri, Sep 10, 2021 at 11:56:22AM +, tom petch wrote:
> > > 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
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > 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 
>
> --
> 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] NULL value for uint16

[tom petch]

From: Jürgen Schönwälder 
Sent: 10 September 2021 17:18
To: tom petch
Cc: netmod@ietf.org
Subject: Re: [netmod] NULL value for uint16

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.



OK will do.

Tom Petch
/js

On Fri, Sep 10, 2021 at 04:06:14PM +, tom petch wrote:
> From: Jürgen Schönwälder 
> Sent: 10 September 2021 13:14
>
> 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.
>
> 
>
> 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
>
> On Fri, Sep 10, 2021 at 11:56:22AM +, tom petch wrote:
> > 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
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > 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 

--
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] NULL value for uint16

[Jürgen Schönwälder]

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

On Fri, Sep 10, 2021 at 04:06:14PM +, tom petch wrote:
> From: Jürgen Schönwälder 
> Sent: 10 September 2021 13:14
> 
> 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.
> 
> 
> 
> 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
> 
> On Fri, Sep 10, 2021 at 11:56:22AM +, tom petch wrote:
> > 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
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > 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 

-- 
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] NULL value for uint16

[tom petch]

From: Jürgen Schönwälder 
Sent: 10 September 2021 13:14

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.



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

On Fri, Sep 10, 2021 at 11:56:22AM +, tom petch wrote:
> 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
> ___
> netmod mailing list
> netmod@ietf.org
> 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 

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

Re: [netmod] yang-instance-file include-defaults leaf

[Andy Bierman]

On Fri, Sep 10, 2021 at 5:15 AM Balázs Lengyel 
wrote:

> See below as BALAZS4
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. szeptember 10., péntek 4:57
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Thu, Sep 9, 2021 at 6:19 AM Balázs Lengyel 
> wrote:
>
> Hello Andy,
>
> See below as BALAZS3.
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. augusztus 25., szerda 18:29
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
> Hi,
>
>
>
> Here is the latest text. It is inconsistent with RFC 6243, section 3.
>
> IMO the subsections should be cited instead of the copy-and-change
> approach.
>
> BALAZS3: The 6243 sections contain parts about “data retrieval”
> “capabilities” or “conceptual data nodes set by the server”
>
> These parts are not relevant for many of the instance data use cases, so I
> would like to stick with including text here.
>
>
>
>
>
>
>
> I guess I do not understand why the "with-defaults" leaf or at leaf
> "with-defaults-mode" typedef
>
> cannot be used. IMO this is bad practice.  Applications that already know
> how to deal
>
> with defaults according to RFC 6243 should be supported.
>
>
>
>
>
>  leaf includes-defaults {
>
>  type ncwd:with-defaults-mode;
>
>  }
>
>
>
> I do not see any text in this typedef that is server-specific.
>
> Andy
>
> BALAZS4:  While I generally agree that duplication is a bad practice, I
> avoided using ncwd:with-defaults-mode because:
>
> ·It references RFC 6243 
> ; Section 3 
>  which is full of 
> inappropriate references (server, data retrieval, capabilities)
>
> ·The typedef’s description is "Possible modes to report default 
> data." However, in a number of use cases (e.g., UC2 Preloading default 
> configuration data, UC7, U8) the data is not reported.
>
> ·report-all-tagged description contains “XML attribute” which is 
> incorrect if we use JSON encoding
>
> ·I prefer to use the 2119 term SHALL, SHALL NOT in the enum 
> descriptions.
>
> Is this acceptable?
>
>
>
>


The  operation uses the with-defaults parameter directly.

https://datatracker.ietf.org/doc/html/rfc8526#section-3.1.1.2

IMO this operation should be consistent with .


Andy


>
>leaf includes-defaults {
>
>  type enumeration {
>
>enum report-all {
>
>  value 1;
>
>  description
>
>"All data nodes SHOULD be included independent of
>
>  any default values.";
>
>
>
> AB: should follow 6243, 3.1
>
>}
>
>enum trim {
>
>  value 2;
>
>  description
>
>"Data nodes that have a default defined and where
>
>  the actual value is the default value SHOULD
>
>  NOT be included.";
>
>
>
> AB: should follow 6243, section 3.2
>
>}
>
>enum explicit {
>
>  value 3;
>
>  description
>
>"Data nodes that have a default defined and where
>
>  the actual value is the default value SHOULD NOT be
>
>  included. However, if the actual value was set by
>
>  a NETCONF client or other management application
>
>  by the way of an explicit management operation the
>
>  data node SHOULD be included.";
>
>
>
> AB: should follow 6243, section 3.3
>
>}
>
>  }
>
>  description
>
>"As instance-data-sets MAY contain incomplete data sets,
>
>  thus any data node MAY be absent.
>
>
>
>  Providing the instance-data-set intends to contain a
>
>  full data set, this leaf specifies whether the data set
>
>  includes data nodes that have a default defined and
>
>  where the actual value is the same as the default value.
>
>
>
>  Data nodes that have no default values should always
>
>  be included.
>
>  Data nodes that have a default value, but the actual
>
>  value is not equal to the schema defined default
>
>  should always be included.";
>
>
>
>
>
> AB: The last paragraph should be removed or changed. Why are these nodes 
> special?
>
> Nodes that are actually present and do not contain the YANG default
>
> are not relevant to this object.
>
> BALAZS3: OK
>
>
>
>  reference
>
>"RFC 6243 : 
> With-defaults Capability for NETCONF";
>
>}
>
>
>
> The best way to indicate a representation of a YANG default in the data
> set is to include
>
> the "default" attribute in each default node.
> https://datatracker.ietf.org/doc/html/rfc6243#section-6
>
> 

[netmod] netmod - New Meeting Session Request for IETF 112

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Lou Berger, a Chair of 
the netmod working group.


-
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger


Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 100
Conflicts to Avoid: 
 Chair conflict: netconf teas detnet
 Key participant conflict: raw ipsecme manet

   


People who must be present:
  Lou Berger
  Joel Jaeggli
  Kent Watsen
  Robert Wilton

Resources Requested:

Special Requests:
  
-


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

Re: [netmod] NULL value for uint16

[Ladislav Lhotka]

On 10. 09. 21 13:56, tom petch wrote:
> 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) ..'

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

> 
> 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
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

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

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

See below as BALAZS4

 

From: Andy Bierman  
Sent: 2021. szeptember 10., péntek 4:57
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Thu, Sep 9, 2021 at 6:19 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

See below as BALAZS3.

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. augusztus 25., szerda 18:29
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >; 
NetMod WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

Here is the latest text. It is inconsistent with RFC 6243, section 3.

IMO the subsections should be cited instead of the copy-and-change approach.

BALAZS3: The 6243 sections contain parts about “data retrieval” “capabilities” 
or “conceptual data nodes set by the server”

These parts are not relevant for many of the instance data use cases, so I 
would like to stick with including text here.

 

 

 

I guess I do not understand why the "with-defaults" leaf or at leaf 
"with-defaults-mode" typedef

cannot be used. IMO this is bad practice.  Applications that already know how 
to deal

with defaults according to RFC 6243 should be supported.

 

 

 leaf includes-defaults {

 type ncwd:with-defaults-mode;

 }

 

I do not see any text in this typedef that is server-specific.

Andy

BALAZS4:  While I generally agree that duplication is a bad practice, I avoided 
using ncwd:with-defaults-mode because:

*It references   RFC 
6243;   Section 3 
which is full of inappropriate references (server, data retrieval, capabilities)
*The typedef’s description is "Possible modes to report default data." 
However, in a number of use cases (e.g., UC2 Preloading default configuration 
data, UC7, U8) the data is not reported.
*report-all-tagged description contains “XML attribute” which is 
incorrect if we use JSON encoding
*I prefer to use the 2119 term SHALL, SHALL NOT in the enum 
descriptions.
Is this acceptable?
 

 

   leaf includes-defaults {
 type enumeration {
   enum report-all {
 value 1;
 description
   "All data nodes SHOULD be included independent of
 any default values.";
 
AB: should follow 6243, 3.1
   }
   enum trim {
 value 2;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD
 NOT be included.";
 
AB: should follow 6243, section 3.2
   }
   enum explicit {
 value 3;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD NOT be
 included. However, if the actual value was set by
 a NETCONF client or other management application
 by the way of an explicit management operation the
 data node SHOULD be included.";
 
AB: should follow 6243, section 3.3
   }
 }
 description
   "As instance-data-sets MAY contain incomplete data sets,
 thus any data node MAY be absent.
 
 Providing the instance-data-set intends to contain a
 full data set, this leaf specifies whether the data set
 includes data nodes that have a default defined and
 where the actual value is the same as the default value.
 
 Data nodes that have no default values should always
 be included.
 Data nodes that have a default value, but the actual
 value is not equal to the schema defined default
 should always be included.";
 
 
AB: The last paragraph should be removed or changed. Why are these nodes 
special?
Nodes that are actually present and do not contain the YANG default
are not relevant to this object.
BALAZS3: OK
 
 reference
   "RFC 6243  : 
With-defaults Capability for NETCONF";
   }

 

The best way to indicate a representation of a YANG default in the data set is 
to include

the "default" attribute in each default node. 
https://datatracker.ietf.org/doc/html/rfc6243#section-6

This actually works for explicit mode and leaf-lists (unlike the current 
solution).

BALAZS3: OK. Added report-all-tagged enum to includes-defaults leaf.

Here is the current proposed text:



leaf includes-defaults {

  type enumeration {

enum report-all {

  value 1;

  description

"All data nodes SHALL be included independent of

  any 

Re: [netmod] NULL value for uint16

[Jürgen Schönwälder]

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 +, tom petch wrote:
> 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
> ___
> netmod mailing list
> netmod@ietf.org
> 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 

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

[netmod] NULL value for uint16

[tom petch]

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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [bmwg] WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-06

[Vladimir Vassilev]

On 09/09/2021 12.05, tom petch wrote:

From: bmwg  on behalf of MORTON JR., AL 

Sent: 08 September 2021 14:35

BMWG:

A WG Adoption Call for the Internet-Draft on

   A YANG Data Model for Network Interconnect Tester Management
draft-vassilev-bmwg-network-interconnect-tester-06

will be open from 8 September through 6 October, 2021.

Please weigh-in on this topic by providing:

+ whether or not you believe the working group should adopt this Internet-Draft
as a work item, for eventual publication as an Informational RFC.
+ your current comments on the draft from your adoption call review
(recent comments on the list should be referenced).
+ whether or not you are willing to review new versions of the draft during
development.



Oppose

I commented in January and some of my comments have been addressed, some have 
not.

The one I regard as most significant is that this uses two character prefix for 
the YANG modules.  Prefix must be unique across the entire IETF, everything 
from every WG, everything not from a WG, so while brevity is attractive, I see 
them as belonging with modules that will be widely used, widely known - 
interfaces comes to mind. I do not see this in this category,

I have yet to see a YANG doctor approve of a two-character prefix but I have 
seen opposition.



There is no problem to add longer prefixes. "tg:" -> "nttg:", "ta:" -> 
"ntta:" where "nt" stands for network test.


The intention with this draft is to provide "widely used, widely known" 
modules. The equivalent of ping and tcpdump functionality in YANG terms 
but also very deterministic and precise method for specification of test 
traffic for the dataplane. If the IETF and the authors manage to pull 
this off these modules will be the base modules augmented by vendors of 
network test equipment and very likely regular networking equipment will 
have implementation for verification and troubleshooting purposes.


There is reference code that implements RFC2544 as a simple python 
script using the model specified in the draft - 
https://github.com/vlvassilev/litenc/blob/master/tntapi/example/ietf-network-interconnect-tester/rfc2544.py 



and a reference device side implementation with open-source and 
open-hardware design  - 
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c



significant part of this work was done at IETF Hackathon events.


/Vladimir




The author's response was to do it later n the process, that it would mean 
changing code.  Well the later in the process the more code there will be to 
change, more work, more mistakes from anyone involved..

There are other glitches in the  YANG module but I see this as the one to fix 
before considering any other.

Tom Petch


Send your comments to this list @b...@ietf.org

A URL for this Internet-Draft is [0]

Al
bmwg co-chair

[0] 
https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester-06.txt



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