Last Call Review of draft-ietf-netconf-restconf-notif-13
review-ietf-netconf-restconf-notif-13-tsvart-lc-eddy-2019-04-02-00
| 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 |
Review
review-ietf-netconf-restconf-notif-13-tsvart-lc-eddy-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 tsv-art@ietf.org 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.