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> 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@outer-planes.net > 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@outer-planes.net
> Curdle@xxxxxxxx <mailto:Curdle@xxxxxxxx>> <mailto:linuxwolf+ietf@outer-planes.net >> 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
> https://www.ietf.org/mailman/listinfo/curdle
> <https://www.ietf.org/mailman/listinfo/curdle >
>
>