Hi, Balazs,
Thanks for the comments, much appreciated! I am trying to prepare a new version
resolving your comments, please also see my reply below.
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: Friday, December 2, 2022 11:01 PM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] Balazs comments on draft-ietf-netmod-system-config-00
Hello,
Some comment on draft-ietf-netmod-system-config-00.
General:
I support this work, I see it as important.
Thanks, Balazs. I see it both important and interesting. Since there is a broad
implementation among multiple vendors, the authors would always welcome
contributions from the WG.
I think this draft should be dependent on the immutable draft. I see limited
value of system-configuration if there is no way to protect It from client
modification.
While I agree that a lot of system configuration need to be protected from
client modification, this work tries to define a standard mechanism to :1)
allow the client to see what system configuration is available (includes
inactive system configuration which is not present in ) ;2) enable
the client to reference system configuration without having to copy it into
explicitly; 3) support a better configuration of descendant nodes of
system configuration.
Ch 1)
Why is explicit copying bad? Why do we need resolve-system parameter? the You
should motivate that.
I think the reason is that we always want the life easier and more convenient
for clients. The device exists a lot of system configuration, the client would
like to leafref system configuration (or put system configuration in when/must
statement) directly in , without having to declaring the referenced
item in manually. Sure, we will try to state it clearly in the
Introduction section.
Ch 1.4)
edit-config and edit-data cannot be used towards the startup datastore.
Copy-config can.
Agree that edit-config and edit-data cannot be used towards . This
sentence that might cause confusion can be traced from RFC7950 Sec.8.3.3 "If
the datastore is 'running' or 'startup', these constraints MUST be enforced at
the end of the or operation." Given the next
comment that you made, see my proposed changes below.
" If the target
datastore of the / or is
"candidate", the server's copy referenced nodes from to the
target datastore is delayed until a or operation
takes place."
This means that the device has to remember that resolve-system was used. Is
this fact visible for other clients? What if someone overrides items that were
planned for resolve-system?
Other clients (not the one that used the resolve-system) will be confused.
What happens if I have a must statement including a "count () <= max" on list
items. Another client might create max number of list entries. This could
prevent the device from adding new list-entries based on resolve-system.
IMHO delaying the copy is a bad idea.
Thanks for pointing this out. I think your arguments are valid to me. The
server having to remember that there is a resolve-system parameter used before
just complicates the implementation. Since this parameter is carried with the
RPC operation, it makes sense the copy operation should always be finished at
the end of RPC operation itself. Proposed update:
OLD:" According to the NETCONF constraint enforcement model defined in the
section 8.3 of [RFC7950], if the target datastore of the / or is "running" or "startup", the
server's copy referenced nodes from to the target datastore
MUST be enforced at the end of the / or
operations during the validation. If the target
datastore of the / or is
"candidate", the server's copy referenced nodes from to the
target datastore is delayed until a or operation
takes place."
NEW: "The server's copy referenced nodes from to the target datastore
MUST be enforced at the end of the / or
operations. This is regardless of which target datastore it is."
1.5.2) IMHO we should have the same capability in Netconf too.
I am thinking that a client can discover if the server supports the
resolve-system parameter by reading the YANG library information in
and checking if the server supports the
"ietf-netconf-resolve-system" YANG module. Given that, there is no need to
define a resolve-system capability identifier for NETCONF. Thoughts?
2) Define what does it mean if a part of system configuration is not active/
not applied? In which datastore is it visible? If I explicitly copy a
conditionally-active item into (while its condition is still not met)
does it become active?
If system configuration is inactive, it means this configuration is not "in
use" and does not actually impact the current running configuration of the
device. According to the definition of the Operational datastore in NMDA draft,
such
