I'd rather add an option to flag some behavior rather than do a version bump.
Have to agree with Scott that version bumps take forever. (I had a network engineer recently tell me that DNS packets *MUST* be no larger than 512 bytes - and EDNS0 was 1999?) tim On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > On June 8, 2023 12:58:51 PM UTC, Tobias Herkula <tobias.herkula= > 401und1...@dmarc.ietf.org> wrote: > ... > > > >However, such a fundamental shift in the protocol's architecture warrants > a clear signifier. I suggest we upgrade our DMARC version string from the > current state to 'DMARC2.' This upgrade would not only denote the change of > SPF removal, but also the switch from the Public Suffix List (PSL) to the > Tree-Walk algorithm. > > > >By moving towards DMARC2, we not only update our standard to better > reflect our present requirements, but we also make a clear commitment to > the ongoing evolution and improvement of the protocol. > > > There's been a fair amount of discussion of the drop SPF part of this > proposal, but I think less about the question of version bumps. I'm going > back to the top of the thread to focus on that. > > I don't think there's much precedent for version bumps being successful in > any reasonable time frame. How long did it take to transition from SMTP to > ESMTP? Is it done yet? Absent IPv4 address exhaustion, how many more > decades would it have taken for IPv6 deployment to take off? SSL/TLS is > the best example I can think of, but even that, where there are very strong > security and privacy incentives, has been too slow and very painful. We > have nothing like that level incentive for people to support an > incompatible break between non-IETF DMARC and IETF DMARC. > > Technically, it's a new protocol. There's no technical difference between > saying records now have to start with v=DMARC2 and they have to start with > v=NOTDMARC. It's a decision to abandon all existing deployments and start > over. > > What's the incentive that any existing DMARC users (senders or receivers) > would have to invest additional resources in another email authentication > protocol? My expectation is that if the IETF decides to bump the version, > very little deployment of the IETF variant. "The IETF says this one is > better" doesn't move budgets in any meaningful way. > > My suggestion is that if we determine that a change requires a version > bump, out response should be to not make that change instead. > > For clarity, I don't think the tree walk should drive a version bump (and > we already went over that, let's resist the temptation to do it again), but > if it did, then I would rather stay with the PSL. > > Please, no version bumps. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
