On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely <[email protected]> wrote:
> Todd,
>
> does your message assume that the relevant tickets are all accepted as
> valid
> indications to alter the spec? In particular, tickets #52 and #75 have
> never
> been discussed on list. I'd guess they'll have to be discussed in their
> own
> threads.
>
I don't know if each of those individual tickets has to be discussed in
their own threads or not, and I think it's more a decision for the chairs
to make than for the editors or the working group, but I could be very
wrong about that.
What I will say is this:
- The design team went off and effectively created a new version of
draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
proposed text, nothing more, nothing less.
- The design team's work was influenced by those tickets which
currently show a status of 'infoneeded'.
- Due to the nature of the text, both of the following are true:
- Most, but perhaps not all, of the 'infoneeded' tickets had impacts
on multiple sections of draft-ietf-dmarc-dmarcbis-01
- Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
that were made in producing draft-ietf-dmarc-dmarcbis-01 were
influenced by
multiple tickets
Back on April 23, when I posted here about setting expectations, I thought
at the time that adjudicating each of the infoneeded tickets might be the
way to go, but upon further reflection I'm not sure that's the case, since
it can be argued that those tickets were created against a work product
that no longer exists. It's also true that because those tickets affect the
wording in multiple sections of the document, adjudicating the -00 tickets
can theoretically result in a morass of edits made across multiple sections
of -01 and subsequent revisions, and everyone eventually losing the plot.
Chairs, your thoughts?
> Discussing the resulting text before those tickets entails, for example,
> noting
> the cumbersomeness of the locution "severity of concern" where something
> like
> "desired disposition" might seem more immediate. In fact, ticket #85 was
> only
> discussed as a side effect of ticket #39, where the consensus, IIRC, was
> to
> keep the existing policy names while wavering about how to describe them.
>
> The term RFC5322.From is consistently used, notwithstanding ticket #96.
> For an
> alternative, let me attempt to define DMARC in terms of its acronym:
>
> The Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
> protocol recognizes the prevailing importance of the domain appearing
> in the
> From: header field of email messages. That domain name will be called
> the
> Main Identifier in this document. DMARC leverages the Sender Policy
> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
> protocols
> by focusing the authentication mechanisms they provide toward the Main
> Identifier. The Domain Owners corresponding to the Main Identifier are
> endowed with the possibility to receive feedback reports about
> authentication results at receivers. Finally, receivers are provided
> with
> the Domain Owners' desiderata about messages that fail authentication,
> which
> receivers may or may not decide to conform to.
>
>
As I stated above, I believe the better path for the working group is to
adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
labeled "Introduction", you have proposed alternate text for that section,
let's discuss that section on the list, come to a consensus, and do it all
under the auspices of ticket 113.
But that's just my opinion...
--
*Todd Herr* | Sr. Technical Program Manager
*e:* [email protected]
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
