Todd, as you prepare for the next draft, I want to restate my significant concerns with the previous draft and subsequent discussions:
1) Private Registres Private registries are a significant design consideration because they cause a single DNS path to have two organizational boundaries instead of one. This was perhaps minimally important for the PSL-based determination of the organization usedby RFC 7489, but it is certainly very important for the tree walk algorithm. Private Registry or Private Registrar needs to be defined in the initial material. 2) psd=y The PSD acronym only has meaning to those who study this document, and the document defines a PSD as a domain controlled by an ICANN-sanctioned registrar. It is therefore inappropriate and misleading to take this carefully defined term and broadly apply it to both public and private registrars. The term "registrar" is a well understood English term and should be the starting point for implementing this information element. 3) psd=n The use of psd=n implies that "psd" has two states which are mutually exclusive. This is untrue and misleading. In some cases, possibly most, the private registry is a single layer, so that one domain is both the organization domain underneath the PSO registration, and the registration domain above the privately registered clients. Nothing about "psd=n" communicates "organization domain", nor does it expose the complexity of a dual-role domain. The token used to identify an organizational domain should be meaningful to the novice reader. 4) psd=u DMARC policies can play three roles: organization domain policy, single-domain policy, or registrar policy. The problem with documenting a single-domain policy is that if it is true, the tree walk needs to proceed upward as if no information had been provided. However, if it is false and believed, the tree walk could incorrectly proceed into the registrar domain, causing relaxed alignment to incorrectly produce PASS. Consequently, single-domain policies cannot be documented in a way which is trusted and useful, so they must not be tagged at all. I cannot imagine how we can gain respect for our document if it has language which says, "the term psd=u is useless and MUST be ignored, but it is defined so that you can use it anyway." Since the surviving token values are not mutually exclusive, the token definition needs to reflect that situation. A token of the form: role=(registrar,organizationaldomain) will convey the correct information much more effectively than psd=(y|n|u). I recognize that this is wordy and therefore prone to typing errors, so I believe it can and should be shortened. Whatever the choice, the syntax chosen should not mislead. 5) Boundary verification The evaluator needs certainty that the tree walk has not walked across a private registry boundary. For this to happen, the evaluator needs feedback at the stopping point to verify that the organizational domain chosen is the correct one for the domain from which he started. This requires an entry in the organizational domain policy to assert whether the selected organization contains private registrars or not. In most cases, the answer will be "No", but the evaluator cannot be certain unless that "No" is explicit. In the exception case, the selected policy needs to provide information about where the contained private registry boundary occurs, so that the evaluator can correctly distinguish between PASS/FIAL and NO POLICY FOUND. I have proposed solutions to this problem but they have been disparaged without an alternative being offered. We cannot produce a trusted result of PASS using unverifiable assumptions. Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
