Just quickly on your last point: „see also“ provides the opposite direction 
from references. A function that provides a pointer from an existing RFC to a 
newer one that didn’t exist when the old RFC was written.

> Am 07.07.2026 um 23:13 schrieb Brian E Carpenter 
> <[email protected]>:
> 
> 
> 
> Regards/Ngā mihi
>   Brian Carpenter
> 
>> On 08-Jul-26 08:09, Mirja Kuehlewind (IETF) wrote:
>> See inline.
>>>> On 7. Jul 2026, at 20:19, Eric Rescorla <[email protected]> wrote:
>>> 
>>> 
>>> 
>>>> On Tue, Jul 7, 2026 at 9:38 AM Mirja Kuehlewind (IETF) 
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>>    The discussion on which tag applies would be at least based on something 
>>> written and consensus based and not just on differing strong opinions about 
>>> how to do it right. That should make the discussion easier and also create 
>>> less of them. That’s the goal! Maybe it wouldn’t avoid it entirely but I 
>>> don’t think that a good reason to not do it as I don’t think there is a 
>>> perfect solution (and probably there don’t need to be one; sometimes you 
>>> simply need to have a discussion and make a decision).
>>> 
>>> 
>>> I'm sorry, I don't agree. My view is that adding more tags with detailed 
>>> guidelines is just as likely to create more debate, not less. If we are to 
>>> do something here, I would instead replace both Obsoletes and Updates with 
>>> some variant of "look over here" or "you might be interested in", thus 
>>> avoiding any debate.
>> That’s why we also added the “see also” tag. Why do you think that “amends” 
>> and “extends” are not clear?
> 
> As SM pointed out, there is some existing language in 2223bis [1] 
> (ironically, an expired "Obsoletes" draft) that actually strikes me as very 
> good:
> 
> Updates:   The new document cannot be
>           used alone, it can only be used in conjunction with the
>           earlier document.
> 
> Obsoletes: The new document can be used alone as a
>           replacement for the obsoleted document.
> 
> Also, the meaning of "Extends" is quite broad and can mean many different 
> things [RFC6709]. So can "Amends" (is it a correction, a clarification, or an 
> actual change that changes what should be on the wire?).
> 
> I'm slowly coming round to the view that "Updates" with a mandatory 
> explanation may be the best solution (whereas "Obsoletes" is complete on its 
> own).
> 
> On balance, I'm not a fan of "See Also" - that's what Informational 
> references are for.
> 
> [1] 
> https://datatracker.ietf.org/doc/html/draft-rfc-editor-rfc2223bis-08#page-13
> 
>   Brian
> 
>>> 
>>>    Having some potentially confusing tags on old RFCs (that could be 
>>> revised if needed) doesn’t seem to be worse than what we have right now: 
>>> one tag that is not defined at all and a mismatch of use and interpretation 
>>> as everybody makes up their own requirements.
>>> 
>>> 
>>> I think we just have different opinions.
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>>>    On 7. Jul 2026, at 17:02, Eric Rescorla <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> 
>>>> 
>>>>    On Tue, Jul 7, 2026 at 7:54 AM Michael Richardson 
>>>> <[email protected] <mailto:mcr%[email protected]>> wrote:
>>>> 
>>>> 
>>>>        Mirja Kuehlewind \(IETF\) <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>>        Agreed!
>>>>        I think that it would be brilliant if an AD review told the WG:
>>>>          "Yeah, that document is not an Updates-123, it's an Updates-545, 
>>>> right?"
>>>> 
>>>>        WG: Oh yeah, we didn't change our meta-data as our I-D evolved into 
>>>> being
>>>>            better at interoperating with old thing FOO.
>>>> 
>>>>    This seems like the optimistic view. The pessimistic view is that it 
>>>> will usher
>>>>    in a whole new round of arguments about whether it should be 
>>>> Updates-123 or
>>>>    Updates-545.
>>>> 
>>>> 
>>>>            > Also my question is what’s the harm I trying it. If it 
>>>> doesn’t help, we
>>>>            > stop it again. However, I think there is a chance to at least 
>>>> improve
>>>>            > the situation even though we might not fix all issues 
>>>> entirely.
>>>> 
>>>>        +1
>>>> 
>>>> 
>>>>    In addition to the concern above, namely creating new arguments about
>>>>    which tag applies, if it turns out not to work, we end up with a bunch 
>>>> of
>>>>    confusing and no-longer-used tags in perpetuity.
>>>> 
>>>>    -Ekr
>>>> 
>>>> 
>>> 
>>> --
>>> 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]

Reply via email to