Hello Denis, I had other things I needed to attend to, and could not respond until now. I think this new text is much improved, thank you. I find the guidance for an extension's specification to be more vague than I like, but I'm maybe that's effectively addressed with the IANA extension table's registration requirements. Thanks again, - m&m Matthew A. Miller On 17/07/28 00:52, denis bider wrote: > 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 <denisbider.ietf@xxxxxxxxx > <mailto:denisbider.ietf@xxxxxxxxx>> 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 > <linuxwolf+ietf@xxxxxxxxxxxxxxxx > <mailto:linuxwolf+ietf@xxxxxxxxxxxxxxxx>> 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 > > <linuxwolf+ietf@xxxxxxxxxxxxxxxx > <mailto:linuxwolf%2Bietf@xxxxxxxxxxxxxxxx> > > <mailto:linuxwolf+ietf@xxxxxxxxxxxxxxxx > <mailto:linuxwolf%2Bietf@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> > > <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> > <mailto:Curdle@xxxxxxxx <mailto:Curdle@xxxxxxxx>> > > https://www.ietf.org/mailman/listinfo/curdle > <https://www.ietf.org/mailman/listinfo/curdle> > > <https://www.ietf.org/mailman/listinfo/curdle > <https://www.ietf.org/mailman/listinfo/curdle>> > > > > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature