Hi Authors,
Thanks for working on the document. Also, thanks to Michal Vasko for providing
the YANG doctors’ review of the document.
I found the document well-written and easy to understand. The examples were
especially useful. Here are some comments/clarifications on the document.
Section 1.3, paragraph 2
> This document also updates the definition of "intended" origin
> metadata annotation identity defined in Section 5.3.4 of [RFC8342].
> The "intended" identity of origin value defined in [RFC8342]
> represents the origin of configuration provided by <intended>, this
> document updates its definition as the origin source of configuration
> explicitly provided by clients, and allows a subset of configuration
> in <intended> that flows from <system> yet is not configured or
> overridden explicitly in <running> to use "system" as its origin
> value. As per Section 5.3.4 of [RFC8342], all configuration with
> origin value being reported as "intended" MUST originate from
> <running>, which includes any configuration in <system> that has been
> copied into <running>. Configuration that is in <system> and not
> also present in <running> MUST be reported as origin "system" in
> <operational>.
It was my understanding that configuration in <system> is NOT copied into
<running> but that it is merged with <running> before being written into
<intended>. Is my understanding wrong? Figure 1 also does not indicate any
copying of <system> into <running>.
Section 4, paragraph 7
> Configuration in <system> is undeletable to clients (e.g., a system-
> defined list entry can never be removed), even though a node defined
> in <system> may be overridden in <running>. If it is desired to
> enable a client to delete system configuration, it can be
> approximated using <factory-default> ([RFC8808]). If system
> initializes a value for a particular leaf which is overridden by the
> client with a different value in <running> (Section 6.3), the node in
> <running> may be removed later, in which case system-initialized
> value defined in <system> may still be in use and appear in
> <operational>.
There is a seeming contradiction here, or the behavior is not very well
explained. Earlier in the section, the document states:
"To ensure the validity of <intended>, configuration in <running> is merged
with <system> to become <intended>, in which process, configuration appearing
in <running> takes precedence over the same node in <system>.”
However, in this paragraph, it says that values in <running> may be removed
later, in which case system-defined values may be in use. What gives? Are there
special conditions under which the opposite is true?
"A.1.", paragraph 10
> The client may also define its customized applications. Suppose the
> configuration of applications is present in <running> as follows:
To keep the same tune as the <system> contents, it is better to say:
OLD:
The client may also define its customized applications. Suppose the
configuration of applications is present in <running> as follows:
NEW:
The client may also define its customized applications. Those
applications may be present in <running> as follows:
"A.1.", paragraph 15
Please add some explanation for the contents of the <operational> datastore.
Something like, "since there were no conflicts in the content between <system>
and <running>, all the applications were merged as-is".
"A.2.", paragraph 6
> <interfaces xmlns="urn:example:interface">
> <interface>
> <name>lo0</name>
> <mtu>65536</mtu>
> <ip-address>127.0.0.1</ip-address>
> <ip-address>::1</ip-address>
> </interface>
> </interfaces>
> A client modifies the value of MTU to 9216 and adds the following
> configuration into <running> using a "merge" operation:
>
> <interfaces xmlns="urn:example:interface">
> <interface>
> <name>lo0</name>
> <mtu>9216</mtu>
> </interface>
> </interfaces>
The merge of <system> and <running> and the net result of that in <intended>,
if shown here, would be helpful before showing the result in <operational>. It
will also demonstrate why the origin is <intended> in <operational>.
"A.2.", paragraph 6
> <interfaces xmlns="urn:example:interface"
> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> or:origin="or:intended">
> <interface>
> <name>lo0</name>
> <mtu>9216</mtu>
> <ip-address or:origin="or:system">127.0.0.1</ip-address>
> <ip-address or:origin="or:system">::1</ip-address>
> </interface>
> </interfaces>
Can there be an explanation added here to explain why the <interfaces> origin
is "intended", but that of the <ip-address> is "system”?
Similar to A.1, some explanatory text about how the mtu value from <running>
overrode the mtu value in <system> would be helpful.
"A.3.", paragraph 1
> In the above example, imagine the client further configures the
> description node of a "lo0" interface in <running> using a "merge"
> operation as follows:
>
> <interfaces xmlns="urn:example:interface">
> <interface>
> <name>lo0</name>
> <description>loopback</description>
> </interface>
> </interfaces>
Which "above example" are you referring to? The immediate example above is as
follows:
<interfaces xmlns="urn:example:interface">
<interface>
<name>lo0</name>
<mtu>9216</mtu>
</interface>
</interfaces>
which would make the config post merge as follows:
<interfaces xmlns="urn:example:interface">
<interface>
<name>lo0</name>
<mtu>9216</mtu>
<description>loopback</description>
</interface>
</interfaces>
"B.1.", paragraph 5
> <interfaces xmlns="urn:example:interfacemgmt"
> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> or:origin="or:system">
> <interface>
> <name>lo0</name>
> <type>loopback</type>
> <enabled or:origin="or:default">true</enabled>
> <ip-address>127.0.0.1</ip-address>
> <ip-address>::1</ip-address>
> <description>system-defined interface</description>
> </interface>
> </interfaces>
Should the origin of the <ip-addresses> not show where that config is coming
from, as in the above examples? Or is that left out on purpose? If so, please
state that for brevity or clarity of the example, not all origins are indicated.
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
"A.2.", paragraph 6
> Then the configuration of interfaces is present in <operational> as
> follows:
s/interfaces is present in <operational> as/interfaces that is present in
<operational> is as/
These URLs in the document did not return content:
* https://datatracker.ietf.org/wg/netmod/WG (I think WG is extra)
Section 7.2, paragraph 8
> ontent. The YANG module only defines a identity that uses the "ds:convention
> ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".
"A.1.", paragraph 10
> loopback interface (named "lo0") with a MTU value "65536", a default IPv4 add
> ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
