Last Call Review of draft-ietf-netconf-yang-push-22

Request Review of draft-ietf-netconf-yang-push
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-04-12
Requested 2019-03-22
Authors Alexander Clemm, Eric Voit
Draft last updated 2019-04-10
Completed reviews Secdir Early review of -00 by Takeshi Takahashi (diff)
Yangdoctors Early review of -06 by Bert Wijnen (diff)
Yangdoctors Last Call review of -15 by Martin Björklund (diff)
Yangdoctors Last Call review of -21 by Martin Björklund (diff)
Rtgdir Last Call review of -22 by Daniele Ceccarelli (diff)
Secdir Last Call review of -22 by Takeshi Takahashi (diff)
Tsvart Last Call review of -22 by Wesley Eddy (diff)
Genart Last Call review of -22 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-ietf-netconf-yang-push-22-genart-lc-bryant-2019-04-10-2
Reviewed rev. 22 (document currently at 25)
Review result Ready with Nits
Review completed: 2019-04-10


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


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)
SB> I assume that the ADs are happy with seven front page authors.


   Via the mechanism described in this document, subscriber applications
SB> I am not sure if  starting a sentence with "via" is good English
SB> but I have not seen it done before.

   Traditional approaches to providing visibility into managed entities
   from remote have been built on polling.
SB> from remote what?


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 trivial
SB> specified in the model. It seems that it perhaps ought to be.

   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/