No, I am saying that I have seen people implement custom solutions to problems in an RFC because they don't realize that there is a related RFC that fixes those problems (or suggests how to do whatever tangential thing they needed to implement). Having a link in the related RFCs make things easier to discover.
In this case, if I was someone wanting to, for example, implement channel binding between TLS and some sort of authentication token so that the token would not remain valid if the TLS session changed, I would probably go to the TLS spec to see if such a thing exists. If that spec doesn't contain the "Updated by" link, I don't think it's as likely that I'd find that there was a standard way to do this. —Sam On Fri, Oct 1, 2021, at 23:11, Rob Sayre wrote: > On Fri, Oct 1, 2021 at 8:04 PM Sam Whited <[email protected]> wrote: > >> I have to respectfully disagree with this. >> >> Anecdotally, RFCs are hard to discover. > > > > What do you mean, exactly, here? > > Are you saying that this draft “update” 8446 in order for readers to > understand it and 8446 itself? _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
