Dear all,
In order not to be the bottleneck in the process and assuming that the
document will be in "publication requested" pretty soon, here is my AD
review of draft-ietf-netmod-revised-datastores-08
-
5.3.2. Missing Resources
Configuration in <intended> can refer to resources that are not
available or otherwise not physically present. In these situations,
these parts of <intended> are not applied. The data appears in
<intended> but does not appear in <operational>.
I understand what you want to say.
Let me take an example. I have a router with a Line Card configured and
working well. if I remove the LC, the configuration should still be in
the <running> and <intended> but not in <operational>.
However, based on figure below, the notion of "inactive" nodes might be
misleading. Indeed, people might read that the LC is inactive, so the LC
configuration should not be in <intended>
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of "inactive"
| // nodes, expansion of templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
I understand that "inactive nodes" has a different meaning.
Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"
- In the C.1 example,
<system
xmlns="urn:example:system"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<hostname or:origin="or:dynamic">bar</hostname>
<interface or:origin="or:intended">
<name>eth0</name>
<auto-negotiation>
<enabled or:origin="or:default">true</enabled>
<speed>1000</speed>
</auto-negotiation>
<speed>100</speed>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
<address or:origin="or:dynamic">
<ip>2001:db8::1:100</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
I guess it "or:dynamic" should be replaced by "or:learned"
Justification:
identity learned {
base origin;
description
"Denotes configuration learned from protocol interactions with
other devices, instead of via either the intended
configuration datastore or any dynamic configuration
datastore.
Examples of protocols that provide learned configuration
include link-layer negotiations, routing protocols,_and DHCP._";
_Editorial:_
- number the figures
- section 8.2
This document registers two YANG modules in the YANG Module Names
registry [RFC6020 <https://tools.ietf.org/html/rfc6020>]. Following the format in
[RFC6020 <https://tools.ietf.org/html/rfc6020>], the the
following registrations are requested:
duplicated "the the"
Regards, Benoit (OPS AD)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
