Comments in-line. Scott K
On Tuesday, March 10, 2020 6:16:41 PM EDT Dave Crocker wrote: > This is offered as summary comments, focusing on some basic concerns, > rather than providing a detailed review of the specification. > > My original comments were posted 12 August 2019: > > https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg I have certainly reviewed those in detail. > 0. DMARC use of Organizational Domain > > DMARC specifies use of the Organizational Domain as a fallback for not > finding a DMARC record at the full domain name under scrutiny. The need > for this is to cover slow DMARC adoption among sub-domains and to handle > queries about non-existent domains. It also short circuits the need for a tree walk up to the organizational domain. I think it's also relevant to note that it only addresses queries about non-existent domains below the organizational domain level. This draft provides for an equivalent for non-existent organizational domains where appropriate. It also provides for a mechanism to express a different policy for non-existent and existent sub-domains. > 1. These are not 'public' suffixes (1) > > The concept of a 'public' suffix refers to domain names associated with > registries subject to externally-imposed operational policies. For want > of a better term, these operations are regulated. The domain suffixes > that PSD attends to are not public registries. > > * If the company that uses .example.com also gets .example, the > latter is not a 'public' domain. It is a private domain, just like > example.com. In terms of DMARC, the fact that it is delegated by ICANN > rather than a 'regular' registry is -- or at least should be -- irrelevant. > > * If member-based association that uses association.example gets > ..association, the latter is not a public domain. It's private. > > * A government-based domain name that want to enforce DMARC onto > subordinate domain names of subordinate agencies that haven't yet > adopted it are, of course, pursuing an entirely reasonable goal. But > these, too, are not public suffixes and their need is internal to their > organization. > > In every case, these are domains at the top of an administrative > authority, for all of the subordinate domains. That's the definition of > an Organizational Domain. That may be true as you have defined terms above, but it's not accurate relative to the current RFC 7489 definition, which is the relevant definition for this document. Additionally, the term public suffix as used in this document matches current common usage. In any case, the term public suffix is not baked into the protocol by this draft. If we want a different term if/when we fold this functionality into RFC 7489bis, we can use it. It's usage here won't constrain that decision. > > 2. Externalizing internal difficulties > > Some organizations have sub-groups to which various administrative > responsibilities have been delegated. In general, there can be many > levels of such delegation. Not just two. > > For the cases the PSD specification is intended to cover, > PSD seeks to adapt to slow DMARC adoption or non-existent domains for > one of its delegated sub-groups, by looking for an even-higher-level > encompassing record under a next-level Organizational Domain. That is, > PSD is specifying using two different Organizational Domains. The usual > one and its parent. > > A difficulty within the organization is being externalized to a burden > for everyone else on the net. Given the RFC 7489 definitions that are relevant for this draft, that's not correct. PSD is addressing non-organizational domains based on the current definitions. > > 3. DMARC wants the Organizational Domain > > The existing DMARC model is a) look under the full domain, and then b) > look under the Organizational Domain, as a fallback. My strong > suggestion is to keep the model as simple as that. > > The argument for adding just this one more layer of Organizational > Domain seems modest, primarily because it is purpose-built to handle a > new, special case, rather than because it represents a considered, > general case. > I don't think it just seems that way. No one has ever claimed that this PSD is generally appropriate for all domains. It's not. I translate your comment as 'because it is not useful for everyone, we shouldn't standardize it'. I don't think that's a reasonable approach. The IETF publishes documents all the time that have less than 100% applicability. That said, the applicability constraint for PSD is related to policy publishers. It is a generally useful addition for all receivers that check DMARC policy. > > 4. DMARC should not specify how to obtain the Organizational Domain. > > DMARC needs to say 'give me the organizational domain' or perhaps 'give > me the dmarc record under the organizational domain' and it needs to > have nothing to do with the method of satisfying the request. > > It's not that the problem being addressed by PSD isn't real. It's that > it needs to be viewed more carefully. > > The combination of this being a problem /within/ an organization, along > with the various continuing challenges of the PSL, mean that all > knowledge of this needs to be kept away from the DMARC spec. > This is unrelated to PSD. Your original objection was that PSD should not be published because of this unrelated issue. That did not generate (in my judgement) significant support withing the working group. It's presence in any discussion about PSD is a red herring. > > 5. There is little engagement with the PSD technical effort > > It is easy to see why owners of some domains would want a mechanism like > PSD. As noted, they do have a real and significant problem. So, > statements of support from such folk merely confirm their need. (As an > aside I'll note that historically the IETF hasn't been all that > interested in simplistic statements of support but, rather, actual > involvement in the engineering discussion.) > > What such statements do /not/ provide is any indication that the broader > Internet community has an interest in adopting this. > > First, where are the statements of actively engaged support from an > interesting set of organizations on the other side of these queries? In > general, there has been a track record of limited adoption for anything > that changes infrastructure services, in the absence of a very > widespread perception of need, benefit, and tractable operational cost. I don't think that accurately characterizes the situation for PSD. > Second, there has been a distinct lack of interest in the working > group's considering the concerns I've raised. Not none, just not much. > And the responses have mostly been to merely reject the concerns, such > as by asserting that an extra DNS query isn't expensive, ignoring the > architectural issues. Forgive my indulging in a small lack of modesty > in believing that I'm raising concerns that are relatively basic, having > some merit. I think you are confusing lack of agreement with lack of interest. I, for one, certainly paid close attention to them, but I remain unconvinced. I have no doubt your perspective is genuinely held and you wouldn't have raised them if you didn't believe they had merit, but I don't agree. > > > 6. The 'experiment' has vague goals and criteria > > In spite of having explicit language covering this specification as an > 'experiment' the specification does not give me a clear and concrete > understanding of exactly what will be evaluated, or how, and what > constitutes satisfactory accomplishment. > I won't argue it's clear, because I wouldn't have written it the way I did if I didn't think it was. It apparently seems to be reasonably straightforward to others based on WGLC and previous replies to your note. I'll leave it at that. > > I'm posting this primarily to finish an obligation and place it into the > working group record, rather than from an expectation that it will be > acted upon. Absent any indication of serious interest in serious and > constructive discussion, I won't be pressing this further, other than > possibly posting a pointer to it during IETF Last Call, as a formality. > Fair enough. I'm replying for essentially the same reasons. I don't expect you to agree, but I don't want it said no one paid attention. I certainly did. > d/ > > > > ----------------------------- > > > (1) The draft credits me for the term "public suffix". So I should > apologize, since it is now clear to me that these suffixes are very much > NOT public. They are private or governmental. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
