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]
