Good catch. I believe this refers to the following paragraph: "If an extension requires both the client and the server to include it in order for the extension to take effect, the relative position of the extension-name in each EXT_INFO message is irrelevant."
I have drafted the following new wording: "Unless a particular extension's specification indicates differently; then, if an extension requires both the client and the server to include it in order for the extension to take effect; implementers MUST use a default assumption that the relative position of the extension-name in each EXT_INFO message is irrelevant with respect to whether the extension takes effect." The purpose of this wording is to: - Provide a sensible default, which is that in the absence of specific knowledge, order of extension names does not matter. - Allow for deviations in special cases where there is specific knowledge. For example, extension "foo-linux" could be specified, but after some years of use, it's observed that it works well for its main purpose, but is not ideal for a server on Windows. Therefore, extension "foo-windows" is specified, which works well when the server is Windows, but not as well when it's Linux. In this case, an implementation that supports "foo-linux" only would be ignorant of anything else, and would use the default rule (order of extension names does not matter). However, an implementation that supports "foo-windows" could implement only that, or both "foo-linux" and "foo-windows". The specification for "foo-windows" could indicate that when both are supported, the first one listed by the server (or in other cases, by the client) is used. Allowing for such an extension-defined special case would allow a Linux server to advertise extensions [... "foo-linux", ..., "foo-windows", ...], preferring "foo-linux", but supporting the less appropriate "foo-windows" mechanism as well. Whereas, a Windows server could advertise [... "foo-windows", ..., "foo-linux", ...], preferring "foo-windows", but supporting the less appropriate "foo-linux" mechanism as well. Does this work? If there are no objections, I'll upload a -11 draft version with this new wording. On Mon, Jul 24, 2017 at 3:02 PM, Matthew Miller < [email protected]> wrote: > Reviewer: Matthew Miller > Review result: Ready with Issues > > 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. > > > _______________________________________________ > Curdle mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/curdle >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
