Stewart, thanks for your review. Alex, thanks for your responses, they all make sense to me. I have entered a No Objection ballot. Alissa > On Apr 24, 2019, at 3:07 PM, Alexander Clemm <ludwig@xxxxxxxxx> wrote: > > 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 > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
