> On Nov 11, 2023, at 11:06 AM, Scott Kitterman <skl...@kitterman.com> wrote: > > The short answer is it depends. We don't vote. > > Here's the longer answer: > > https://datatracker.ietf.org/doc/html/rfc7282 > > Scott K > >> On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz <n...@marmot-tech.com> >> wrote: >> What is the definition of rough consensus. That is if you took a vote, 100 >> people voted yes and 3 voted no, the three win? Id there’s a document that >> states these rules I’d be happy to dig into it. If there’s a rule we should >> have a vote. Who is entitled to vote? Like I’m new to this and so it’d be >> understandable if I’m not entitled to a vote. That said, what do the rules >> say? >> >>>> On Oct 23, 2023, at 9:07 PM, Scott Kitterman <skl...@kitterman.com> wrote: >>> >>> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote: >>>> I have been asked by Murray to assist with a consensus evaluation on the >>>> discussion that has been going on for a while about the dmarcbis document >>>> and how to move forward. >>>> >>>> I have made an attempt to evaluate consensus on the topic, trying to look >>>> at >>>> it from a complete outsider’s point of view and trying not to let my >>>> personal opinion bias my assessment. This is a summary of that evaluation. >>>> It is based on several threads in the mailing list: [1], [2], [3] and >>>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to >>>> chronology of comments, because some people have expressed different >>>> support for different proposals, in which case I consider the latest email >>>> I can find as the person’s latest opinion. Although that was mentioned, I >>>> believe there is no consensus to move the document status to Informational. >>>> I believe there is a rough consensus that a change needs to be made in the >>>> text to include stronger requirements admonishing operators against >>>> deploying DMARC in a way that causes disruption. The mails go in many >>>> directions, but the most contentious point I could identify is if there >>>> ought to be some normative MUST NOT or SHOULD NOT text. Many people have >>>> suggested text (thank you!). I believe the ones with more tractions are >>>> Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I >>>> believe most people who’d prefer just descriptive text have stated that >>>> they can live with the SHOULD NOT text, but they have stronger objections >>>> towards the MUST NOT text. There also a number of people who strongly >>>> believe MUST NOT is the way to go, but these people have not objected >>>> strongly to Barry’s latest proposed text in the mailing list (although they >>>> have made their preference clear during the meeting [4]). As a consequence, >>>> I believe there is a stronger (very rough) consensus for going with Barry’s >>>> SHOULD NOT text. I also believe there is consensus to add some >>>> non-normative explanatory text (be it in the interoperability or security >>>> consideration sections, or both) around it. I suggest the authors and the >>>> working group start with Berry’s text and fine-tune the details around it. >>>> In particular, as another AD that might have to ballot on this document, I >>>> suggest that you pay particular attention to the text around the SHOULD >>>> NOT, as also Murray suggested in [5]. I have often blocked documents with >>>> the following text: “If SHOULD is used, then it must be accompanied by at >>>> least one of: (1) A general description of the character of the exceptions >>>> and/or in what areas exceptions are likely to arise. Examples are fine >>>> but, except in plausible and rare cases, not enumerated lists. (2) A >>>> statement about what should be done, or what the considerations are, if the >>>> "SHOULD" requirement is not met. (3) A statement about why it is not a >>>> MUST.”. I appreciate everybody’s patience and constructive discussion.
>>>> If I’m not mistaken Francesca has outlined an opening for a deal. >>>> According to the rules document, making everyone 100% happy isn’t the >>>> priority. If agreement can be reached that’s satisfactory to most, if not >>>> all parties, could get us to rough consensus. This seems like evidence >>>> that the parties aren’t taking immutable stands, leaving an opening for an >>>> agreement. Well done, Francesca, your astute summary might possibly get us >>>> over the finish line avoiding a protracted stalemate. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
