> On 26 Mar 2023, at 11:13, Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas <m...@mtcc.com > <mailto:m...@mtcc.com>> wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the result that the working group comes >> > out with, but not in the problem statement. >> >> There isn't a place in the charter/milestones for that. > > The charter identifies these possible outputs in some combination: > > (1) a clear problem statement; > > (2) one or more protocol update document(s); > > (3) a statement of some kind that the WG determined no feasible protocol > solution exists (and, one would hope, how it reached this conclusion); > > (4) an update to current DKIM operational advice with respect to the stated > problem. > > The only constraint in the charter is that (2) and (3) are mutually exclusive.
Agreed with all of this. > I believe that a history of what techniques were previously tried and failed > could arguably go into any of them. The charter is neither prescriptive or > proscriptive on this point. It seems to me a history of what did work / didn’t will go into document 4 or the reasoning for document 3. My current preference is for the discussion to not be in the problem statement. My reasoning is that there will be discussion about what didn’t work and why it didn’t work. I expect that there will be quite a bit of back and forth to capture the details of why something didn’t work - including the adaptations that the attackers made to the changes. This, to my mind, is the job of the working group: to look at the current status, discuss where the holes are and if they are protocol holes or if they are best practice / implementation holes. On a more practical point, we have a month to finalize the problem statement. No one has proposed language to include in the problem statement about what has worked and what hasn’t worked. Given the current state of the group, I simply don’t think we have the time to put this into the problem statement and get it out in time. I do think we have the time and space to discuss techniques after the problem statement is done and include it in one of the WG output documents. laura (as chair) -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
