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