As a participant: On Wed, Mar 11, 2020 at 7:00 PM Scott Kitterman <skl...@kitterman.com> wrote:
> > 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. > Since we're mentioning a tree walk here, I believe we are ripe for a reopening of that debate. It's my understanding that the DNS community has softened its position on the impact of such a mechanism as a way of finding nodes of interest. I could be wrong, but there's one way to find out. Perhaps that is the case, and that a tree walk renders many of these issues moot. > 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. > > > I suspect the name used derives from the name of the resource to which DMARC attached itself early on, namely the Public Suffix List. Debating its name is probably out of scope here. And as Alessandro pointed out, the PSL was made for a different purpose and DMARC simply decide to use it to meet its own goals, which in turn supports DMARC distancing itself a bit. I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC. I don't think anyone has disagreed with that assertion. > 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. > Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem? Specifically, what's the internal problem being exploited? > 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. > I think there's some validity here at least in the claim that the purported interest has not made itself both visible and enthusiastic. Such dearth absolutely does not rise to the level of supporting something on the standards track, to be sure, but that wasn't the goal here either. > 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. > As we're now under AD Evaluation and there's still an IETF Last Call to go, this is still on the table for being fixed if it appears by further reviewers to be unclear. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
