[Last-Call] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Reshad Rahman
Review result: Ready with Issues

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been identified,
they can be resolved quickly.

Issues
        1.      YANG model P8, for “leaf xpath-filter”, add reference to
        RFC6021. There should also be a normative reference to RFC6021 (as per
        RFC8407) 2.      Example P10, </interfa should be </interfaces> 3.     
        Example P10, last paragraph talks about preference and
        explicit-router-id. This seems to be leftover from when the example was
        based on OSPF model. 4.      Example P12 and P13. The RPC operation has
        “operational” as source (enabled is true)  and “intended” as target
        (enabled is false). The differences shown (in RPC output) have “value
        true” and “source-value false”. But I thought value came from target
        datastore and source-value from source datastore, so the values are
        reversed, i.e.. it should be “value false” and “source-value true”
        instead? Looking at the origin in the output I am wondering if the
        intent is to have “intended” as source and ”operational” as target. Or
        am I misunderstanding this?

Questions
        1.      YANG model: does the operation “delete” make sense for a diff
        operation? If it is kept, it’d be good to have some text explaining
        that for a diff operation, “delete” and “replace” are the same? If
        they’re not the same, please also add some text…. 2.      YANG model:
        prefix “cp” doesn’t seem to be a great choice since cp is associated
        with copying. I realize that there is some preference for 2-letter
        prefixes, but to me “cp” is not a great choice. What about “cmp”?
        WG/chairs should have a word to say about this. 3.      YANG model P9,
        for the “uses path:yang-patch”, why not have a  reference to RFC8072
        (is it because the description above mentions RFC8072)? 4.      Section
        7 mentions rate limiting requests per client. Should there be a
        “global” rate-limiting too, i.e not client-specific? 5.      Wondering
        if section 8 should be in an Appendix (or even removed)? Also, the
        method suggested doesn’t seem to guarantee that the difference
        persisted for the “dampening” time.

Nits:
        1.      P11 replace <operational<  with <operational>



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux