On Mon 03/Feb/2020 19:47:45 +0100 Murray S. Kucherawy wrote: > > Now, to the working group as a whole: > > The chairs note that we have a duly and properly completed WGLC in hand. > Still, Dave's concerns have validity, so they need to be considered by the > working group. Since we need to do *something*, we are now putting the > question back to the working group, and we need to see some answers. The > chairs will not accept hearsay replies or opinions, or expressions of needing > this work but not knowing how to engage; you either give your feedback on the > list or privately to the chairs or Area Directors, or you are along for > whatever ride results. Please indicate, as soon as possible, where your > support lies given the above. We're not going to let this go additional > months > (probably not even weeks) without progress in some direction.
I support publishing draft-ietf-dmarc-psd as is. As I wrote already, I appreciate Dave's narration and think it can lead to a better overall statement of DMARC. However, I don't think it suggests any practical software technique that may improve [PSD]DMARC implementations in the short term. > I will also say for the record that we don't find compelling the assertion > that > resources will not be dedicated to the experiment absent a document in the RFC > Editor queue. That constraint is fully external to the IETF, and it will > carry > no weight in the decision made here. It should indeed be possible to run an > experiment based on a document in any state at all. We're entertaining > publication not because it must happen, but because that action (currently) > has > consensus, and it's our job to act on consensus. There are a number of ICANN liaisons mentioned in IETF website[*]. I think it is their, or at least some of them's, duty to inform the relevant ICANN authority about the experiment, so that they can allow it to proceed, as soon as draft-ietf-dmarc-psd enters the RFC Editor queue. Will Area Directors please advise them? NOTE: The provision to publish _dmarc resource records, or whatever selection of registered underscored node names[†], under selected global TLDs is *not* to be considered ephemeral. [*] https://ietf.org/about/liaisons/ [†] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names > Dave also made an additional observation, that experiments expected to fail > are > not generally what the IETF produces. I would quibble some with that wording: > The working group doesn't expect the experiment to "fail", but rather expects > it to be ephemeral. Were we to refer to chapter-and-verse, there's nothing in > RFC2026 (which defines "Experimental" as a document status) that precludes > what > the working group appears to be trying to do here. As for whether the IETF > generally should produce an Experimental document describing something > ephemeral, I would claim that a working group or its chairs are below the pay > grade where authoritative claims like those are made; it's the kind of thing > about which the IESG makes proclamations. Accordingly, I've Cc'd our current > Area Director to see what he thinks might happen if we were to send this up, > and give him a chance to provide guidance in case that's the decision (but we > won't wait long for that either). I don't expect the experiment to fail. What seems to me to be ephemeral is its providing for three different services[‡] to determine which TLDs deserve an extra DNS lookup. The experiment will hopefully determine which one(s) are fit. [‡] https://psddmarc.org/ Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
