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 > <linuxwolf+ietf@xxxxxxxxxxxxxxxx > <mailto:linuxwolf+ietf@xxxxxxxxxxxxxxxx>> 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 > Curdle@xxxxxxxx <mailto:Curdle@xxxxxxxx> > https://www.ietf.org/mailman/listinfo/curdle > <https://www.ietf.org/mailman/listinfo/curdle> > >
Attachment:
signature.asc
Description: OpenPGP digital signature