On 12/9/20 12:23 AM, John C Klensin wrote:
So, IMO, if this situation is going to be straightened out, we should let this document go with Ben's suggested changes but should go back to the IETF list and push for some changes, ideally binding on the IESG, which prevents our getting into this kind of situation again. In other words, while I think this document is a mistake as written, I think the authors and WG are victims and we should not punish them for it. Instead, we should learn from this example and work to avoid its happening again. Or we should find out that the community does not care and then proceed to revise 2026 accordingly.
Of course the intent is not to punish the authors and/or the WG. Instead it's to avoid either (a) causing a significant fraction of the user community to have to compromise its security even more by having to use old hardware, operating systems, application software, and/or firmware to continue to interoperate with systems that cannot be upgraded; and (b) avoid the damage to IETF's reputation from making security recommendations that are unworkable in practice.
But as I wrote elsewhere I suspect it's too late to fix this document, and that arguing about the status of this document isn't likely to fix that situation at any rate. So I just hope that the authors and/or IESG will try to Do The Right Thing and clarify scope before this is published.
I do agree that we (the community) need to stop using BCPs to make changes to standards-track protocol specifications.
Keith
