Hi Pete, sorry for the delay.
But I think, Andy and Charles would have an other opinion on the binding character of RFC 7282. By the way, you are confusing me, because you as Past-AD should know it better. Regards, Timo It looks like Pete Resnick aimed to say: > 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] 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]
