Qiufang, WG,
Thank you for the effort you put into working out all the wrinkles of system
config. I read the updated version, and I think it is a significant
improvement. As usual, I have some comments, questions and suggestions. š In
order of appearance.
#1 Somewhat unclear conceptual model
Section 5.1 has a nice drawing of how the datastores relate to each other, and
an introductory text that explains the interactions. The following sections
explain how data can be copied from system to running, or can be filled in
automatically using the resolve-system parameter. But the first sentence of
section 5.1 is
Clients MAY reference nodes defined in <system>, override system-provided
values, and configure descendant nodes of system-defined configuration in
<running>.
In my mind, this is only true when the client uses the resolve-system
parameter. Otherwise, a client cannot reference <system> directly, but needs to
copy from <system> to <running>. So maybe the introductory sentences could be
reworded?
#2 No way to squelch system config from intended
The software on a device decides what config from <system> that show up in
<intended> (i.e. is considered āreferencedā). If the client would like
something not to flow through to <intended>, there is no mechanism for that.
Letās say some device always creates a loopback0 interface in <system>. The
client can change the loopback0 mtu by configuring it in running, but there is
no way to entirely remove loopback0. Maybe a stupid example, but letās say the
client wants the loopback0 to be called lo0 instead. The same situation would
arise for anything else in <system>, e.g. some system TPM security credential,
system traffic classification rule or whatever else people may throw into
<system>.
Is this a problem? Is this something that should be mentioned so that people
leveraging <system> are aware of this limitation?
#3 Still unclear what needs to be copied
In section 5.2 it is explained how a client can copy data from system to
running. The introduction in section 1 has some bullets about conditions that
require copying to happen. Section 6 was added with some language about leafs
with default values that need to be copied. The same need probably also applies
to presence containers (which are not mentioned anywhere in -06).
All in all, I think the design work around the rules for what needs to be
copied is hard to grasp in the current version, and is probably incomplete.
Similarly, section 5.3, which deals with what is being copied by resolve-system
parameter should probably also refer to the same rules, once established.
#4 Resolve-system without <system>
At the end of section 5.3, there is a sentence about what a system should do if
it supports resolve-system but not <system>.
If a server implements <system>, referenced system configuration is copied from
<system> into the target datastore when the "resolve-system" parameter is used;
otherwise it is an implementation decision where to copy referenced system
configuration.
This sentence was a bit confusing to me. After reading it many times, I think
an alternative text with similar meaning would be
If a server implements <system>, referenced system configuration is copied from
<system> into the target datastore when the "resolve-system" parameter is used.
If a system does not implement <system>, itās up to the implementation to
determine how the resolve-system mechanism fills in the missing configuration
items in the target datastore, e.g. <running>.
#5 Example missing ns qualifier
Section 5.5.1 has a nice example of how resolve-system works. But the example
rpc that is using it is missing the namespace qualifier, I think. Isnāt this
what it should look like?
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ncrs="urn:ietf:params:xml:ns:yang:ietf-netconf-resolve-system">
<edit-config>
<target>
<running/>
</target>
<config>
<acl xmlns="urn:example:acl">
<acl-rule>
<name>allow-access-to-ftp-tftp</name>
<matches>
<ipv4>
<src-address>198.51.100.0/24</src-address>
<dst-address>192.0.2.0/24</dst-address>
</ipv4>
<application>ftp</application>
<application>tftp</application>
<application>my-app-1</application>
</matches>
<packet-action>forward</packet-action>
</acl-rule>
</acl>
</config>
<ncrs:resolve-system/>
</edit-config>
</rpc>
#6 Old value in example
The example in 5.5.3 and 5.5.4 used to change an mtu from 65536 to 65535. Since
itās somewhat hard to spot the difference between those values, you replaced
65535 with 9216. This is great. But I think the old 65535 value is still
lurking there twice and should be replaced by 9216.
Section 5.5.4 starts with the following sentence.
In the above example, image the client further configures the description node
of a "lo0" interface in <running> as follows:
Perhaps āimageā should be āimagineā? And maybe it should be mentioned that the
client is doing a merge, not a replace? How about this?
In the above example, imagine the client further configuring the description
node of the "lo0" interface in <running> using a merge operation as follows:
#7 Implied semantics
Section 7.1 describes how the factory-default datastore is meant to be used. It
is implied that the system datastore is not meant to be used in this situation,
but it is never mentioned. Perhaps it would be worth mentioning that system is
not to be used in this way?
#8 Confusing ietf-system-datastore example
The entire section 8 is devoted to describing the tiny ietf-system-datastore
module. There is an example there, but I have to admit I donāt understand what
it is trying to show. And there must be something wrong with the last config
snippet that shows the contents of <system> after the messages? Or maybe there
is more going on here, that I never understood?
#9 Expand appendix A
Appendix A with its example showing many steps is very nice. But there it
doesnāt show any of the more complex situations, e.g. when there are defaults,
mandatory leafs, when statements or presence containers involved. Maybe the
example could be extended?
Best Regards,
/jan
From: maqiufang (A) <[email protected]>
Date: Friday, 31 May 2024 at 10:54
To: [email protected] <[email protected]>
Subject: [netmod] Re: I-D Action: draft-ietf-netmod-system-config-06.txt
Hi, all
-06 tries to address comments received during WGLC, thanks a lot to Jan, Rob
and Jason for your valuable inputs.
Major updates are following:
1. remove the definition of inactive-until-referenced system config, -06 only
defines two kinds of system config now: immediately-present vs.
conditionally-present;
2. add a new section (see sec.6) to clarify the interplay between system config
and defaults;
3. add a new section (see sec.7) to clarify relation to other datastores, which
includes <factory-default> and <candidate>/<private-candidate>;
4. leave the merge behavior of <system> and <running> unspecified, as we think
this is not specific to this document;
5. update figure 1 (architectural model of datastores) to make the arrows of
<system> and <running> merge at a common point flowing into <intended>;
6. augment <validate> and <commit> PRC operation to also support
"resolve-system" parameter;
7. remove the implementation specifics related to "resolve-system" parameter;
8. other editorial fix as suggested by Jan and Rob;
There is one issue highlighted during WGLC, which will be posted in a separate
thread for further discussion. The authors would like to request the WG to
review the update and provide your feedback, any comments and suggestions would
be much appreciated. Thanks!
Best Regards,
Qiufang //co-author
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, May 31, 2024 3:06 PM
To: [email protected]
Cc: [email protected]
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-06.txt
Internet-Draft draft-ietf-netmod-system-config-06.txt is now available. It is a
work item of the Network Modeling (NETMOD) WG of the IETF.
Title: System-defined Configuration
Authors: Qiufang Ma
Qin Wu
Chong Feng
Name: draft-ietf-netmod-system-config-06.txt
Pages: 39
Dates: 2024-05-31
Abstract:
This document defines how a management client and server handle YANG-
modeled configuration data that is instantiated by the server itself.
The system-defined configuration can be referenced (e.g., leafref) by
configuration explicitly created by a client.
The Network Management Datastore Architecture (NMDA) defined in RFC
8342 is updated with a read-only conventional configuration datastore
called "system" to expose system-defined configuration.
This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-06
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-06
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
