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

["Matthew A. Miller" <[e-mail]>]

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 <[e-mail]
> <mailto:[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]
>     <mailto:[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]>
>         > <mailto:[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>
>         >     <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]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>         >     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>>
>         >
>         >
> 
> 
>