I think it's appropriate as an explicit clarification of the behavior the RFC intended, and which most implementations implement (but some don't).
I don't think It's too late because errant implementations can correct this, and in time new versions of these implementations will be used.
Don't think in 2-3 years time, think in 10 years time. Internet protocols tend to hang around for a while. SMTP has been around for 33 years...
Jeffrey Hutzelman <jhutz%cmu.edu@localhost> , 11/13/2015 3:12 PM:
On November 13, 2015 9:39:23 AM EST, denis bider <ietf-ssh3%denisbider.com@localhost> wrote:
>Much agreed.
>
>If the IETF will accept an erratum with a clarification, here's a
>proposed wording:
>
>
>"Servers and clients may or may not be aware of a future extension to
>this RFC that specifies a use for the KEXINIT reserved field.
>
>Servers and clients that are NOT aware of such an extension:
>- MUST send the reserved field with the value zero (indicating
>unawareness);
>- MUST NOT act on any value of this field when received, whether zero
>or non-zero;
>- in key exchange, MUST properly hash the actual received value of this
>field.
>
>This behavior is REQUIRED to allow use of this field in future protocol
>extension."
It certainly was a mistake not to specify this to begin with. However, this represents a change to the protocol, not correction of a technical inaccuracy in the document. Nor is it a change to reflect common, consistent actual practice which differs from the specified protocol. So, I don't think it's appropriate for an erratum. Further, it's too late: this behavior is only useful if older implementations follow it; you can't add extensibility after the fact.
-- Jeff