Hi Stewart, Thank you for your comments! Please find replies inline, <ALEX> --- Alex -----Original Message----- From: netconf <netconf-bounces@xxxxxxxx> On Behalf Of Stewart Bryant via Datatracker Sent: Wednesday, April 10, 2019 1:41 PM To: gen-art@xxxxxxxx Cc: draft-ietf-netconf-yang-push.all@xxxxxxxx; ietf@xxxxxxxx; netconf@xxxxxxxx Subject: [netconf] Genart last call review of draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-netconf-yang-push-22 Reviewer: Stewart Bryant Review Date: 2019-04-10 IETF LC End Date: 2019-04-12 IESG Telechat date: Not scheduled for a telechat Summary: A well written document with just a small nuber of minor matter in the nits section that need to be considered. Major issues: None Minor issues: None Nits/editorial comments: ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) ============ <ALEX> We will update the reference. </ALEX> SB> I assume that the ADs are happy with seven front page authors. =========== Abstract Via the mechanism described in this document, subscriber applications SB> I am not sure if starting a sentence with "via" is good English but SB> I have not seen it done before. <ALEX> we think "via" is fine; if you prefer it to say "using", please let us know and we will change it. </ALEX> =========== Traditional approaches to providing visibility into managed entities from remote have been built on polling. SB> from remote what? <ALEX> from a remote system, a remote application, a remote location. I do think this is clear; if you prefer it to say "from a remote system" we will change; please let us know if you would prefer to make that change. </ALEX> =========== 3.10. On-Change Notifiable Datastore Nodes In some cases, a publisher supporting on-change notifications may not be able to push on-change updates for some object types. Reasons for this might be that the value of the datastore node changes frequently (e.g., [RFC8343]'s in-octets counter), that small object changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), or that the implementation is not capable of on-change notification for a particular object. SB> I could not see the parameter range specifiy what is regarded as SB> trivial specified in the model. It seems that it perhaps ought to be. =================== <ALEX> This will depend heavily on the object and its intended use. Basically we are giving only reasons why an implementation might choose to not support on-change notifications for a particular object. Going deeper into reasoning behind such implementation choices, what size would be "small" or "large", and over what time interval, etc, would IMHO go beyond the scope of this document. We prefer not to make a change to the document. (Please note that there is another draft on smart filters for push updates, which might in the future add the ability for users to e.g. configure this and other things.) </ALEx> The next figure depicts augmentations of module ietf-yang-push to the notifications that are specified in module ietf-subscribed- notifications. The augmentations allow to include subscription SB> s/allow to include/allow the inclusion of/ =============== <ALEX> We will make this change. </ALEX> _______________________________________________ netconf mailing list netconf@xxxxxxxx https://www.ietf.org/mailman/listinfo/netconf
