Re: [dmarc-ietf] Overall last-call comments on DMARC

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely <[e-mail]> wrote:

> > I know what "contract" means abstractly, but what does this actually
> look
> > like to someone that's looking for specific guidance?  The text you have
> > here, by itself, is vague and I don't think many operators will know
> what
> > to do with it.
>
> A file in each user's home directory listing allowed pairs of ARC's d=
> domain
> and the list-id identifier of a List-Id: field?


I'm a Gmail user.  What's a "home directory"?


> Whatever.  What do Google use
> to determine if an ARC seal is trusted?
>
> We don't have much concrete experience on how to set up a contract, though.
>

This is what I'm worried about.  We're in WGLC for the base document, so
this discussion is in that context.  But is WGLC really a good time and
place to be introducing abstract ideas about how this might or might not
work?  Aren't we looking to create something fairly complete and concrete
in a Proposed Standard?

>> Meanwhile, we can mention ARC, in Section 5.8  (minimal text proposed in
> >> another thread[*]).  How much can we expand that?  For example, can we
> >> whisper something about the need to trust specific sealers for specific
> >> streams?
> >
> > If you really need ARC to make all of this work and interoperate with
> > lists, then I think we need to start talking about how we want to move
> ARC
> > out of "Experimental" first so it can become a normative reference.
>
> Back to timing here.  DMARCbis I-Ds seem to be mature enough to go out,
> even if
> there are not yet a practical solutions to the ML problem.  Further
> delaying
> them until we find one is inadvisable.
>

Then why are we tossing about all these ideas during WGLC, muddying the
waters?


> Yes, we need ARC, but we also need a method to convey agreements based on
> it.
> We couldn't spell out a solution even if ARC were standard track already.
>

> We can just hint at it.  Parts of the Doug's text sound good for that.
> Here's
> a variation on it, mixed with the 2nd paragraph of Section 5.8:
>
> [...]
>

So if I can summarize, I believe you're saying:

Here's a Proposed Standard.  In some common deployment scenarios, we know
that it has some undesirable side effects.  There isn't any concrete way to
fix that as part of the PS.  You could do some X, which is this new-ish
experimental thing, or you could do some Y, or maybe both, and Z might
help, "whatever", but only one of those is well-defined, and none of them
are part of this PS nor are they published yet, and there's a non-zero
chance that we'll run out of energy and not actually do so.

Is that what you want to send to the IESG?

-MSK