Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Andy Bierman]

On Wed, Mar 23, 2022 at 4:33 PM Balázs Lengyel  wrote:

> *From:* Kent Watsen 
> *Sent:* Thursday, 24 March, 2022 00:05
> *To:* Balázs Lengyel 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] Common etag, timestamp on all interfaces
> (draft-lindblad-netconf-transaction-id)
>
>
>
>
>
>
>
> I assume that the etag defined in your I-D is the same as the one defined
> in Restconf. Does or should your draft include a statement like:
>
> “The etag values maintained by the server are protocol/interface
> independent. If requested the same etag values will be visible on all
> interface including Restconf, Netconf, CLI etc.”
>
>
>
> While it makes sense that a server would use the same values across
> protocols, I'm unsure if it's needed and, if we do, if we could state it in
> a NETCONF-specific draft.
>
> BALAZS2: I see it as a VERY important advantage of the whole
> YANG/Netconf/Restconf ecosystem that the separate protocols (practically
> including the CLI and possibly a gui too) are just views of the same
> central configuration datastore. So IMO this is important and should be
> stated.
>
>
>


I strongly support this approach.
It applies to the entire server API, including notifications.
E.g., a client should be able to reuse code for processing NETCONF
notifications,
even if the protocol is RESTCONF or the new YANG-Push over UDP.

The RESTCONF mechanisms adapted from HTTP should be extended to be
protocol-independent.  Our goal should be code to the YANG models, NOT the
protocols.



>
> Restconf also includes timestamps. What was your reason to exclude them
> from your I-D ? IMHO if the server maintains timestamps they would be
> protocol/interface independent just as etags, so the task is to make them
> available on Netconf too (and maybe the CLI).
>
>
>
> I agree and have mentioned before.  LastModified either needs to be added,
> or justified why not added, to get my adoption support.
>
>
>

I agree. They both need to be supported in RESTCONF.
A timestamp can be applied to multiple servers, unlike the ETag values.
Typical usage is for the client to track its own polling timestamps,
and use If-Modified-Since to retrieve data only if needed.
The same timestamp can also be used with If-Unmodified-Since for edits.



>
> Regards Balazs
>
>
>
> Kent // contributor
>
>
>

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] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Balázs Lengyel]

From: Kent Watsen 
Sent: Thursday, 24 March, 2022 00:05
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Common etag, timestamp on all interfaces 
(draft-lindblad-netconf-transaction-id)




I assume that the etag defined in your I-D is the same as the one defined in 
Restconf. Does or should your draft include a statement like:
“The etag values maintained by the server are protocol/interface independent. 
If requested the same etag values will be visible on all interface including 
Restconf, Netconf, CLI etc.”

While it makes sense that a server would use the same values across protocols, 
I'm unsure if it's needed and, if we do, if we could state it in a 
NETCONF-specific draft.
BALAZS2: I see it as a VERY important advantage of the whole 
YANG/Netconf/Restconf ecosystem that the separate protocols (practically 
including the CLI and possibly a gui too) are just views of the same central 
configuration datastore. So IMO this is important and should be stated.


Restconf also includes timestamps. What was your reason to exclude them from 
your I-D ? IMHO if the server maintains timestamps they would be 
protocol/interface independent just as etags, so the task is to make them 
available on Netconf too (and maybe the CLI).

I agree and have mentioned before.  LastModified either needs to be added, or 
justified why not added, to get my adoption support.



Regards Balazs

Kent // contributor


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

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Andy Bierman]

On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel 
wrote:

>
>
>
>
> *From:* Andy Bierman 
> *Sent:* Wednesday, 23 March, 2022 22:32
> *To:* Balázs Lengyel 
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] Alternative approach to
> draft-ma-netmod-immutable-flag-00
>
>
>
>
>
>
>
> On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
> Hello Andy,
>
> I also propose an extension. (see my mail Review of
> draft-ma-netmod-immutable-flag-00)
>
> In Ericsson we saw no need for exceptions, but do see the need for
> applying it to descendant nodes. Typically we need to protect a full
> subtree.
>
>
>
> Why do you need the exceptions? Could you provide some use-case examples ?
>
>
>
> I think create/delete-only and modify-only access modes are used the most,
> after no-access.
>
> BALAZS: How is a modify-only data-node different from a mandatory
> data-node? It must be there but can be changed. It get’s an initial value
> somehow.
>

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.



> BALAZS: Any examples when would a create/delete only data node be used?
>

Sometimes developers do not want to write complex instrumentation that
supports
modification of resources.  Instead a user has to delete the old entry and
create a new
one with (potentially) different parameters.



>
> Applying to descendant nodes may be better, or may require more work to
>
> undo the extension used in an ancestor node. This impacts the extension
> usage within a grouping.
>
>
>
> BALAZS2: I did not include it in my mail, but we actually have one more
> rule:
>
> “Top level statements in augment or groupings do NOT inherit
>
>the static-data value from containing nodes, they default to
>
>static-data false.”
>
>
>

This seems complicated to users and developers to track how the final
schema tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too
close to this extension.
Things that seem the same, but are NOT the same cause the most support
tickets.


>
> Regards Balazs
>
>
>
> Andy
>

Andy



>
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, 23 March, 2022 21:10
> *To:* NetMod WG 
> *Subject:* [netmod] Alternative approach to
> draft-ma-netmod-immutable-flag-00
>
>
>
> Hi,
>
>
>
> IMO the problem should be viewed as a refinement to the
>
> access control policy of the device.  A standard mechanism
>
> such as a YANG extension would be better than a growing
>
> mix of proprietary solutions.
>
>
>
> We have such a YANG extension called "user-write" that is widely deployed.
>
> A simple boolean is not fine enough granularity, so a bits type is
>
> needed instead to allow control of create, update, and delete access
> operations.
>
>
>
>
>
>
> https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write
> 
>
>
>
>
>
> Andy
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Kent Watsen]

> I assume that the etag defined in your I-D is the same as the one defined in 
> Restconf. Does or should your draft include a statement like:
> “The etag values maintained by the server are protocol/interface independent. 
> If requested the same etag values will be visible on all interface including 
> Restconf, Netconf, CLI etc.”

While it makes sense that a server would use the same values across protocols, 
I'm unsure if it's needed and, if we do, if we could state it in a 
NETCONF-specific draft.


> Restconf also includes timestamps. What was your reason to exclude them from 
> your I-D ? IMHO if the server maintains timestamps they would be 
> protocol/interface independent just as etags, so the task is to make them 
> available on Netconf too (and maybe the CLI).

I agree and have mentioned before.  LastModified either needs to be added, or 
justified why not added, to get my adoption support.


> Regards Balazs

Kent // contributor


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

[netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Balázs Lengyel]

Hello Jan,
I assume that the etag defined in your I-D is the same as the one defined in 
Restconf. Does or should your draft include a statement like:
"The etag values maintained by the server are protocol/interface independent. 
If requested the same etag values will be visible on all interface including 
Restconf, Netconf, CLI etc."

Restconf also includes timestamps. What was your reason to exclude them from 
your I-D ? IMHO if the server maintains timestamps they would be 
protocol/interface independent just as etags, so the task is to make them 
available on Netconf too (and maybe the CLI).
Regards Balazs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello Kent, Andy,
I see more problems with an access control based immutable solution.
- user-dependency as Kent mentioned
- it is always possible to insert a new rule(set) at the beginning of the NACM 
list that overrides other rules. We would need to ensure that these rules stay 
the first
- there is a need to protect the access control rules protecting immutable data 
nodes; then rules to protect the rules that protect the rules that protect ...
- access control can be switched off
- access control does not work for emergency sessions
- access control rules that reference different part of the systems are MUCH 
more difficult to understand than a yang-extension statement immutable. 
Especially if you have an access control list with many (hundreds of) rules
Regards Balazs

From: netmod  On Behalf Of Kent Watsen
Sent: Wednesday, 23 March, 2022 23:07
To: Andy Bierman 
Cc: netmod@ietf.org
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi Andy,

The draft allows individual data instance nodes (e.g., in a list) to be flagged 
as immutable:



   The following terms are defined in this document:



   immutable:  A metadata annotation indicating the immutability of a

  data node.  An immutable data node is read-only to clients.  Note

  that "immutable" is used to annotate instances of YANG data nodes

  rather than schema nodes.  For instance, a "list" data node may

  exist in multiple instances in the data tree, "immutable" can

  annotate some of the instances as read-only, while others are not.


If it were not for that, then an access-control refinement seems appropriate, 
because then it would have to be user-specific, whereas this draft enables 
user-independant immutability.

As for *why* this draft enables individual data instance nodes to be flagged as 
immutable (a question asked in other recent review comments), please note that 
this work came out of the "with-system" work after a number of folks (myself 
included) noted that the concept was independent of a  datastore.  For 
instance, I defined a similar mechanism in a past life to handle objects 
published from a host-system to logical-systems (LNEs).

The most common example for such a need is with interfaces, e.g., the 
host-system publishes "eth-3.1.2" to a logical-system, where it is unable to 
delete it (whereas it is deletable in the host-system's config).  That said 
(playing devil's advocate), I wonder if, in this example, the interfaces, when 
published to a logical-system, should be published to the  datastore 
(because they're effectively a system-defined resource then, from the LNE's 
POV) and hence pickup their immutability that way.

Kent // contributor

On Mar 23, 2022, at 4:09 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


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] Alternative approach to draft-ma-netmod-immutable-flag-00

[Kent Watsen]

Hi Andy,

The draft allows individual data instance nodes (e.g., in a list) to be flagged 
as immutable:


   The following terms are defined in this document:

   immutable:  A metadata annotation indicating the immutability of a
  data node.  An immutable data node is read-only to clients.  Note
  that "immutable" is used to annotate instances of YANG data nodes
  rather than schema nodes.  For instance, a "list" data node may
  exist in multiple instances in the data tree, "immutable" can
  annotate some of the instances as read-only, while others are not.


If it were not for that, then an access-control refinement seems appropriate, 
because then it would have to be user-specific, whereas this draft enables 
user-independant immutability.

As for *why* this draft enables individual data instance nodes to be flagged as 
immutable (a question asked in other recent review comments), please note that 
this work came out of the "with-system" work after a number of folks (myself 
included) noted that the concept was independent of a  datastore.  For 
instance, I defined a similar mechanism in a past life to handle objects 
published from a host-system to logical-systems (LNEs).  

The most common example for such a need is with interfaces, e.g., the 
host-system publishes "eth-3.1.2" to a logical-system, where it is unable to 
delete it (whereas it is deletable in the host-system's config).  That said 
(playing devil's advocate), I wonder if, in this example, the interfaces, when 
published to a logical-system, should be published to the  datastore 
(because they're effectively a system-defined resource then, from the LNE's 
POV) and hence pickup their immutability that way.

Kent // contributor


> On Mar 23, 2022, at 4:09 PM, Andy Bierman  wrote:
> 
> Hi,
> 
> IMO the problem should be viewed as a refinement to the
> access control policy of the device.  A standard mechanism
> such as a YANG extension would be better than a growing
> mix of proprietary solutions.
> 
> We have such a YANG extension called "user-write" that is widely deployed.
> A simple boolean is not fine enough granularity, so a bits type is
> needed instead to allow control of create, update, and delete access 
> operations.
> 
> 
> https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write
>  
> 
> 
> 
> 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] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

From: Andy Bierman 
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
Cc: NetMod WG 
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.
BALAZS: Any examples when would a create/delete only data node be used?

Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
   the static-data value from containing nodes, they default to
   static-data false.”


Regards Balazs

Andy


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


Andy

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

Re: [netmod] Review of draft-ma-netmod-immutable-flag-00

[Reshad Rahman]

 Hi,
I went through the doc, have not reviewed it extensively but +1 to this comment 
from Balazs. I don't see the use-case for supporting this per instance either.

If we make this a schema property it can be documented in a transparent manner

with a YANG extension statement. If it is handled as instance connected metadata

the client cannot know a-priori whether a data node is or is not immutable. 
This information
is only available in runtime. System integrators, OSS developers will have a 
problem.

Regards,Reshad.
On Wednesday, March 23, 2022, 03:23:32 PM EDT, Balázs Lengyel 
 wrote:  
 
  
Hello,
 
I did a review of the immutable draft. My comments questions are below.
 
Regards Balazs
 
  
 
General)
 
I think this work is important and valuable, but it needs quite a lot 
improvements.
 
  
 
Why is immutable connected to instances. IMO it should be a schema property.
 
If we connect it to instances it is hard/impossible to specify “it is 
prohibited to create a
 
new container, list entry of leaf-list value”. That is clearly needed for the
 
capability-check use-case. Maybe allow it on both schema and instance ?
 
  
 
If we make this a schema property it can be documented in a transparent manner
 
with a YANG extension statement. If it is handled as instance connected metadata
 
the client cannot know a-priori whether a data node is or is not immutable. 
This information
 
is only available in runtime. System integrators, OSS developers will have a 
problem.
 
  
 
As immutability is connected to instance (now) this raises the question how
 
stable this property is? 
 
- We don't say anything; the server can keep it stable or make the data node
 
immutable every odd second and writable every even second
 
- The property should be relatively stable in an unspecified manner
 
- The property shall be set when the data node is created and the property
 
should not change till the data node is deleted/replaced
 
- Can the immutable property be set on just some interfaces e.g. the
 
leaf is readOnly on the CLI but writable on Netconf ?
 
If we make immutable a schema-property, the problem will not arise.
 
  
 
IMO it would be important to list the use-cases we want to solve. I provide 3 
below.
 
  
 
  
 
Ch 1) 
 
I don't like paragraph 2. Someone could say just declare the interface name
 
config=false which is a quite usual solution.
 
  
 
I would rather change the first and second paragraphs to:
 
  
 
"YANG [RFC7950] is a data modeling language used to model both state
 
and configuration data, based on the "config" statement. However there is data
 
that should not be modifiable by the client, but still needs to be declared
 
as config true. Some examples of this problem are presented below:
 
  
 
Interfaces are represented as list entries. The list schema node must be
 
defined as config=true as many of its child leaves need to be configurable by
 
the client. However the interface name and type values are set by the system,
 
based on the hardware actually present in the device, and must not be modified
 
by clients. The natural solution would be to declare the name (which is the
 
list's key) and the type as config=false. However according to the rules of
 
YANG the key leaf for a configuration list must also be config=true. Thus the
 
leaf /interfaces/interface/name is config true even if it might not be
 
writable in some systems.
 
  
 
System capabilities might be represented as system-set data nodes in the model.
 
Configurable data nodes might need constraints specified as "when", "must" or
 
"path" statements to ensure that configuration is set according to the system's
 
capabilities. E.g., 
 
- a timer can support the values 1,5,8 seconds. This is defined in the
 
leaf-list ‘supported-timer-values’. 
 
- When the configurable ‘interface-timer’ leaf is set it should be ensured that
 
one of the supported values is used. The natural solution would be to make the
 
‘interface-timer’ a leaf-ref pointing at the ‘supported-timer-values’.
 
However, this is not possible as ‘supported-timer-values’ must be readOnly thus
 
config=false while ‘interface-timer’ must be writable thus config=true.
 
According to the rules of YANG it is not allowed to put a constraint between
 
config true and false schema nodes.
 
  
 
If configuration is created by the system (e.g., copied from the 
 
datastore to the  datastore it might need to be protected. In some
 
cases there is a need to ensure that system-originated configuration shall
 
not be altered even after it is copied over to the  datastore.”
 
  
 
  
 
Ch 2)
 
"Create an immutable data node with a same value initially set by
 
  the system if it doesn't exist in the datastore, e.g., explicitly
 
  configure a system generated interface name in ;"
 
IMO this is not needed because 
 
- If the data already exists in the  datastore it cannot be
 
created according to Netconf rules. 
 
- If it does not exist in the  datastore there is n

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Andy Bierman]

On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
wrote:

> Hello Andy,
>
> I also propose an extension. (see my mail Review of
> draft-ma-netmod-immutable-flag-00)
>
> In Ericsson we saw no need for exceptions, but do see the need for
> applying it to descendant nodes. Typically we need to protect a full
> subtree.
>
>
>
> Why do you need the exceptions? Could you provide some use-case examples ?
>

I think create/delete-only and modify-only access modes are used the most,
after no-access.
Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension
usage within a grouping.


Regards Balazs
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, 23 March, 2022 21:10
> *To:* NetMod WG 
> *Subject:* [netmod] Alternative approach to
> draft-ma-netmod-immutable-flag-00
>
>
>
> Hi,
>
>
>
> IMO the problem should be viewed as a refinement to the
>
> access control policy of the device.  A standard mechanism
>
> such as a YANG extension would be better than a growing
>
> mix of proprietary solutions.
>
>
>
> We have such a YANG extension called "user-write" that is widely deployed.
>
> A simple boolean is not fine enough granularity, so a bits type is
>
> needed instead to allow control of create, update, and delete access
> operations.
>
>
>
>
>
>
> https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write
> 
>
>
>
>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?
Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG 
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


Andy

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

[netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Andy Bierman]

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access
operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


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

[netmod] Review of draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

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

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

Why is immutable connected to instances. IMO it should be a schema property.
If we connect it to instances it is hard/impossible to specify "it is 
prohibited to create a
new container, list entry of leaf-list value". That is clearly needed for the
capability-check use-case. Maybe allow it on both schema and instance ?

If we make this a schema property it can be documented in a transparent manner
with a YANG extension statement. If it is handled as instance connected metadata
the client cannot know a-priori whether a data node is or is not immutable. 
This information
is only available in runtime. System integrators, OSS developers will have a 
problem.

As immutability is connected to instance (now) this raises the question how
stable this property is?
- We don't say anything; the server can keep it stable or make the data node
immutable every odd second and writable every even second
- The property should be relatively stable in an unspecified manner
- The property shall be set when the data node is created and the property
should not change till the data node is deleted/replaced
- Can the immutable property be set on just some interfaces e.g. the
leaf is readOnly on the CLI but writable on Netconf ?
If we make immutable a schema-property, the problem will not arise.

IMO it would be important to list the use-cases we want to solve. I provide 3 
below.


Ch 1)
I don't like paragraph 2. Someone could say just declare the interface name
config=false which is a quite usual solution.

I would rather change the first and second paragraphs to:

"YANG [RFC7950] is a data modeling language used to model both state
and configuration data, based on the "config" statement. However there is data
that should not be modifiable by the client, but still needs to be declared
as config true. Some examples of this problem are presented below:

Interfaces are represented as list entries. The list schema node must be
defined as config=true as many of its child leaves need to be configurable by
the client. However the interface name and type values are set by the system,
based on the hardware actually present in the device, and must not be modified
by clients. The natural solution would be to declare the name (which is the
list's key) and the type as config=false. However according to the rules of
YANG the key leaf for a configuration list must also be config=true. Thus the
leaf /interfaces/interface/name is config true even if it might not be
writable in some systems.

System capabilities might be represented as system-set data nodes in the model.
Configurable data nodes might need constraints specified as "when", "must" or
"path" statements to ensure that configuration is set according to the system's
capabilities. E.g.,
- a timer can support the values 1,5,8 seconds. This is defined in the
leaf-list 'supported-timer-values'.
- When the configurable 'interface-timer' leaf is set it should be ensured that
one of the supported values is used. The natural solution would be to make the
'interface-timer' a leaf-ref pointing at the 'supported-timer-values'.
However, this is not possible as 'supported-timer-values' must be readOnly thus
config=false while 'interface-timer' must be writable thus config=true.
According to the rules of YANG it is not allowed to put a constraint between
config true and false schema nodes.

If configuration is created by the system (e.g., copied from the 
datastore to the  datastore it might need to be protected. In some
cases there is a need to ensure that system-originated configuration shall
not be altered even after it is copied over to the  datastore."


Ch 2)
"Create an immutable data node with a same value initially set by
  the system if it doesn't exist in the datastore, e.g., explicitly
  configure a system generated interface name in ;"
IMO this is not needed because
- If the data already exists in the  datastore it cannot be
created according to Netconf rules.
- If it does not exist in the  datastore there is nothing that could
be immutable as immutable is linked to the instances.
The above is independent of what is defined in 

Until now we never
had any constraints between 2 datastores like:
you can update datastore1 if datastore2 contains something.
I don't think we want to introduce that either.

"Comment: Should we allow the client delete an "immutable" system
   instantiated node in  ?"
Once a data node is instantiated there is no record where it came from.
https://datatracker.ietf.org/doc/html/rfc8342#section-5.3.4 states that origin
is only maintained in the  datastore. Unless we want to introduce
it into . So the even the question is wrong as we don't know which
data is system instantiated.

Servers MUST reject any attempt to the "create", "delete" and
   "update" access operations on a

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

[Balázs Lengyel]

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.

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.

Does the solution allow conditional system configuration?
(E.g.,  if the client creates an OSPF interface the system inserts a child leaf 
into it)

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 .

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.

1.4) Shoudn't copy-config also be effected? Copy-config
might also need system configured items. It should be mentioned that the same
"resolution" is also needed after a node-restart.

What does populate mean? Is it the same as "copy from system to running" ? If
yes please use that terminology. Populate is not as specific.

2) In the subchapters (and later) you use the terms provided, activated, 
applied. I am not
sure what this means. Is a not yet applied item present in the 
datastore or only when it is applied? If I do a get-data on 
will I receive not-applied data nodes?

What is the difference between an applied and an activated data node and an
applied but not activated data node?

I would rather see terminology like:
- is present in the  datastore
- is not yet present in the  datastore, but the system will create it
in the  datastore when a condition is fulfilled.

How is it defined for specific schema nodes which kind of system-data it is ?
Free English text?
Is it needed to define this formally or is it enough if the server knows this?

2.2) Isn't the best example for this, when the functionality is licensed and
the license key is inserted?

3.1)  is also read-only so why is that better to store
deletable data ? Did you mean that system-config originated data cannot be
delete even if it is copied over to running? Is that true both for explicit
NBI originated copy and copy due to resolve-system?

3.2) If something was populated/copied over to running/candidate will/should
any changed system values be copied over again thereby updating the
running/candidate datastores?
Can this result in the running becoming invalid?

4.1)  You write
"The client may reference nodes defined in , overwrite values
   of configurations defined in "
IMHO the data nodes in  and  are 2 different things even
if they reside on the same path in the data tree. You need to find
terminology to differentiate between the same(-path) data nodes in different
datastores. The current terminology is confusing, I need to guess which
datastore you mean. I think this guessing process might hide problems.
Do you mean here: "The client may reference nodes defined in  if they 
are
copied into / as a result of an explicit copy or
resolve-system parameter." For me referencing a data node in running and
referencing a data node in  (even if they share the same address in
the data tree) are 2 separate things. I don't think you want to create a
reference that point between datastores.
Do you mean here: "overwrite values of the data nodes that were created by
copying from the  datastore."

" MAY overwrite and/or extend " this means that the
data nodes in system are modified although they are readOnly.
Is this what you mean? Clarify!

"Note that only  aware clients copy
   referenced system nodes from "
How does the server know if the client is system-aware? It would be better to
state something like:
'In order for the system configuration to affect validation the client needs to
either use the resolve-system parameter or explicitly copy system configuration
into running'

Last para: The server has no way to know if the client is system aware. Once
the data nodes are copied into  there is no need to say more.

4.2
"If the "resolve-system" parameter is not given by the client, the server
   MUST NOT modify  in any way not specified by the client."
I very strongly OBJECT.
- It is a bad idea.
- This is a big NBC change to Netconf/YANG.
- Other SDOs (3GPP, O-RAN) depend on the capability to modify . They
have data nodes where it is stated that list entries are not created by the 
client.
- This would need a revision 2 of YANG.
- It is also unenforceable. It would be possible to work aroun

Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

[Jürgen Schönwälder]

On Wed, Mar 23, 2022 at 07:57:23AM +0100, Carsten Bormann wrote:
> On 22. Mar 2022, at 21:04, Jürgen Schönwälder 
>  wrote:
> > 
> > updates are done in a way to maintain backwards compatibility
> 
> (Forward compatibility?
> Backward compatibility = old data, new system.
> Forward compatibility = new data, old system.
> Just saying…)
>

The design goal was to ensure that server upgrades do not break
existing clients. We commonly call YANG data model changes ensuring
that old clients continue to work 'backwards compatible'.

This discussion seems to be about a scenario where a server has been
upgraded and there are old and new clients talking to the same server,
i.e., the problem is a version mix on the client side. Such a scenario
is tricky and requires a lot of careful design since clients must be
written with the idea in mind that they may have a limited view on the
state of the world.

/js

-- 
Jürgen Schönwälder  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