[rfc-i] Feedback solicited: Update tags draft

[ekr at rtfm.com (Eric Rescorla)]

On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <suresh.krishnan at gmail.com>
wrote:

> Hi Ekr,
>
> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr at rtfm.com> wrote:
> >
> > At present, I am not in favor of these changes.
> >
> > We already spend quite a bit of time debating which tags should apply
> when compared to the (IMO marginal) value of these tags, and this seems
> likely to make that worse.
> >
> > The "amended" tag in particular seems like a workaround for our refusal
> to simply update RFCs when they are wrong. The first rule of holes to stop
> digging.
>
> The option to bis the RFCs will still exist and the IESG can still guide
> people to do that. The goal of the Amended tag is to point implementers to
> other RFCs that are mandatory to implement. Right now Updates is being used
> both for optional extensions as well as for mandatory changes and the goal
> is to disambiguate this.
>

I'm not talking about -bising the RFC. I'm talking about re-publishing
with the same RFC #.

More generally, I don't really understand what you think "mandatory"
means.

Consider two cases:

1. We publish an RFC X with a clear mistake. For instance, it allocates
   two code points, A and B, and then in the text it says A=1 and
   B=2 but in the IANA considerations it says A=1, B=1.

2. We publish an RFC X with an algorithm we later determine to be bad.
   For instance it says to use a parameter 2 but we later determine
   that 2 is bad and 3 would be better.

In the former case, I would argue that the RFC correctly read had the
code points A=1 B=2 and thus in order to be conformant with RFC X, you
need to adopt B=2.

However, what would you say in the latter case?  Older implementations
continue to be conformant with RFC X, but just not with RFC Y, which
you publish later. So, what does "mandatory" mean in this case? The
problem here, as usual, is the failure to have some way to refer to
the concept of the protocol rather than the concept of the RFC.

-Ekr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200229/f0257e93/attachment.html>