Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd

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

On Mon, Jun 10, 2019 at 3:31 PM Scott Kitterman <[e-mail]>
wrote:

> > >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote:
> > >I recently had a chance to read through draft-ietf-dmarc-psd. If I
> > >understand it correctly (and I'm not sure that I do), the document
> > >suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT
> > >record like "_dmarc.com<http://dmarc.com/>" can be published in the com
> > >zone. I found this part of the draft confusing because it's not possible
> > >to add TXT records like that >to the com zone. It might help to
> explicitly
> > >note somewhere (perhaps in Section 2.2) that there may be policy
> > >restrictions in place that disallow the publication of DMARC policy
> > >>records in some DNS zones, including some top-level domain zones.
>

As I understand it, we're in an interesting position here: ".com" can't
have a TXT record in that zone due to ICANN policy, and this ICANN policy
won't change without a (published or imminent) RFC that suggests allowing
such records would be of benefit to the community.  So the publication of
this even at experimental might obviate the need for such text in the
document.

Given your concern, I think we're talking about adding text that says
"There may be operational constraints that prevent any given operator's
participation in this experiment."  But isn't that an implicit caveat of
all experiments?

On the other hand, perhaps the largest benefit would be from the restricted
TLD operators if they were allowed to do so.

> Right now, PSD DMARC cannot be deployed
> > ubiquitously. That reality should not be overlooked.
>

This part I agree with; by pointing out that this cannot be widely deployed
right away, we are highlighting that the results of the experiment could be
understated due to the restrictions Scott H. has identified.

I see your point, but I think it's probably out of scope.  This is an IETF
> document and such restrictions are outside the IETF's control.  Also, keep
> in
> mind that once an RFC is published, it is immutable.  If that guidance
> changes, then there would be no way to correct the document without
> spinning
> up a whole new RFC process.
>

I think it might be beneficial to point out somewhere in the document that
today's operational reality prevents this experiment from being deployed
globally.  However, if the experiment shows that PSD solves a real problem
at a large scale, it would be fodder for appropriate policy changes outside
of the IETF that would permit its ubiquitous deployment.


> Is there a public, stable reference that describes the restrictions?  If
> so,
> it might make sense to reference it.  If we can, I think that would be
> much
> better than 'hard coding' the current external policy in an RFC.
>

I concur.  Does anyone know of such a policy statement from ICANN?  I don't
recall it being present in, say, any of the DNS RFCs, but there are so many
of those now...

-MSK