Hi Murray, hi all, The core foundation of IETF consensus engineering under BCP 25 (RFC 2418) and RFC 7282 is strictly bound to technical quality and the mitigation of architectural flaws, not to the mathematical counting of unaligned voices.
To address Hannah's recent validation on the wire layer: I never said that REST APIs are forbidden or should be forbidden. But the specification should strictly allow O(n+d) implementations only. When a core security specification willingly permits undefined execution bounds (RFC 8259, Section 4) causing an application-layer semantic collapse, dismissing this structural vulnerability as a non-unanimous minority opinion violates the very core of architectural accountability. If the working group architecture chooses to bypass documented algorithmic complexity exploits prior to state execution, the process failure is absolute. My goal was never to attack you or Pete under $ 6.5.1 of RFC 2026 I just wanted you to know that I MAY consider it. Best, Timo It looks like Murray S. Kucherawy aimed to say: > On Tue, Sep 22, 2026 at 12:56 AM Timo Gerke <[email protected]> wrote: >> It may not be binding, but it is lived daily routine. >> >> This is not just bad practice; it is an absolute catastrophe. If >> you willingly use an Informational perspective against me to >> dismiss mathematically proven parsing vulnerabilities and enforce >> this "routine" over core technical safety, you are risking an >> appeal regardin pursuant § 6.5.1 of RFC 2026. > > You're conflating your technical argument with how consensus is > evaluated. I've taken no position on the former. > > You've made a claim (which Pete has challenged) that two people agreed > with your assessment, thereby negating the notion that consensus > exists. Pete correctly pointed out that (a) consensus calls are the > purview of the Chair, and (b) by referencing RFC 7282, that > "consensus" and "unanimity" are not synonyms. > >> Under BCP 25 (RFC 2418), checking for consensus must remain a >> transparent, deterministic process based on technical quality, >> not an arbitrary "lived routine" used to bypass architectural >> accountability. > > Consensus is also, by pure definition, "a general or widespread > agreement among the members of a group." As Pete also pointed out, > thus far there has not been a "general or widespread" swing of group > agreement toward your position. If you wish, I can point you to prior > appeals to the IESG and then the IAB where a singular position > asserting a serious quality defect in a proposed standard failed to > sway the group's consensus, and the document proceeded to publication. > There was at least one such appeal during my Area Director term. > > The record lays plain the fact that you have not been ignored, which > would certainly be grounds for redress. Rather, the group has engaged > with you in good faith and on the record. That, so far, consensus has > not changed in the direction you wish is not, I claim, a process > failure. It is, conversely, evidence of precisely the opposite. > > If you still wish to avail yourself of the appeal process under BCPs 9 > and 25, your next step is Andy Newton, who is on this list. > > > > -MSK > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] Timo Gerke Hamburg, Germany "If you think technology can solve your security problems then you don't understand the problems and you don't understand the technology." -- Bruce Schneier
OpenPGP_0x9F03DF9F597BF31E.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
