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

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> 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>.
>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>