I don't think it's something we should delay on. In my, admittedly limited, experience with these things, once something is in an experimental version of an RFC, then it 'has' to be preserved in the name of interoperability with the installed base. I think now is the time to remove obvious fluff. This documents makes my head hurt enough as it is.
If anything, it should be a separate document as it's got nothing to do with ARC, per se. Any utility of AMS past the immediate previous one is entirely speculative. Let's lean towards easy, not hard. Now is the time to prune this. Having reviewed the thread that Kurt pointed me to, it seemed like this is something only one person wanted. It didn't appear to have a lot of push behind it. Scott K On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote: > Given the intended status is Experimental, is this something that's a > showstopper? > > We have the debate about "fail" versus "invalid" that I believe we consider > to be a showstopper for Proposed Standard, but we're willing to let slide > for Experimental. Is this the same? > > -MSK > > On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman <[email protected]> wrote: > > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <[email protected]> > > > > wrote: > > >Taking this back to the dmarc list instead of the IETF-wide one: > > > > > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <[email protected]> > > > > > >wrote: > > >> . . . I understand the desire to just ship it at this point so more > > >> operational experience can be gained before another update. With one > > >> exception, I agree with that approach. > > >> > > >> In Section 5.2. Validator Actions, I think it's highly unlikely that > > > > > >Step > > > > > >> 5, AMS (ARC Message Structure) validation of AMS header fields beyond > > > > > >the > > > > > >> one immediately prior in the chain is useful. > > >> > > >> Failure doesn't change the ARC result, so there are no > > > > > >interoperability > > > > > >> implications for removing it from the draft. The only reason to > > > > > >specify > > > > > >> anything is the notion of 'oldest-pass'. This looks like a dubious > > > > > >and > > > > > >> premature optimization to me. > > >> > > >> I didn't and don't plan to implement it. > > >> > > >> Later, after there is more experience with ARC, if it's established > > > > > >that > > > > > >> validation of AMS beyond the immediately prior step in the chain has > > >> utility and there is sufficient efficiency associated with > > > > > >'oldest-pass', > > > > > >> it can be added then. 'Oldest-pass' seems like an easy way to get > > > > > >around > > > > > >> having downstream validators do AMS validation up the chain (by > > > > > >always > > > > > >> adding arc.oldest-pass=1 to all messages). > > >> > > >> ARC is complicated enough without this and it seems like any easy win > > > > > >for > > > > > >> simplicity in design to take this out for now (and we'll see about > > > > > >the > > > > > >> future). Deleting it also reduces the IANA considerations. > > > > > >I'm not by any means arguing with your analysis and plans to skip this > > >component, but I did want to point you, for informational purposes to > > >the > > >WG thread which was the genesis of this concept. It was originally > > >proposed > > >as "closest-fail" but then inverted to be "oldest-pass". You can find > > >the > > >thread from January 2018 at > > >https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI > > >which references an older discussion circa August 2017. > > > > Thanks. I've reviewed it and my opinion is reinforced. It ought to be > > removed. Nothing other than the immediate prior AMS matters for > > evaluation > > of the ARC result. Everything about prior hops is purely for receiver > > edification, not needed for the protocol. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
