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 revision | 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 | |
I-D 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 A. Miller (diff) Secdir Last Call review of -11 by Shawn M Emery (diff) Opsdir Telechat review of -10 by Mehmet Ersue (diff) Genart Telechat review of -12 by Matthew A. Miller (diff) |
|
Assignment | Reviewer | Matthew A. Miller |
State | Completed | |
Request | Last Call review on draft-ietf-curdle-ssh-ext-info by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 10 (document currently at 15) | |
Result | Ready w/issues | |
Completed | 2017-07-24 |
review-ietf-curdle-ssh-ext-info-10-genart-lc-miller-2017-07-24-00
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.