Last Call Review of draft-ietf-conex-abstract-mech-12
review-ietf-conex-abstract-mech-12-genart-lc-sparks-2014-08-05-00
| Request | Review of | draft-ietf-conex-abstract-mech |
|---|---|---|
| Requested revision | No specific revision (document currently at 13) | |
| Type | IETF Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2014-08-08 | |
| Requested | 2014-07-31 | |
| Authors | Matt Mathis , Bob Briscoe | |
| I-D last updated | 2015-12-28 (Latest revision 2014-10-24) | |
| Completed reviews |
Genart IETF Last Call review of -12
by Robert Sparks
(diff)
Genart Telechat review of -13 by Robert Sparks Secdir IETF Last Call review of -12 by Donald E. Eastlake 3rd (diff) |
|
| Assignment | Reviewer | Robert Sparks |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-conex-abstract-mech by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 12 (document currently at 13) | |
| Result | Ready | |
| Completed | 2014-08-05 |
review-ietf-conex-abstract-mech-12-genart-lc-sparks-2014-08-05-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-conex-abstract-mech-12 Reviewer: Robert Sparks Review Date: 5-Aug-2014 IETF LC End Date: 8-Aug-2014 IESG Telechat date: Not on an upcoming telechat agenda Summary: Ready for publication as Informational This document handles a complex description problem in a very accessible way. Thank you for the effort that has gone into creating it. One minor point to double-check: This document goes out of its way to push decisions about measuring in packets, bytes, or other units to the concrete encoding proposals. RFC6789 was explicit about conex exposing a metric of congestion-volume measured in bytes. RFC6789 was published a couple of years ago - has that part of it become stale? If so, it would be good for this document to explicitly call that out. If not, (most of section 4.6 goes back to -04 which predates RFC6789), does this document need to retain the this flexibility in its description?