The draft also provides some guidance on „Indication of Linkage in the Abstract and Introduction“ in section 4.3. I‘d be happy to work on more concrete or stronger guidance but I’m not fully sure how that would look like and if that would really lead to consistent description and an easy way for the reader to assess if the draft needs to be read and implemented for their usage. But maybe we should work on the text first and then discuss if it addresses any part of the problem(s).
Also note that the need for more description/explanation is mainly there because “updates" has been used inconsistently so far. That’s what we are trying to resolve by entirely new tags. And relying on the description in the RFC only would also mean that for long lists of "updated by” RFC, the reader would need to always look at all new RFCs and read the respective section. We already have examples where that list is quite long. That’s again a consequence of the inconstant, broad use. > On 7. Jul 2026, at 20:28, Scott Bradner <[email protected]> wrote: > > fwiw - this fixation with tags seems orthogonal to what is needed - which is > that the > "changes since RFC xxx" section of the new document carefully explain the > changes > (whatever they are - replacements, additions, sidesteps, workarounds ....) > > the readers can decide for themselves what to call the change - > > I'd just stick with "updates" and require the full details > > Scott > >> On Jul 7, 2026, at 12:38 PM, Mirja Kuehlewind (IETF) >> <[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). >> >> 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. >> >>> On 7. Jul 2026, at 17:02, Eric Rescorla <[email protected]> wrote: >>> >>> >>> >>> On Tue, Jul 7, 2026 at 7:54 AM Michael Richardson <[email protected]> >>> wrote: >>> >>> Mirja Kuehlewind \(IETF\) <[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]
