Re: [netconf] [Gen-art] Genart last call review of draft-ietf-netconf-yang-push-22

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@clemm.org> wrote:
> 
> Hi Stewart,
> 
> Thank you for your comments!  Please find replies inline, <ALEX>
> 
> --- Alex
> 
> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Stewart Bryant via
> Datatracker
> Sent: Wednesday, April 10, 2019 1:41 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-netconf-yang-push.all@ietf.org; ietf@ietf.org;
> netconf@ietf.org
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art