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

[Scott Kitterman <[e-mail]>]

On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, Scott wrote:
> From: dmarc <[e-mail]> On Behalf Of Craig Schwartz
> Sent: Thursday, June 6, 2019 2:52 PM
> To: Hollenbeck, Scott <shollenbeck=[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd
> 
> 
> 
> 
> 
> 
> >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.
> 
> 
> 
> 
> The purpose of the document is to convey technically how PSD DMARC can be
> accomplished rather than who can or cannot undertake this due to policy
> considerations. As the operator of .BANK and .INSURANCE, fTLD initiated
> this stream of work with the IEFT because of the explicit prohibition by
> ICANN from inserting TXT records in the DNS. The goal is to get to an RFC
> that specifies the technical aspect of PSD DMARC and ultimately seek
> ICANN's approval to allow publication of such a record in the DNS. In
> contrast, gTLDs not under contract with ICANN such as .MIL and .GOV, who
> are both involved in this work, do not have a contractual relationship with
> ICANN and thus are not prohibited from this activity, and the same goes for
> ccTLDs.
 
> 
> 
> It would be helpful to the reader if the draft were either clear about
> potential limitations to deployment or more descriptive about the domains
> for which the approach can work. Right now, PSD DMARC cannot be deployed
> ubiquitously. That reality should not be overlooked.

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.

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.

Scott K