Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

[mohamed.boucadair]

Hi Kent, 

There are not thousands of RFCs that include a "Module Review Checklist" :-), 
which is the purpose of this erratum. Thanks. 

Cheers,
Med

> -Message d'origine-
> De : Kent Watsen 
> Envoyé : jeudi 31 mars 2022 00:24
> À : RFC Errata System 
> Cc : BOUCADAIR Mohamed INNOV/NET ; Andy
> Bierman ; rfc...@rfc-editor.org; IESG
> ; netmod@ietf.org
> Objet : Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)
> 
> If this Errata is accepted, does it mean that an Errata will be filed
> for the thousands of RFCs that have been published since 2009 when the
> error was introduce in RFC 5691?
> 
> Kent
> 
> 
> > On Mar 30, 2022, at 5:20 PM, RFC Errata System  editor.org> wrote:
> >
> > The following errata report has been held for document update for
> > RFC8407, "Guidelines for Authors and Reviewers of Documents Containing
> YANG Data Models".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6899
> >
> > --
> > Status: Held for Document Update
> > Type: Editorial
> >
> > Reported by: Mohamed Boucadair  Date
> > Reported: 2022-03-29 Held by: RFC Editor
> >
> > Section: Appendix A
> >
> > Original Text
> > -
> >   o  License -- verify that the document contains the Simplified BSD
> >  License in each YANG module or submodule.  Some guidelines
> related
> >  to this requirement are described in Section 3.1.  Make sure that
> >  the correct year is used in all copyright dates.  Use the
> approved
> >  text from the latest TLP document, which can be found at:
> >
> > Corrected Text
> > --
> >   o  License -- verify that the document contains the Revised BSD
> >  License in each YANG module or submodule.  Some guidelines
> related
> >  to this requirement are described in Section 3.1.  Make sure that
> >  the correct year is used in all copyright dates.  Use the
> approved
> >  text from the latest TLP document, which can be found at:
> >
> > Notes
> > -
> > https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ says:
> >
> > ==
> > Note: in prior versions of these provisions, the software license was
> erroneously called the “Simplified BSD License” rather than the “Revised
> BSD License”, and many documents that refer to these provisions copied
> the erroneous name. The IETF Trust corrected the error on September 21,
> 2021. The license text itself was always that of the Revised BSD License
> and has not changed.
> > ==
> > --VERIFIER NOTES--
> > Approved by John Levine (Temporary RFC Series Project Manager and
> member of the IETF Trust).
> >
> > --
> > RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> > --
> > Title   : Guidelines for Authors and Reviewers of
> Documents Containing YANG Data Models
> > Publication Date: October 2018
> > Author(s)   : A. Bierman
> > Category: BEST CURRENT PRACTICE
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

[Sandy Ginoza]

Hi Kent,

I hope not.  Per discussion with John Levine (Temporary RFC Series Project 
Manager and member of the IETF Trust), we have marked this item as Held for 
Document Update .

Thanks,
Sandy 


> On Mar 30, 2022, at 3:23 PM, Kent Watsen  wrote:
> 
> If this Errata is accepted, does it mean that an Errata will be filed for the 
> thousands of RFCs that have been published since 2009 when the error was 
> introduce in RFC 5691?
> 
> Kent 
> 
> 
>> On Mar 30, 2022, at 5:20 PM, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been held for document update 
>> for RFC8407, "Guidelines for Authors and Reviewers of Documents Containing 
>> YANG Data Models". 
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6899
>> 
>> --
>> Status: Held for Document Update
>> Type: Editorial
>> 
>> Reported by: Mohamed Boucadair 
>> Date Reported: 2022-03-29
>> Held by: RFC Editor  
>> 
>> Section: Appendix A
>> 
>> Original Text
>> -
>>  o  License -- verify that the document contains the Simplified BSD
>> License in each YANG module or submodule.  Some guidelines related
>> to this requirement are described in Section 3.1.  Make sure that
>> the correct year is used in all copyright dates.  Use the approved
>> text from the latest TLP document, which can be found at:
>> 
>> Corrected Text
>> --
>>  o  License -- verify that the document contains the Revised BSD
>> License in each YANG module or submodule.  Some guidelines related
>> to this requirement are described in Section 3.1.  Make sure that
>> the correct year is used in all copyright dates.  Use the approved
>> text from the latest TLP document, which can be found at:
>> 
>> Notes
>> -
>> https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ says:
>> 
>> ==
>> Note: in prior versions of these provisions, the software license was 
>> erroneously called the “Simplified BSD License” rather than the “Revised BSD 
>> License”, and many documents that refer to these provisions copied the 
>> erroneous name. The IETF Trust corrected the error on September 21, 2021. 
>> The license text itself was always that of the Revised BSD License and has 
>> not changed.
>> ==
>> --VERIFIER NOTES--
>> Approved by John Levine (Temporary RFC Series Project Manager and member of 
>> the IETF Trust).
>> 
>> --
>> RFC8407 (draft-ietf-netmod-rfc6087bis-20)
>> --
>> Title   : Guidelines for Authors and Reviewers of Documents 
>> Containing YANG Data Models
>> Publication Date: October 2018
>> Author(s)   : A. Bierman
>> Category: BEST CURRENT PRACTICE
>> Source  : Network Modeling
>> Area: Operations and Management
>> Stream  : IETF
>> 
>> ___
>> 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

[netmod] Email Request

[Kent Watsen]

This is going to sound old-school, but please try to use standard 
email-indentations when replying to others on this list.  Exception, of course, 
when top-posting, which is understandably preferred sometimes.

Most SMTP-clients support indentation automatically, while others need to be 
configured.  It was nearly 15-years ago, back when I was using Outlook, when 
someone in the IETF clued me in that Outlook had a configurable option to set 
indents.

Indentations, when supported by SMTP-clients, greatly facilitate readability.  
Not only is the text successively-indented (physical offsets), but also many 
times colorized (based on indent-level, per client-prefs), and sometimes 
collapsible.

Speaking of color, please do not use colors as it may cause 
accessibility-issues: 1) some are color-blind (I for one have a doppler-shift 
that makes RED very difficult to read), 2) colors don't render well on all 
displays (e.g., dark-mode vs. light-mode), 3) colors interferes with 
SMTP-client's color-preference settings.

Thank you,
Kent and Lou  (NETMOD Chairs)


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

Re: [netmod] [Errata Held for Document Update] RFC8407 (6899)

[Kent Watsen]

If this Errata is accepted, does it mean that an Errata will be filed for the 
thousands of RFCs that have been published since 2009 when the error was 
introduce in RFC 5691?

Kent 


> On Mar 30, 2022, at 5:20 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been held for document update 
> for RFC8407, "Guidelines for Authors and Reviewers of Documents Containing 
> YANG Data Models". 
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6899
> 
> --
> Status: Held for Document Update
> Type: Editorial
> 
> Reported by: Mohamed Boucadair 
> Date Reported: 2022-03-29
> Held by: RFC Editor  
> 
> Section: Appendix A
> 
> Original Text
> -
>   o  License -- verify that the document contains the Simplified BSD
>  License in each YANG module or submodule.  Some guidelines related
>  to this requirement are described in Section 3.1.  Make sure that
>  the correct year is used in all copyright dates.  Use the approved
>  text from the latest TLP document, which can be found at:
> 
> Corrected Text
> --
>   o  License -- verify that the document contains the Revised BSD
>  License in each YANG module or submodule.  Some guidelines related
>  to this requirement are described in Section 3.1.  Make sure that
>  the correct year is used in all copyright dates.  Use the approved
>  text from the latest TLP document, which can be found at:
> 
> Notes
> -
> https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ says:
> 
> ==
> Note: in prior versions of these provisions, the software license was 
> erroneously called the “Simplified BSD License” rather than the “Revised BSD 
> License”, and many documents that refer to these provisions copied the 
> erroneous name. The IETF Trust corrected the error on September 21, 2021. The 
> license text itself was always that of the Revised BSD License and has not 
> changed.
> ==
> --VERIFIER NOTES--
> Approved by John Levine (Temporary RFC Series Project Manager and member of 
> the IETF Trust).
> 
> --
> RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> --
> Title   : Guidelines for Authors and Reviewers of Documents 
> Containing YANG Data Models
> Publication Date: October 2018
> Author(s)   : A. Bierman
> Category: BEST CURRENT PRACTICE
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> 
> ___
> 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] Balazs Review of draft-ma-netmod-with-system-02

[Balázs Lengyel]

See BALAZS3 below.
regards Balazs

From: Jan Lindblad 
Sent: Wednesday, 30 March, 2022 16:12
To: Balázs Lengyel ; maqiufang (A) 

Cc: NetMod WG 
Subject: Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello Balázs, Qiufang,

I've added some comments below as JANL.

Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there 
are still a couple of comments that need further discussion, like:

·Terminology to differentiate between the same(-path) data nodes in 
different datastores(e.g., system and running).
BALAZS2: MY best idea is to ALWAYS say:
   The “interface data node in ”
   “/running/interfaces/interface/name”  - so prefix the datastore 
name to the path

JANL: Actually, I think this notation is rather confusing. How about 
:running:/interfaces/interface/name ?
BALAZS3:OK, I tried to follow the Restconf notation, but I am ok with your 
proposal.



·Should “copy-config” operation also be augmented to support 
“resolve-system” parameter?
BALAZS2: IMO yes. If you copy a complete configuration from a file to running, 
you will still need parts of  to make the new content of  
valid.

JANL: I think this makes sense.


·The potential NBC issue behind this principle: If the "resolve-system" 
parameter is not given by the client, the server MUST NOT modify  in 
any way not specified by the client.
BALAZS2: I very strongly oppose this restriction because it is: a bad idea, 
unenforceable, NBC and would be a problem for other SDOs.

JANL: I could accept watering down MUST NOT to SHOULD NOT.
BALAZS3: Sorry, I know system-set data has its problems, but my arguments still 
stand.


·Will the update of  be reflected into ? If not, will 
this cause an invalid  datastore?
BALAZS2: I see this similar as an upgrade problem. Following RFC7950 section 11 
rules: During an upgrade you may obsolete a schema node, this remove it, or you 
may add a default value. Both changes may make an existing configuration 
invalid. System configuration should also be changed only very carefully 
because it may cause an invalid configuration, in which case the change to 
system-configuration probably should be rejected / not-allowed.

JANL: At system upgrade, I think autoconfig (system modifying its own 
configuration) is acceptable. Such changes could be seen as actions made by a 
system-internal client.

Automatic updates in running is a tricky problem. E.g. will you remove 
configuration of an interface if the HW is removed? There might be a lot of 
data nodes configured based on it. There might be leafrefs pointing at the 
interface.

JANL: As many of you know, I'm not particularly happy about such changes (I 
prefer the configuration to be left intact, but the oper state to change to 
down/hardware-missing, etc) but if someone insists, these situations too could 
be seen as management operations executed over a different protocol (the 
operator-manipulates-the-hardware-protocol). In this case the system-internal 
client making config updates is responsible for ensuring running stays valid at 
all times.
BALAZS3:  I see this similar to an upgrade. At time of an upgrade or 
system-config changes you may need to adjust your configuration. E.g. confd 
does that. IMHO changing the system-configuration is just as serious matter as 
an upgrade. It should happen rarely and be done carefully. I don’t have a 
strong opinion about this yet, but I feel we should describe whatever should be 
happening.

In section 1) we indicate automatically updating the interfaces depending on HW 
changes.  I would REALLY ! like a detailed description of this use-case. 
That would help me understand our plans better.
As I understand
when an interface is plugged in
- it will be automatically  created in  with list-entry, name, type.
-  will NOT be updated automatically
The client might copy over the created :system:/interfaces/interface into 

The client may use resolve-system property to implicitly copy over the 
:system:/interfaces/interface into 

Can a client set a different type to 
:running:/interfaces/interface[name=if0]/type then what is automatically set in 
:system:/interfaces/interface[name=if0]/type ?
- If yes, that might lead to confusion, misconfiguration (might use an 
operationalState leaf to indicate this)
- if no, this is a constraint between 2 datastores that needs to be cleanly 
explained in the draft and specified in the model
One idea for this would be to introduce a new value for the immutable flag (in 
the other draft) for the schema node “system-defined-value” meaning that the 
value in  and/or  MUST be the same as the value in  
(if system datastore is supported) otherwise the same as in  (if 
that system datastore is not supported but operational is) or the same as a 
system defined value documented in an implementation specific manner (if 
neither system nor operational is 

[netmod] [Errata Held for Document Update] RFC8407 (6899)

[RFC Errata System]

The following errata report has been held for document update 
for RFC8407, "Guidelines for Authors and Reviewers of Documents Containing YANG 
Data Models". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6899

--
Status: Held for Document Update
Type: Editorial

Reported by: Mohamed Boucadair 
Date Reported: 2022-03-29
Held by: RFC Editor  

Section: Appendix A

Original Text
-
   o  License -- verify that the document contains the Simplified BSD
  License in each YANG module or submodule.  Some guidelines related
  to this requirement are described in Section 3.1.  Make sure that
  the correct year is used in all copyright dates.  Use the approved
  text from the latest TLP document, which can be found at:

Corrected Text
--
   o  License -- verify that the document contains the Revised BSD
  License in each YANG module or submodule.  Some guidelines related
  to this requirement are described in Section 3.1.  Make sure that
  the correct year is used in all copyright dates.  Use the approved
  text from the latest TLP document, which can be found at:

Notes
-
https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ says:

==
Note: in prior versions of these provisions, the software license was 
erroneously called the “Simplified BSD License” rather than the “Revised BSD 
License”, and many documents that refer to these provisions copied the 
erroneous name. The IETF Trust corrected the error on September 21, 2021. The 
license text itself was always that of the Revised BSD License and has not 
changed.
==
 --VERIFIER NOTES--
Approved by John Levine (Temporary RFC Series Project Manager and member of the 
IETF Trust).

--
RFC8407 (draft-ietf-netmod-rfc6087bis-20)
--
Title   : Guidelines for Authors and Reviewers of Documents 
Containing YANG Data Models
Publication Date: October 2018
Author(s)   : A. Bierman
Category: BEST CURRENT PRACTICE
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF

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

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[Jan Lindblad]

Hello Balázs, Qiufang,

I've added some comments below as JANL.

> Hi, Balazs,
> Thanks for your thorough review and valuable comments!
> To be brief, I will incorporate some of them to the update, but I think there 
> are still a couple of comments that need further discussion, like:
> Terminology to differentiate between the same(-path) data nodes in different 
> datastores(e.g., system and running).
> BALAZS2: MY best idea is to ALWAYS say:
>The “interface data node in ”
>“/running/interfaces/interface/name”  - so prefix the 
> datastore name to the path

JANL: Actually, I think this notation is rather confusing. How about 
:running:/interfaces/interface/name ?

> Should “copy-config” operation also be augmented to support “resolve-system” 
> parameter?
> BALAZS2: IMO yes. If you copy a complete configuration from a file to 
> running, you will still need parts of  to make the new content of 
>  valid.

JANL: I think this makes sense.

> The potential NBC issue behind this principle: If the "resolve-system" 
> parameter is not given by the client, the server MUST NOT modify  in 
> any way not specified by the client.
> BALAZS2: I very strongly oppose this restriction because it is: a bad idea, 
> unenforceable, NBC and would be a problem for other SDOs.

JANL: I could accept watering down MUST NOT to SHOULD NOT.

> Will the update of  be reflected into ? If not, will this 
> cause an invalid  datastore?
> BALAZS2: I see this similar as an upgrade problem. Following RFC7950 section 
> 11 rules: During an upgrade you may obsolete a schema node, this remove it, 
> or you may add a default value. Both changes may make an existing 
> configuration invalid. System configuration should also be changed only very 
> carefully because it may cause an invalid configuration, in which case the 
> change to system-configuration probably should be rejected / not-allowed.  

JANL: At system upgrade, I think autoconfig (system modifying its own 
configuration) is acceptable. Such changes could be seen as actions made by a 
system-internal client.

> Automatic updates in running is a tricky problem. E.g. will you remove 
> configuration of an interface if the HW is removed? There might be a lot of 
> data nodes configured based on it. There might be leafrefs pointing at the 
> interface.

JANL: As many of you know, I'm not particularly happy about such changes (I 
prefer the configuration to be left intact, but the oper state to change to 
down/hardware-missing, etc) but if someone insists, these situations too could 
be seen as management operations executed over a different protocol (the 
operator-manipulates-the-hardware-protocol). In this case the system-internal 
client making config updates is responsible for ensuring running stays valid at 
all times.

Best Regards,
/jan



> From: netmod [mailto:netmod-boun...@ietf.org 
> ] On Behalf Of Balázs Lengyel
> Sent: Thursday, March 24, 2022 2:47 AM
> To: 'netmod@ietf.org '  >
> Subject: [netmod] Balazs Review of draft-ma-netmod-with-system-02
>  
> Hello,
> I did a detailed review of the system draft. My comments questions are below.
> Regards Balazs
>  
> ===
>  
> General)
> I think this work is important and valuable, but it needs quite a lot 
> improvements.
>  
> The term system-configuration is used confusingly. Does 
> system-configuration reside in the  datastore only or can it
> reside in the  datastore too? If system-configuration is copied by
> the client (+) into the  datastore is it
> still system-configuration? It is set by the client this time not the system.
> [Qiufang] Yes, I agree.
> System configuration is provided by the device in  datastore, though 
> I think it may also be present in  with origin=”system”.
> If it is copied/pasted into , the copied configuration in  
> should not be called as “system configuration”.
> But I think it’s okay to say something like “copy system configuration into 
> ”, the object to be copied is system configuration which is defined 
> in .
> BALAZS2: So the definition of system-config is:
> System configuration:  Configuration that is provided by the system itself. 
> It is the configuration that is stored in the  datastore or the 
> configuration data stored in the  datastore with origin=system.
> This means that 
> Some terminology is needed to indicate that you mean a specific data node
> IN A SPECIFIC DATASTORE. The same data node (according to the path in the
> data tree) in different datastores need to be referenced separately.
> [Qiufang]Cross-datastores references is not the intention here.
> Any suggestions to make it clear or what does the terminology looks like in 
> your mind?
>  
> Does the solution allow conditional system configuration? 
> (E.g.,  if the client creates an OSPF interface the system inserts a child 
> leaf into it)
> 

Re: [netmod] RFC 7951 - JSON encoding of empty lists

[Kent Watsen]

> Also note that #1 isn't really of much use, as entire list and leaf-list 
> instances aren't even resources/endpoints in RESTCONF API - e.g. it's not 
> possible to GET the entire list.

True, but the “list-pagination” drafts (adoption-call in NETCONF) seek to 
change this. 

K. 



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

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[Balázs Lengyel]

Hello Quifang,
See comments as BALAZS2 below.
Regards Balazs

From: maqiufang (A) 
Sent: Tuesday, 29 March, 2022 08:10
To: Balázs Lengyel 
Cc: NetMod WG 
Subject: RE: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there 
are still a couple of comments that need further discussion, like:

  *   Terminology to differentiate between the same(-path) data nodes in 
different datastores(e.g., system and running).
BALAZS2: MY best idea is to ALWAYS say:
   The "interface data node in "
   "/running/interfaces/interface/name"  - so prefix the datastore 
name to the path

  *   Should "copy-config" operation also be augmented to support 
"resolve-system" parameter?
BALAZS2: IMO yes. If you copy a complete configuration from a file to running, 
you will still need parts of  to make the new content of  
valid.

  *   The potential NBC issue behind this principle: If the "resolve-system" 
parameter is not given by the client, the server MUST NOT modify  in 
any way not specified by the client.
BALAZS2: I very strongly oppose this restriction because it is: a bad idea, 
unenforceable, NBC and would be a problem for other SDOs.

  *   Will the update of  be reflected into ? If not, will 
this cause an invalid  datastore?
BALAZS2: I see this similar as an upgrade problem. Following RFC7950 section 11 
rules: During an upgrade you may obsolete a schema node, this remove it, or you 
may add a default value. Both changes may make an existing configuration 
invalid. System configuration should also be changed only very carefully 
because it may cause an invalid configuration, in which case the change to 
system-configuration probably should be rejected / not-allowed.
Automatic updates in running is a tricky problem. E.g. will you remove 
configuration of an interface if the HW is removed? There might be a lot of 
data nodes configured based on it. There might be leafrefs pointing at the 
interface.


Please also see my detailed reply inline.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: Thursday, March 24, 2022 2:47 AM
To: 'netmod@ietf.org' mailto:netmod@ietf.org>>
Subject: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello,
I did a detailed review of the system draft. My comments questions are below.
Regards Balazs

===

General)
I think this work is important and valuable, but it needs quite a lot 
improvements.

The term system-configuration is used confusingly. Does
system-configuration reside in the  datastore only or can it
reside in the  datastore too? If system-configuration is copied by
the client (+) into the  datastore is it
still system-configuration? It is set by the client this time not the system.
[Qiufang] Yes, I agree.
System configuration is provided by the device in  datastore, though I 
think it may also be present in  with origin="system".
If it is copied/pasted into , the copied configuration in  
should not be called as "system configuration".
But I think it's okay to say something like "copy system configuration into 
", the object to be copied is system configuration which is defined in 
.
BALAZS2: So the definition of system-config is:
System configuration:  Configuration that is provided by the system itself. It 
is the configuration that is stored in the  datastore or the 
configuration data stored in the  datastore with origin=system.
This means that
Some terminology is needed to indicate that you mean a specific data node
IN A SPECIFIC DATASTORE. The same data node (according to the path in the
data tree) in different datastores need to be referenced separately.
[Qiufang]Cross-datastores references is not the intention here.
Any suggestions to make it clear or what does the terminology looks like in 
your mind?

Does the solution allow conditional system configuration?
(E.g.,  if the client creates an OSPF interface the system inserts a child leaf 
into it)
[Qiufang] Yes, it does. System configurations which are provided and activated 
based on specific conditions being met in a system, it is defined as 
"Conditionally-Active system configuration".
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02.txt#section-2.2
 describes this kind of system configuration.

1.1) If system shares the same schema as running that would force it to
populate mandatory nodes.  That might be a problem.
State that mandatory or min-elements might not be enforced in .
[Qiufang] I think that mandatory or min/max-elements nodes should be enforced 
in . There should be no exceptions.
What's the problem that you think might happen?
1.3) "client may overwrite values of configurations defined in "
However it also states: The contents of  datastore are read-only
These seem to contradict. Please clarify.

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[mohamed.boucadair]

Hi all,

FWIW, a new version with the change of a normative language is available at:


URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-03.txt

Status: 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-boucadair-netmod-iana-registries-03

Cheers,
Med

De : netmod  De la part de mohamed.boucad...@orange.com
Envoyé : mardi 29 mars 2022 07:44
À : Andy Bierman 
Cc : netmod@ietf.org
Objet : Re: [netmod] TR: New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt

Hi Andy,

Thank you for sharing the feedback.

For the paragraph you quoted, I removed the normative language from the first 
sentence.

The other parts of that paragraph are useful as they call an important aspect 
that is only supported with identities + the guideline to document the 
reasoning. Will keep that text. Thank you.

Cheers,
Med

De : Andy Bierman mailto:a...@yumaworks.com>>
Envoyé : lundi 28 mars 2022 20:05
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Ladislav Lhotka mailto:ladislav.lho...@nic.cz>>; 
Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>;
 netmod@ietf.org
Objet : Re: [netmod] TR: New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt

Hi,

I read the -02 draft.
It does not conflict with RFC 8407.
I don't think sec 3, para 3 is really needed, but the guideline to document the
reasoning behind using enum vs. identity is more relevant for IANA modules than 
other modules.


Andy



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [netmod] RFC 7951 - JSON encoding of empty lists

[Ladislav Lhotka]

Hi,

Jack Rickard  writes:

> Hi,
>
> I think I've found an ambiguity in RFC 7951, and I'd like your input on what 
> was intended and what the best behaviour to exhibit is.
>
> Section 5.3 and 5.4 of RFC 7951 - JSON Encoding of Data Modeled with YANG 
> (ietf.org) 
> describe the encoding of leaf-lists and lists, however it's unclear how an 
> empty list should be encoded. Should it be encoded as:
>
>   1.  An empty array: {"list": []}
>   2.  A missing field: {}

Both variants are equivalent and should be supported by tools and libraries.

I can understand though that tools supporting both XML and JSON representations 
tend to prefer #2 because #1 doesn't exist in XML.

Also note that #1 isn't really of much use, as entire list and leaf-list 
instances aren't even resources/endpoints in RESTCONF API - e.g. it's not 
possible to GET the entire list.

Lada

>
> I've seen libraries go either way, libyang only accepts 2 but the python 
> yangson library accepts both (I'm not sure which is the default).
>
> Thanks,
> Jack Rickard
> he/him
> Software Engineer
> jack.rick...@microsoft.com
>
> [Microsoft Logo]
>
>
> ___
> 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