Hi Alex, I will review the latest version.
See below for questions/responses. On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" <[email protected] on behalf of [email protected]> wrote: Hello Reshad, hello YANG Doctors, thank you for your review! Please find my replies inline, <ALEX>. We have also just posted -05 (thanks, Yingzhen, for doublechecking my updates). --- Alex on behalf of coauthors On 9/7/2020 7:06 AM, Reshad Rahman (rrahman) wrote: > <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. > <snip> > 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…. <RR> I actually meant "delete" and "remove". <ALEX> Here we are simply referring to the basic YANG-patch edit operations per https://tools.ietf.org/html/rfc8072#page-11. Those are in turn derived from <edit-config> operations per https://tools.ietf.org/html/rfc6241#page-37. I am not sure we need add to explain those, as we are directly referring to YANG-patch. </ALEX> <RR> The operations are indeed well defined in RFC8072 (copied below), but they are defined from the perspective of YANG-Patch. So for YANG-Patch "delete" and "remove" are different operations, but from a diff comparison I believe they are the same (the resource must exist since it's being returned in a diff) +-----------+-----------------------------------------------------------------+ | delete | delete a data resource if it already exists; if it | | | does not exist, return an error | | | | | remove | remove a data resource if it already exists | +-----------+-----------------------------------------------------------------+ > 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)? <ALEX> We are clearly referencing RFC 8072; are you suggesting to put a reference substatement below the uses statement? It looks a little strange to me but sure, we will add it. <RR> Not needed. > 4. Section 7 mentions rate limiting requests per client. Should there be a “global” rate-limiting too, i.e not client-specific? <ALEX> I am not sure this is really needed as I think the number of management clients will in general be fairly limited to begin with, but we can certainly add it. How about the following text: OLD: One possibility for an implementation to mitigate against such a possibility is to limit the number of requests that is served to a client in any one time interval, rejecting requests made at a higher frequency than the implementation can reasonably sustain. NEW: One possibility for an implementation to mitigate against such a possibility is to limit the number of requests that is served to a client, or to any number of clients, in any one time interval, rejecting requests made at a higher frequency than the implementation can reasonably sustain. <RR> Good with me. </ALEX> > 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. <ALEX> Personally, I do think it makes sense to include a brief discussion of possible further extensions. I suggest to keep the section if it's okay with you, or perhaps leave it to the chair whether they have a preference to remove it. </ALEX> <RR>Whatever the WG/chairs decide is fine with me. Regards, Reshad. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
