OK, I have uploaded version -11 with language as follows: "An extension MAY dictate, where it is specified, that in order to take effect, both parties must include it in their EXT_INFO; or it MAY be sufficient that only one party includes it; or other rules MAY be specified. The relative order in which extensions appear in an EXT_INFO message MUST be ignored by default; but an extension MAY specify that the order matters for that extension, in a specific way."
This seems clearer to me than it was in -10. If you still see room for improvement, let me know! On Wed, Jul 26, 2017 at 9:09 PM, denis bider <[email protected]> wrote: > Hello Matthew, > > I'm not sure if I know how to address this better than with the language > so far proposed. > > Perhaps one choice would be to simply remove this paragraph. However, the > reason it was added was because an earlier reviewer (I'm not sure of the > details at this time) raised the question about whether extension > negotiation works like it does for algorithm lists, such as in e.g. > SSH_MSG_KEXINIT. In that case, multiple algorithms are enumerated by both > sides, and only one is chosen that (1) is enumerated by both sides, and (2) > is the first of those to be enumerated by the client. The main purpose of > this paragraph has been to clarify that extension negotiation does not work > that way in EXT_INFO. > > What language would you propose? Is there some simple language that would > do? How about this? > > "An extension may dictate, where it is specified, that in order to take > effect, both parties must include it in its EXT_INFO; or it may be > sufficient that only one party does; or more complex rules may be > specified." > > > On Wed, Jul 26, 2017 at 1:28 PM, Matthew A. Miller < > [email protected]> wrote: > >> Thanks very much for the response, Denis. >> >> I think I understand the intent here, but I'm not sure this new text is >> enough to mitigate some future conflict. I'm also concerned that it >> completely ignores the one-party extensions (e.g., an extension included >> in the EXT_INFO by only the client or the server, but not both), and >> what the impact is holistically. Looking at the one-party extensions >> defined herein, I can't see how their order matters; but does that mean >> the order will never matter? >> >> In writing this reply, I wondered if it's better for the order to always >> be irrelevant; an implementation might be allowed to hint its preferred >> order in the EXT_INFO, but implementations are still free to do whatever >> makes sense to them within the bounds of the relevant extension >> definitions. If an extension ought to take precedence over another, >> make it clear in its specification that it SHOULD (or MUST) be dealt >> with before (or after) others. >> >> Does that make sense? >> >> >> - m&m >> >> Matthew A. Miller >> >> On 17/07/25 16:24, denis bider wrote: >> > 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] >> > <mailto:[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 >> > <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] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/curdle >> > <https://www.ietf.org/mailman/listinfo/curdle> >> > >> > >> >> >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
