Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-nmda-diff-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Alexey Melnikov for the secdir review. I'm not experienced enough with YANG to know whether or how problematic it is that the "anydata subtree-filter" node contents are described by reference to the NETCONF specification, which has a particular (XML) representation of YANG data and does not give a clear presentation of the abstract YANG structure/semantics to be used. Is it possible to use the filter-spec choice option when, for example, RESTCONF is used with JSON encoding? Section 4 o report-origin: When set, this parameter indicates that origin metadata should be included as part of RPC output. When this parameter is omitted, origin metadata in comparisons that involve <operational> is by default omitted. Why is it important to complicate the semantics of this parameter with a dependence on the datastore? It seems like it would be simpler to get this effect by having clients specify report-origin when the target is not <operational>. Note that changing the semantics would require text changes in subsequent parts of the document for consistency. (If retaining the current semantics, please clarify whether "comparisons that involve <operational>" applies when operational is source, target, or either.) Section 9 In addition to noting that the "compare" RPC is sensitive and should be restricted to authorized parties, I suggest to reiterate that the "compare" operation should not provide a mechanism to work around access control on other nodes -- that is, a result should only be returned if the requestor would be allowed to access both the "source" and "target" trees independently of the RPC. In particular, even a "no-matches" output should not be returned, as that might provide a way to determine the structure of the datastore even without accessing it. We might also incorporate by reference the security considerations for subtree filtering (RFC 6241) and xpath filtering (RFC 6991). NITS Section 1 an unusually long time to do so. This can be the case due to certain conditions not being met, certain parts of the configuration not propagating because considered inactive, resource dependencies not being resolved, or even implementation errors in corner conditions. "because considered inactive" seems like an incomplete clause; maybe "because they are considered inactive"? Section 4 o differences: This parameter contains the list of differences. Those differences are encoded per YANG-Patch data model defined in s/YANG-Patch/the YANG-Patch/ I'd also consider s/per/according to/, since this is not exactly a logic-driven deduction but rather more of a new requirement. Section 6 for the management of interfaces defined in [RFC8343]. The excerpt of the data model whose instantiation is the basis of the comparison is as follows: I feel like this phrasing is a little misleading, as not only is the following snippet only a subset of the nodes contained within "container interfaces" but the descriptions have been greatly abbreviated as well. Perhaps we could say something about "for the purposes of understanding the subsequent example, the following subset of the [RFC8343] data model is provided". Accept: application/yang-d (I believe this truncated header field was already noted by another reviewer.) _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
