On Fri, Oct 1, 2021 at 8:18 PM Sam Whited <s...@samwhited.com> wrote:
> No, I am saying that I have seen people implement custom solutions to > problems in an RFC Makes sense a goal—I think the objection is more that updating 8446 on paper here is presumptuous, since that document took orders of magnitude more work. That should not detract from the work in this new draft, but hopefully my message at least makes the disagreement more clear. thanks, Rob 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 <s...@samwhited.com> 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
