<Here's the same message with hopefully more readable formatting>
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>
On 2020-09-06, 4:42 PM, "yang-doctors on behalf of Reshad Rahman via Datatracker" <yang-doctors-bounces@xxxxxxxx on behalf of noreply@xxxxxxxx> wrote:
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>
_______________________________________________
yang-doctors mailing list
yang-doctors@xxxxxxxx
https://www.ietf.org/mailman/listinfo/yang-doctors
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
