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

[Andy Bierman]

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

   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 default values, if the data node
>
>   is covered by the instance-data-set.";
>
> }
>
> enum report-all-tagged  {
>
>   value 2;
>
>   description
>
> "All data nodes SHALL be included independent of
>
>   any default values if the data node
>
>   is covered by the instance-data-set.
>
>   Any nodes considered to be default data SHALL
>
>   contain a 'default' attribute set to 'true'";
>
> }
>
> enum trim {
>
>   value 3;
>
>   description
>
> "Data nodes that have a default defined and where
>
>   the actual value is equal to the schema default
>
>   value SHALL NOT be included.";
>
> }
>
> enum explicit {
>
>   value 4;
>
>   description
>
>  

Re: [netmod] Unknown idnits error

[Carsten Bormann]

On 2021-09-09, at 23:40, Balázs Lengyel  wrote:
> 
> AFAIK I did not copy any old material. Balazs

Indeed, so you can ignore this message.

> Sadly to...@ietf.org returns with “Unknown To address”

I think tools-disc...@ietf.org was meant here.

But I don’t think new light will be generated there, except for the observation 
that the idnits backend is up for some re-integration work, so hiccups like 
this are currently not unlikely.

Grüße, Carsten


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

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-18.txt
Pages   : 28
Date: 2021-09-09

Abstract:
   There is a need to document data defined in YANG models at design
   time, implementation time or when a live server is unavailable.  This
   document specifies a standard file format for YANG instance data,
   which follows the syntax and semantics of existing YANG models, and
   annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-18


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

AFAIK I did not copy any old material. Balazs

-Original Message-
From: Carsten Bormann  
Sent: 2021. szeptember 9., csütörtök 23:25
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Unknown idnits error

On 2021-09-09, at 19:12, Balázs Lengyel 
 wrote:
> 
> Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.

My experience is that this message is caused by hiccups of the idnits tool in 
retrieving metadata.

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ 
certainly has no problems figuring that out.

(The question is whether you are copying from/evolving from material that was 
submitted before RFC 5378 went into force, in which case you might need a 
different ipr= attribute.  Most likely your text is not that old!  So this is a 
red herring.)

Grüße, Carsten


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

Sadly to...@ietf.org   returns with “Unknown To address”

Balazs

 

From: Balázs Lengyel 
Sent: 2021. szeptember 9., csütörtök 23:17
To: Mahesh Jethanandani 
Cc: netmod@ietf.org
Subject: RE: [netmod] Unknown idnits error

 

I got this warning while running the web based idnits tool. 
https://tools.ietf.org/tools/idnits/

It might indicate some real problem, but it is impossible to understand from 
the failure message, what it is.

Regards Balazs

 

From: Mahesh Jethanandani mailto:mjethanand...@gmail.com> > 
Sent: 2021. szeptember 9., csütörtök 20:15
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: netmod@ietf.org  
Subject: Re: [netmod] Unknown idnits error

 

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org   and 
have them look at it.

 

On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

I am trying to check/submit a new version of my 
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now suddenly I 
get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at   
https://trustee.ietf.org/license-info to determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to get 
rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
 balazs.leng...@ericsson.com

 

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

 

Mahesh Jethanandani

mjethanand...@gmail.com  

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown idnits error

[Carsten Bormann]

On 2021-09-09, at 19:12, Balázs Lengyel 
 wrote:
> 
> Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.

My experience is that this message is caused by hiccups of the idnits tool in 
retrieving metadata.

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ 
certainly has no problems figuring that out.

(The question is whether you are copying from/evolving from material that was 
submitted before RFC 5378 went into force, in which case you might need a 
different ipr= attribute.  Most likely your text is not that old!  So this is a 
red herring.)

Grüße, Carsten

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

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

I got this warning while running the web based idnits tool. 
https://tools.ietf.org/tools/idnits/

It might indicate some real problem, but it is impossible to understand from 
the failure message, what it is.

Regards Balazs

 

From: Mahesh Jethanandani  
Sent: 2021. szeptember 9., csütörtök 20:15
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Unknown idnits error

 

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org   and 
have them look at it.





On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

I am trying to check/submit a new version of my 
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now suddenly I 
get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at   
https://trustee.ietf.org/license-info to determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to get 
rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
 balazs.leng...@ericsson.com

 

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

 

Mahesh Jethanandani

mjethanand...@gmail.com  

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Thu, Sep 9, 2021 at 4:51 AM Balázs Lengyel 
wrote:

> Hello Andy,
>
> See below as BALAZS2.
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. augusztus 24., kedd 13:35
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Tue, Aug 24, 2021 at 1:41 AM Balázs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
> Hello Andy,
>
> In the -17 I removed the default value for includes-defaults as you
> proposed.
>
>
>
> I am not sure I understand the rest of the comments as
> instance-file-format does not use the concept of “basic-mode”. It has a
> single leaf to indicate what is the situation with defaults in the specific
> instance-data-set.
>
> As this is not a live server request/reply situation we do not want to
> specify a basic and additional modes, we just want to specify the handling
> used for this specific instance data set.
>
>
>
>
>
> The draft as written does not actually provide the same utility as
> .
>
> (Without the "default" attribute the "explicit" mode is not actually
> supported.)
>
>
>
> The "with-defaults" mechanism works exactly the same no matter what
>
> the XML representation is used for.  The mode used to write the data will
>
> correspond to the basic-mode with the same name.
>
> BALAZS2: I will add the report-all-tagged mode to the leaf includes-defaults. 
> This will include the usage of default attribute in the instance data. Will 
> that make the attribute acceptable for you ?
>
>

yes


Andy




>
>
> Regards Balazs
>
>
>
> Andy
>
>
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. augusztus 23., hétfő 18:58
> *To:* Balázs Lengyel 
> *Cc:* Rob Wilton (rwilton) ; NetMod WG  >
> *Subject:* Re: [netmod] yang-instance-file include-defaults leaf
>
>
>
>
>
>
>
> On Mon, Aug 23, 2021 at 5:17 AM Balázs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
> Hello Rob,
>
> I think this won’t fly.
>
> In sections 1.2 and 2 we state:
>
> *“Instance data files MAY contain partial data sets.”*
>
> Which is important for many use-cases.  This means you cannot say that a 
> default value will or must be included, as they might be omitted because they 
> are not part of the partial data set.
>
> In a way it is difficult to separate between leaves that are missing because
>
> -They are not part of the partial data-set
>
> -They are omitted because they have the default value and one of the 
> trim or explicit options is used
>
> If this becomes important the report-all options shall be used.
>
>
>
>
>
>
>
> I thought we already agreed there cannot be a default or there is no way to
>
> represent "no defaults added".
>
>
>
> Note that "report-all" is not useful if basic-mode=explicit, since a leaf
> reporting the YANG default
>
> could be set by the client.  Only report-all-tagged will clearly identify
> defaults in this case.
>
>
>
> Also note that if basic-mode=report-all then there will be no defaults
> ever reported.
>
> This mode means the server does not consider any node to be a default and
> always returns
>
> every node (if with-defaults used or not).
>
>
>
> This is the reason I used the SHOULD word.
>
> Regards Balazs
>
>
>
> Andy
>
>
>
>
>
> *From:* Rob Wilton (rwilton) 
> *Sent:* 2021. augusztus 23., hétfő 12:27
> *To:* Balázs Lengyel ; Andy Bierman <
> a...@yumaworks.com>; NetMod WG 
> *Subject:* RE: [netmod] yang-instance-file include-defaults leaf
>
>
>
> Hi Balazs, Andy, Netmod,
>
>
>
> Sorry for the delayed response.  I would still like to strength the
> description of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.
>
>
>
> Hence, I have generated some proposed alternative descriptions, that are
> somewhat stricter, but also more generically focussed only on the default
> values.
>
>
>
> With these definitions, I think that we could define the
> “include-defaults” default value to be “explicit”, since if the leaf if not
> included, then I think that this effectively what the meaning would be
> anyway.
>
>
>
>
>
> In particular, I would propose changing the descriptions as follows:
>
>
>
>leaf includes-defaults {
>
>  type enumeration {
>
>enum report-all {
>
>  value 1;
>
>  description
>
>"All data nodes SHOULD be included independent of
>
>  any default values.";
>
>}
>
>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.";
>
>}
>
>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 

Re: [netmod] Unknown idnits error

[Mahesh Jethanandani]

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org  and 
have them look at it.

> On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> I am trying to check/submit a new version of my 
> draft-ietf-netmod-yang-instance-file-format-18.
>  
> The previous version did not have any idnits errors or warnings. Now suddenly 
> I get: 
>  
> == Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.  Please check the Legal
>  Provisions document at https://trustee.ietf.org/license-info 
>  to determine
>  if you need the pre-RFC5378 disclaimer.
> I did not change any boilerplate info. Why do I get this warning and how to 
> get rid of it?
>  
> I use xml2rfc. My draft includes:
>  
>  docName="draft-ietf-netmod-yang-instance-file-format-18">
> 
>  
> Help, Balazs
>  
>  
> -- 
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> 
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
Mahesh Jethanandani
mjethanand...@gmail.com





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

[netmod] Unknown idnits error

[Balázs Lengyel]

Hello,

I am trying to check/submit a new version of my
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now
suddenly I get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at https://trustee.ietf.org/license-info to
determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to
get rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

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.

 

   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 default values, if the data node 

  is covered by the instance-data-set.";

}

enum report-all-tagged  {

  value 2;

  description

"All data nodes SHALL be included independent of

  any default values if the data node 

  is covered by the instance-data-set.

  Any nodes considered to be default data SHALL

  contain a 'default' attribute set to 'true'";

}

enum trim {

  value 3;

  description

"Data nodes that have a default defined and where

  the actual value is equal to the schema default  

  value SHALL NOT be included.";

}

enum explicit {

  value 4;

  description

"Data nodes where the actual value is equal to the 

  schema default value SHALL 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 

  SHALL be included, if the data node is covered by 

  the instance-data-set.";

}

  }

  description

"An instance-data-set may contain or exclude default 

  data. This leaf indicates whether default data is 

  included. 

  

  As instance-data-sets MAY contain incomplete data 

  sets: MAY NOT cover all data nodes. A leaf or 

  leaf-list MAY be absent because the 

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

[Balázs Lengyel]

Hello Andy,

See below as BALAZS2.

 

From: Andy Bierman  
Sent: 2021. augusztus 24., kedd 13:35
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Tue, Aug 24, 2021 at 1:41 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

In the -17 I removed the default value for includes-defaults as you proposed.

 

I am not sure I understand the rest of the comments as instance-file-format 
does not use the concept of “basic-mode”. It has a single leaf to indicate what 
is the situation with defaults in the specific instance-data-set.

As this is not a live server request/reply situation we do not want to specify 
a basic and additional modes, we just want to specify the handling used for 
this specific instance data set.

 

 

The draft as written does not actually provide the same utility as 
.

(Without the "default" attribute the "explicit" mode is not actually supported.)

 

The "with-defaults" mechanism works exactly the same no matter what

the XML representation is used for.  The mode used to write the data will

correspond to the basic-mode with the same name.

BALAZS2: I will add the report-all-tagged mode to the leaf includes-defaults. 
This will include the usage of default attribute in the instance data. Will 
that make the attribute acceptable for you ?

 

Regards Balazs

 

Andy

 

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. augusztus 23., hétfő 18:58
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

 

 

 

On Mon, Aug 23, 2021 at 5:17 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Rob,

I think this won’t fly. 

In sections 1.2 and 2 we state:

“Instance data files MAY contain partial data sets.”
Which is important for many use-cases.  This means you cannot say that a 
default value will or must be included, as they might be omitted because they 
are not part of the partial data set.
In a way it is difficult to separate between leaves that are missing because
-They are not part of the partial data-set
-They are omitted because they have the default value and one of the 
trim or explicit options is used
If this becomes important the report-all options shall be used.
 

 

 

I thought we already agreed there cannot be a default or there is no way to

represent "no defaults added".

 

Note that "report-all" is not useful if basic-mode=explicit, since a leaf 
reporting the YANG default

could be set by the client.  Only report-all-tagged will clearly identify 
defaults in this case.

 

Also note that if basic-mode=report-all then there will be no defaults ever 
reported.

This mode means the server does not consider any node to be a default and 
always returns

every node (if with-defaults used or not).

 

This is the reason I used the SHOULD word.
Regards Balazs

 

Andy

 

 

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com> > 
Sent: 2021. augusztus 23., hétfő 12:27
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >; Andy Bierman mailto:a...@yumaworks.com> >; NetMod WG mailto:netmod@ietf.org> >
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hi Balazs, Andy, Netmod,

 

Sorry for the delayed response.  I would still like to strength the description 
of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

 

Hence, I have generated some proposed alternative descriptions, that are 
somewhat stricter, but also more generically focussed only on the default 
values.

 

With these definitions, I think that we could define the “include-defaults” 
default value to be “explicit”, since if the leaf if not included, then I think 
that this effectively what the meaning would be anyway.

 

 

In particular, I would propose changing the descriptions as follows:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "All data nodes SHOULD be included independent of

 any default values.";

   }

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

   }

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

   }