Hi Timo,
On 16 Sep 2026, at 12:55, Timo Gerke wrote:
actually we do not have a rough consensus regarding Section 3
of RFC 7282.
First, understand that RFC 7282 is an Informational document that gives
one particular take on how we achieve and determine consensus. It is one
that I personally believe in, but it is not a BCP.
That said, we may very well have achieved a rough consensus on this
issue in the sense that section 3 talks about: "If the chair finds, in
their technical judgement, that the issue has truly been considered, and
that the vast majority of the working group has come to the conclusion
that the tradeoff is worth making, even in the face of continued
objection from the person(s) who raised the issue, the chair can declare
that the group has come to rough consensus." Murray and I have not made
that determination yet, and I believe we are giving you more-than-ample
opportunity to make your case to the WG that the document needs to
change in order to accommodate your concern, but you do have to make
that case. And as Murray and I have both said, at this point it is going
to require you to provide some proposed text. It is the document
editors' job to "incorporate changes as agreed to by the WG" and ensure
"that the contents of the document accurately reflect the decisions that
have been made by the working group" [RFC2418], but it is our job as
chairs to "allow for a fair distribution of the workload". In this case
we think sharing that workload means you (or others who support your
position) will need to provide some sample text.
The architecture of spec-06 is known to be insecure, confirmed by
Bron [1] and Richard [2].
First, do not characterize other people's posts as coming to a
conclusion. The post you cite by Richard "confirms" no such thing, and
you did not give a citation to any message by Bron.
[1]
https://mailarchive.ietf.org/arch/msg/ietf-dkim/81n06DYR1-8NakXrf89bDorm9mQ/
That is a post by Richard.
[2] Message-ID: <[email protected]> in the same
archive thread.
That is the same message.
Second, the existence of any given security vulnerability does not mean
the WG can't reasonably decide that this is an engineering tradeoff that
they are willing to make: If the vulnerability is of low enough risk (as
determined by the WG), they can decide that the tradeoff is reasonable.
A single WG participant's insistence otherwise can't stop such a
decision, and repeating the same arguments is a ground for the chairs to
close the discussion.
If you or Pete are closing this thread...
We have not yet, but we have explained what is needed to move the
discussion forward.
...I will not be available for review anymore.
It would be a great shame if failure to convince your colleagues on this
one issue should cause someone to refuse to participate in the future.
These sorts of compromises are a very basic part of participating in the
IETF. Murray and I have both been on the IESG and can tell you from
personal experience that there were several cases where each of us
thought a WG was making a poor engineering decision, but decided that
the WG understood the tradeoff being made and that we were "in the
rough" of the rough consensus. We would have a great shortage of expert
reviews if people only participated in those discussions where the
decisions all went their way.
Side-note: Pete is able to defend himself.
First, none of us should be viewing these discussions as an "attack" or
"fight" where someone is in need of a "defense".
Second, Murray and I are co-chairs of this WG. We will work together to
moderate the discussion of the WG. That means that sometimes one or the
other of us will make a comment about the discussion, or sometimes both.
Finally, please keep your discussion to the technical issues at hand,
not about the persons involved or how the discussion is being moderated
by the chairs. If you have concerns about moderation, bring them up
directly to the chairs or to the Area Director.
pr
It looks like Murray S. Kucherawy aimed to say:
On Wed, Sep 16, 2026 at 3:04 AM Timo Gerke <[email protected]>
wrote:
Sorry, Pete, but regarding <xref target="RFC2026" /> and
<xref target="RFC2418" section="2.2" /> this is the duty of the
authors and/or editors.
I have already provided a complete structural solution:
a flattened JSON array layout to eliminate duplicate-key parsing
differentials and guarantee predictable linear O(n) parsing time.
If the authors refuse to fix a known, structural vulnerability
(RFC 8259) in their text, the document lacks the necessary
security architecture to achieve consensus. I expect the authors
to integrate the flat array framework into the next revision.
To clarify: It is the duty of the authors/editors to record working
group consensus (see RFC 2418, Section 6.3). I do not believe
consensus has been established around the changes you're proposing.
I concur with the prior suggestion that providing proposed
alternative
text for the working group to consider would be very helpful here.
-MSK, DKIM co-chair
_______________________________________________
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]
