Telechat Review of draft-ietf-tcpm-rto-consider-16

Request Review of draft-ietf-tcpm-rto-consider
Requested rev. no specific revision (document currently at 17)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-07-07
Requested 2020-06-22
Authors Mark Allman
Draft last updated 2020-07-03
Completed reviews Secdir Last Call review of -14 by Liang Xia (diff)
Genart Last Call review of -14 by Stewart Bryant (diff)
Iotdir Telechat review of -16 by Wesley Eddy (diff)
Genart Telechat review of -16 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant 
State Completed
Review review-ietf-tcpm-rto-consider-16-genart-telechat-bryant-2020-07-03
Posted at
Reviewed rev. 16 (document currently at 17)
Review result Ready with Issues
Review completed: 2020-07-03


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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-tcpm-rto-consider-16
Reviewer: Stewart Bryant
Review Date: 2020-07-03
IETF LC End Date: 2020-06-01
IESG Telechat date: 2020-07-09

Summary: This is a well written document and is much improved over the previous version that I reviewed. I thank the author for their work in that regard. However I do have one concern that I think the Area Directors need to consider carefully.

Major issues:
     Whilst the document has undoubtedly gained consensus in the 
     transport area, it is not clear whether the other areas that will
     be impacted have properly considered the implications 
     of the text and proactively given their consensus to the text.

     In particular the following text in a BCP may be a burden on future
     protocols, particularly in the routing and OAM spaces, with the potential
     for disagreements in the closing stages of specification approval.

      - The requirements in this document may not be appropriate in all
        cases and, therefore, inconsistent deviations and variants may
        be necessary (hence the "SHOULD" in the last bullet).  However, 
        inconsistencies MUST be (a) explained and (b) gather consensus.

     It is possible that I am over-reacting but experience tells me that this
     holds the seeds of future disagreements between areas, delays in 
     publication, and possible re-engineering of what are in practice perfectly
     acceptable implementations.

Minor issues:


Nits/editorial comments:
    There is a trivial nits issue in the abstract that the RFC editor will need
    to resolve.