Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-ext-info-10

[denis bider <[e-mail]>]

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 <[e-mail]>
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 <
> [e-mail]> 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
>> > <[e-mail]
>> > <mailto:[e-mail]>> 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
>> >     [e-mail] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/curdle
>> >     <https://www.ietf.org/mailman/listinfo/curdle>
>> >
>> >
>>
>>
>