Re: Should we update an RFC if people refuse to implement parts of it ?

--On Sunday, June 6, 2021 10:00 -0700 Dave Crocker
<[email protected]> wrote:

> On 6/6/2021 9:56 AM, Alessandro Vesely wrote:
>> On Sat 05/Jun/2021 20:14:28 +0200 John C Klensin wrote:
>>> (2) At the risk of being even more pragmatic about your "very
>>> pragmatic" proposal, I know of no way to make an
>>> authoritative change in a standards track RFC -- whether one
>>> word or a few paragraphs -- without generating an I-D,
>>> having it discussed in the community, going through IETF
>>> Last Call, and publishing a new RFC.
>> 
>> How about an erratum?
> 
> Unfortunately, the administrative rule on RFC errata is that
> they are limited to corrections where what is written does not
> match what was intended.  That is, documentation errors,
> rather than -- such as here -- revised goals.

Agreed.  In addition to Dave's point and going beyond
"administrative rule", the problem is that there is not even a
pretense that errata represent IETF consensus.   So, even if the
WG messed up and the goals need revision, errata don't work
except in one very narrow way.   That would be to submit this as
an erratum and then try to get the powers-that-be to identify it
as "hold for document update" rather than rejecting it outright.
That would provide a very clear signpost that any future
revision of the SMTPUTF8 specifications should (SHOULD?) either
consider the issue or be prepared to explain why not.

> But, yeah.  The way to address a modest change is with a
> modest effort.

And I await a description --other than the errata signpost idea
mentioned above-- as to how to make a change in this area with a
modest effort, presumably one about which IETF consensus can be
asserted but that does not require an I-D, notification of (and
discussion including) as many of those who participated in the
EAI effort as were still interested, IETF Last Call, etc.

A different way of saying the same thing is that, if this change
is not important enough to establish IETF consensus about making
it, it is not a "modest change" but a change that is not worth
the trouble at this point.

    john