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" <yang-doctors-bounces@xxxxxxxx on behalf of ludwig@xxxxxxxxx> 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
