Dear Eliot, I appreciate the attempts at counter argument, but it doesn't appear to be fully fleshed out. Forget former or latter. Canada intends to treat RECOMMENDED=N the same as RECOMMENDED=Y. A very quantum state like outcome indeed.
Whether the N was triggered by the first reason, the second, or the third is irrelevant. The flag is N. The recommendation flag is the same regardless of which input produced it [1]. Canada plans to treat N the same as Y. That is the point. Best, Andrew [1] Let c = consensus, a = limited applicability and s = specific use cases. For N being not recommended: N = (!c || a || s) [2] [2] As you said, and I agree, any of the three reasons can lead to a document marked as not recommended, and in this case, it’s not recommended and Canada intends to ignore it. > On Jul 5, 2026, at 10:18 AM, Eliot Lear <[email protected]> wrote: > > Hi! > > On 05.07.2026 19:00, Andrew Lee wrote: >> >> Jonathan said the Cyber Centre will not recommend one over the other. That >> means Canada plans to treat a limited-applicability, specific-use-case >> option as equivalent to the RECOMMENDED=Y hybrid. > As is commonly pointed out, the IETF are not the protocol police, as we have > limited policing power[1]. Beyond that, you should re-read the text Rich > mentioned: > > If the "Recommended" column is set to "N", it does not necessarily > mean that it is flawed; rather, it indicates that the item either > has not been through the IETF consensus process, has limited > applicability, or is intended only for specific use cases. … > Note the or (emphasis added). Any one of those reasons generates an N, and > in this case it seems that the former applies. I am not so sure about the > latter two. > > Eliot > > [1] https://www.rfc-editor.org/rfc/rfc9948.html > > <OpenPGP_0x87B66B46D9D27A33.asc>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
