Last Call Review of draft-ietf-curdle-ssh-ext-info-10
review-ietf-curdle-ssh-ext-info-10-genart-lc-miller-2017-07-24-00
| Request | Review of | draft-ietf-curdle-ssh-ext-info |
|---|---|---|
| Requested rev. | no specific revision (document currently at 15) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2017-07-30 | |
| Requested | 2017-07-16 | |
| Authors | denis bider | |
| Draft last updated | 2017-07-24 | |
| Completed reviews |
Opsdir Last Call review of -10 by Mehmet Ersue
(diff)
Genart Last Call review of -10 by Matthew Miller (diff) Secdir Last Call review of -11 by Shawn Emery (diff) Opsdir Telechat review of -10 by Mehmet Ersue (diff) Genart Telechat review of -12 by Matthew Miller (diff) |
|
| Assignment | Reviewer | Matthew Miller |
| State | Completed | |
| Review | review-ietf-curdle-ssh-ext-info-10-genart-lc-miller-2017-07-24 | |
| Reviewed rev. | 10 (document currently at 15) | |
| Review result | Ready with Issues | |
| Review completed: | 2017-07-24 |
Review
review-ietf-curdle-ssh-ext-info-10-genart-lc-miller-2017-07-24
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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-curdle-ssh-ext-info-10 Reviewer: Matthew Miller Review Date: 2017-07-24 IETF LC End Date: 2017-07-30 IESG Telechat date: N/A Summary: This document is ready with an issue. I found this document very coherent and easy to follow. Major issues: Minor issues: My only issue borders on nit, but sided with nit as I can see it potentially causing confusion for an implementer in the future. Section 2.5. "Interpretation of Extension Names and Values" explicitly states in the second paragraph a condition where the relative order of extension-names in an EXT_INFO message is irrelevant. However, the rest of the section seems to imply to me that relative order is not important; so to explicitly call out a scenario seems to imply that relative order *is* relevant/important, sometimes. If relative order is expected to be important most of the time, I think it helpful to explicitly state that and give a rationale for it. Nits/editorial comments: * RFC 5226 is referenced by this document, but is obsoleted by RFC 8126.