Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[[e-mail]]

> On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
> >> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
> >>> I Believe I agree with the current version, but can someone post what we
> >>> think is the final text?
> >
> > See below, with the two changes mentioned before and Mr Copy Edit's minor
> > tightening up which I hope are not controversial.
> >
> > Ale said:
> >> I posted it here:
> >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting
> >
> > Hold it. I don't recall that we agreed to break failure reports into a separate
> > document.


> The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker
> seems to confirm WG consensus.

I'm not ethusiastic about the split, but if that's what people want then so be
it. I will say that my experience has been that doing so is usually more work
and provides less benefit than you'd expect.

That said, the adoption of something as a WG document, especially one with an
intended status of <none> and in the absence of a corresponding charter update,
doesn't really mean much. 

I also don't see where the discusssion leading to the WG consensus on the
split occurred on the mailing list. Perhaps you could point me at it?


> But see also:
> https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM


> > It makes more work and I see no agreement to change anything beyond the
> > security paragraph.  In particular, we have nothing to offer on what one
> > might or might not redact.


> I still think it'd be a good idea to mention RFC 6590...

Why? RFC 6589 documents a generic approach to partial information hiding. It
does not specify how to apply this technique to DMARC failure reports, and
doing so effectively requires a careful assessment of what needs to be hidden
and what does not, and that in turn drags in all of the specifics we need to
avoid in a base document of this sort.

Indeed, as things stand, since the intent of RFC 6589 is to preserve some
information, we can't even say it solves any particular problem with DMARC
failure reports.

				Ned

P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on earth do you
assess interoperability?