Skip to main content

Last Call Review of draft-ietf-taps-minset-06

Request Review of draft-ietf-taps-minset
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-09-04
Requested 2018-08-21
Authors Michael Welzl , Stein Gjessing
I-D last updated 2018-08-28
Completed reviews Opsdir Last Call review of -10 by Linda Dunbar (diff)
Secdir Last Call review of -06 by Yaron Sheffer (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Rtgdir Telechat review of -10 by Ben Niven-Jenkins (diff)
Genart Telechat review of -08 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-taps-minset-06-genart-lc-sparks-2018-08-28
Reviewed revision 06 (document currently at 11)
Result Ready with Nits
Completed 2018-08-28
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-taps-minset-06
Reviewer: Robert Sparks
Review Date: 2018-08-28
IETF LC End Date: 2018-09-04
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC, but with nits
to consider before publication.

I had to read quite a bit more than just RFC8303 to understand what
this document has to say. I  suggest moving at least the transport-
security document to normative, and probably also RFC8095.

This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider  whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.

If it proceeds to publication, consider the following nits:

The conclusion (section 4) would be more useful if it were moved to
the introduction (it says things more clearly than the introduction
does now).

Please check with the RFC Editor early about whether the [COBS]
reference is sufficiently stable.

And a couple of questions about the larger work for the group:

The capacity profile concept as captured in this document (page 9)
says it's a number. The interface document has the concept, with an
enumeration. Ultimately, this is going to require a registry, and you
might consider establishing it even though the interface is still
supposed to be an abstract thing. The enumeration is looking pretty

In Appendix A.1, this document had to "slightly change" the
characterization of features  from those in RFC8303, introducing this
"ADDED" construct. That feels out of balance. Is this a warning sign
that RFC8303 needs adjusting?