Re: [dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal

[Tim Wicinski <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula <tobias.herkula=
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>