Last Call Review of draft-ietf-netconf-restconf-notif-13

Request Review of draft-ietf-netconf-restconf-notif
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-04-12
Requested 2019-03-22
Authors Eric Voit, Reshad Rahman, Einar Nilsen-Nygaard, Alexander Clemm, Andy Bierman
Draft last updated 2019-04-02
Completed reviews Yangdoctors Last Call review of -12 by Robert Wilton (diff)
Secdir Last Call review of -13 by Aanchal Malhotra (diff)
Tsvart Last Call review of -13 by Wesley Eddy (diff)
Genart Last Call review of -13 by Robert Sparks (diff)
Opsdir Last Call review of -13 by Dan Romascanu (diff)
Assignment Reviewer Wesley Eddy 
State Completed
Review review-ietf-netconf-restconf-notif-13-tsvart-lc-eddy-2019-04-02
Reviewed rev. 13 (document currently at 15)
Review result Ready with Issues
Review completed: 2019-04-02


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

I reviewed this in conjunction with the set of related WG documents on NETCONF/RESTCONF subscriptions and event notifications.   I have comments that will be sent
on other documents in the set, some of which may influence this once, since they are closely related.

Figure 3 shows a DSCP value of 10, but it isn't clear what the number base is supposed to be, and this should be specified for this protocol, since many examples can be found in other material of DSCP values indicated in binary, decimal, or hexadecimal.

In section 4, the first bullet discusses taking a "priority" and copying it into a "weighting" field.  Since priority and weight can be different, though are closely related, this seems a bit confusing.  I think the intention here for HTTP2 effects that are trying to be achieved should be discussed more so that it is clear to implementers and users what more specific effects this should have.