Hi Pete and Murray, Hi all, I still do not want to argue with you, but a slight controversy is part of all discussions. I actually do not plan initiating a WG Dispute Resolution, but I may consider it, if more processual failures happen.
Regards, Timo It looks like Pete Resnick aimed to say: > On 23 Sep 2026, at 14:26, Timo Gerke wrote: > >> 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. > > Yes, but engineering is an exercise in weighing different approaches. > Almost inevitably, the choices we make will have certain items in their > favor and some against. Unless the collective engineering wisdom of the > group is that a flaw is fatal, consensus can decide that a flaw is worth > living with. I believe what Murray and I are both saying is that the > flaw you are pointing out does not put the product of the WG in > jeopardy, and so the (albeit rough) consensus is that the group will not > be making a change. > >> 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. > > On the contrary, whether something is a "structural vulnerability" or is > "violating the very core of architectural accountability" is an > engineering judgement call that needs to be made on the basis of the > collective wisdom of the group, and we judge the outcome of that > collective wisdom by determining rough consensus. In this case, the > rough consensus appears to be that the current spec does not have a > significant structural vulnerability nor violates the very core of > architectural accountability. One may disagree with that judgement, but > we have a mechanism to adjudicate such a disagreement as described in > RFC 2026 6.5. > >> If the working group architecture chooses to bypass documented >> algorithmic complexity exploits prior to state execution, the >> process failure is absolute. > > No, the working group can judge that the exploits are of low enough > concern that other considerations (ease of deployment, processing speed, > whatever) outweigh. If that's what's determined, the process has > absolutely succeeded. > >> 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. > > The use of 6.5.1 is not an attack at all, and I can assure you neither > Murray nor I view it that way. Chairs can and do make errors, both in > their judgement of the consensus and whether raised issues have been > properly addressed. 6.5.1 is a way to assure that an error is caught. > But you also must allow that the person raising the concern is wrong, > not the chairs or the WG as a whole. > > pr > >> 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 > > > _______________________________________________ > 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]
