Hi,
Thanks for this review!
Benoit Claise <bcla...@cisco.com> wrote:
> 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"
Ok, I will make this change.
> - 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"
Yes, I'll fix this.
> 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
Ok.
> - 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"
Fixed.
Chairs, should I post a new version with these fixes?
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
