Re: [dmarc-ietf] Dmarcbis way forward

[Matt V <[e-mail]>]

I also agree that "SHOULD NOT" would be my vote as the preferred language
going forward.

~
Matt

On Tue, Oct 24, 2023 at 12:41 PM Dotzero <[e-mail]> wrote:

> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
> I fall into the "SHOULD NOT" consensus group with additional non-normative
> language.
>
> The short version of the non-normative language should be in the document
> itself but I believe the issues resulting from deviating from the normative
> "SHOULD NOT" deserve a fuller discussion in a separate document.
>
> Much of the discussion has been focused on the impact to mailing lists but
> the impacts can involve a wider range of issues depending on the nature of
> the domain/organization and users involved. A discussion of those wider
> impacts in the context of a "SHOULD NOT" would be useful in educating
> domain owners, administrators and (even) users. There are differences in
> control and impacts between a corporate/organizational domain, government
> domains, domains which offer free or paid accounts to the public and
> personal domains for example. Advice to one of these groupings may not
> reasonably address the concerns and impacts for domains or constituencies
> in other groupings.
>
> Michael Hammer
>
>
> On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini <francesca.palombini=
> [e-mail]> 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.
>>
>> Francesca, ART AD
>>
>> [1]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>>
>> [2]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>>
>> [3]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>>
>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>>
>> [5]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>