Pulling back to Brian's email, because the discussion has wandered off.
I reach a different conclusion. It's not really broken as it is.
We need to reserve this sort of tagging for stuff that matters to the audience
of the document. Low volume, high impact. For the lower-value relationships,
the tools we have for finding relevant stuff have improved enough that manual
(and high effort) maintenance of tags is a waste of our collective time.[1]
So, as proposed:
"Amends" is roughly the definition I have of Updates. This tracks with some of
the examples from the thread. Basically, it amounts to "if you are
implementing the protocol from this RFC, this other RFC that updates it highly
likely to change what code you write". That might be activating a part of the
wire image that was previously inoperative, changing the recommended action in
response to previously undefined circumstances, fixing a bug, or something else
that materially affects how someone might act on the document.
"Extends" is not a useful thing to have. Our more successful protocols build
in extensibility mechanisms and uses of those extensibility points within the
rules that were created for them is not worthy of tagging this way. Many of
our protocols work this way and have a LOT of extensions.
"See also" is not useful for much the same reason. We'd end up with RFCs that
are festooned with dozens of tags ("look here!", "no look at me!", "I'm
important too!") which is a distraction. If something is relevant, then you
will find a way to cite it in the new document. That suffices. Datatracker
has this nice tool that reports what documents cite an RFC; so it's not like
you can't find and follow these links.
So, after concluding "extends" and "see also" are not worth the noise, I agree
with Brian's final point: it's not worth naming "updates" to "amends".
I acknowledge that the "amends" definition doesn't always track with how the
label has been used. I see that some people have used the "extends" notion in
the past. My suggestion would not be to formally forbid that, but to start to
discourage it a little more. There is no need for hard and fast rules though;
the exercise of good judgment is a major part of the value our processes
deliver and there's no need to over-index on rule-making.
Cheers,
Martin
[1] This also applies to the semantic keyword tagging we are asked to do for
new RFCs. Those keywords are metacrap.[2]
[2] https://people.well.com/user/doctorow/metacrap.htm
On Sat, Jul 4, 2026, at 07:36, Brian E Carpenter wrote:
> Thanks for reviving this. (Although it seems to be another case that
> shows the pointlessness of the 6-month expiry rule, but that's an IETF
> process issue.)
>
> Looking at it again, I reached three conclusions:
>
> 1. Adding the "Extends" tag is a very good idea.
>
> 2. Adding the "See Also" tag is a moderately good idea. I'm not sure
> how much use it would get.
>
> 3. I really don't see any advantage of changing "Updates" to "Amends".
> There are many shades of meaning here that we might want to convey,
> such as Correct, Improve, Clarify. I don't think Amend is more precise
> than Update.
>
> Finally, while I think that this *is* RSWG business, it certainly needs
> consent from the streams.
>
> Regards/Ngā mihi
> Brian Carpenter
>
> On 04-Jul-26 01:23, [email protected] wrote:
>> Internet-Draft draft-kuehlewind-rswg-updates-tag-03.txt is now available.
>>
>> Title: Definition of new tags for relations between RFCs
>> Authors: Mirja Kuehlewind
>> Suresh Krishnan
>> Name: draft-kuehlewind-rswg-updates-tag-03.txt
>> Pages: 9
>> Dates: 2026-07-03
>>
>> Abstract:
>>
>> An RFC can include a tag called "Updates" which can be used to link a
>> new RFC to an existing RFC. On publication of such an RFC, the
>> existing RFC will include an additional metadata tag called "Updated
>> by" which provides a link to the new RFC. However, this tag pair is
>> not well-defined and therefore it is currently used for multiple
>> different purposes, which leads to confusion about the actual meaning
>> of this tag and inconsistency in its use.
>>
>> This document recommends the discontinuation of the use of the
>> updates/updated by tag pair, and instead proposes three new tag pairs
>> that have well-defined meanings and use cases.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-kuehlewind-rswg-updates-tag/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-kuehlewind-rswg-updates-tag-03.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-kuehlewind-rswg-updates-tag-03
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> --
> rswg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
