Hello Shetha,


Thank you for your review.



To the open question to the authors, adding to Andy’s repsonse:



The monitoring of resources consumed by requests, measuring the rate of 
requests etc is deemed to go beyond the scope of this Internet Draft.  The 
ability to monitor such aspects is indeed a valid system management concern, 
but one that is not specific to this draft (but apply to other drafts defining 
RPC operations as well).  If such aspects should be addressed, it would 
probably call for a more general model in its own right.  That said, Section 7 
actually discusses performance consideration.  It does state that 
implementations need to be aware of the fact that excessive invocation of the 
operation will burden system resources, and that mitigation schemes include 
(implementation-specific) rate limiting and servers rejecting requests made at 
a   higher frequency than the implementation can reasonably sustain.  We could 
add a sentence to the effect that “Monitoring of server resources and 
statistics about RPC rates will be useful to provide operators with tools that 
allow to assess the actual overhead imposed on their implementation through 
that feature.  However, the definition of any corresponding YANG data models 
are outside the scope of this document.  If defined, any such model should be 
neither specific nor should it be limited to the RPC operations defined as part 
of this document.”

Re: the nit, yes, this should be application/yang-data+json

Will update the draft shortly.

Thanks
--- Alex
From: netmod <[email protected]> On Behalf Of Andy Bierman
Sent: Friday, July 2, 2021 8:19 AM
To: Shwetha Bhandari <[email protected]>
Cc: Last Call <[email protected]>; [email protected]; NetMod WG 
<[email protected]>; [email protected]
Subject: Re: [netmod] Opsdir last call review of draft-ietf-netmod-nmda-diff-09



On Fri, Jul 2, 2021 at 5:59 AM Shwetha Bhandari via Datatracker 
<[email protected]<mailto:[email protected]>> wrote:
Reviewer: Shwetha Bhandari
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

 Summary:
This is a Standards Track document that defines an RPC operation to compare
management datastores and returns diffs between the datastores as a yang-patch.

While  most access management of the RPC, ensuring availability of the server
by rate limiting are considered I have an open question to authors: where/how
will operational metrics such as rate of requests received, errors, rate
limiting if applied, server resources consumed to process the request etc,
about this new RPC be defined and reported? This is useful information for
server operation where this RPC is enabled.


There are no standard YANG objects to monitor the server resources.
This new operation is likely to consume a lot of resources so I understand your 
concern.
The actual diff results may depend on implementation choices and impact 
resources used.
E.g. comparing 2 datastores that are constantly changing while they are being 
compared.

I am not sure what changes to the draft are needed at this time.
A resource monitoring module would be a generalized solution but it does
not belong in this draft.

Nits:
The RESTCONF example content-type is json but it is set to application/yang-d
that is not present in the registry - should it be application/yang-patch+json?

I think it is supposed to be application/yang-data+json


Andy

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to