Tim Wicinski <tjw.ietf@xxxxxxxxx> writes: > Apologies for the delay on the PSD updates. I sat down with Scott and went > through your review and made lots of edits > related to your comments. I actually attached the reply to your email as > it's been sitting in my editor buffer for a few months too long. > > One normative change that I want your assistance on is the descriptions of > the Experiments. I updated them and pulled them apart, to make them more > understandable to folks looking at this for the first time. I'm not still > 100% on them. > > I want to go back through your opening Nits/editorial comments to make sure > I'm not missing anything. > > Here's the link to the diff. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 My apologies for not tending to this promptly. In regard to the description of the experiments, the result criteria are rather subjective, but I don't see that as a problem. It does seem to me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is too narrow, as only the 3rd experiment seems to be about privacy issues. A title as generic as "PSD DMARC Experiments" would be fine. Looking at the diffs, I notice that I find the new sections 2.3 through 2.6 straightforward. Oddly, they aren't much different than what is in the -08, which I found confusing. It's not clear why ... Perhaps it is because the -09 version starts with attention on "organizational domain", which one has an intuitive understanding of, and defines the other terms from there, whereas the -08 seems to focus on "PSD". Although I note that even the -09 does not define "PSD", only "longest PSD", even though "PSD" is used in section 2.5. I suspect that PSD is equal to "PSO Controlled Domain Name", though, or rather to some related set of them. That needs to be cleaned up in some way. In section 3.5 and later there is the phrase "[this document] longest PSD". I'm not sure, but I think this is supposed to be "longest PSD ([this document] section NN.NN)". I believe that my strongest critique was that section 1 is difficult to understand if one does not already understand DMARC, and it does not seem that the section has been revised. Re-reading it, I notice that it says "DMARC leverages public suffix lists to determine which domains are organizational domains." Ignoring that I dislike this use of "leverage", a critical point is that it takes the existence of public suffix lists a priori -- indeed, this use of "leverage" generally means that the leveraged thing already exists and one is now extracting additional benefit from that. Whereas I've never heard of public suffix lists and would naively expect that they are difficult to create and maintain. It might be better to say "DMARC uses public suffix lists to determine which domains are organizational domains. Public suffix lists are obtained/maintained/distributed by ..." Looking at the second paragraph of section 1, I notice that despite all the special terms for classifying domain names in section 2, the example in this section does not describe which of the domain names that it mentions fall into which of these classes. E.g. "tax.gov.example" is said to be registered, but it looks like it is also the organizational domain, and "gov.example" is its longest PSD. It would also help to mention that "tax.gov.example" is "registered at" "gov.example" to introduce the details of the usage "registered at". Suppose there exists a domain "tax.gov.example" (registered at "gov.example") ... Dale -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
