On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote: > > On 27 Mar 2023, at 16:46, Scott Kitterman <ietf-d...@kitterman.com> wrote: > > > > On March 27, 2023 3:10:40 PM UTC, Laura Atkins <la...@wordtothewise.com> wrote: > >>> 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.> > > So far, unless I was napping when it happened, we don't have a working > > group draft of the problem statement. > We have two documents that are up for debate as the working group draft. > Anyone else is welcome to provide an alternative for consideration as well > - as Dave did and that is now being wrapped into Wei’s draft. > > Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before > > investing any more time on the problem statement. I think it would make > > sense for the group to do a quick assessment of it, when it is available > > and see if we want to adopt it as a working group draft (I strongly > > suspect we do). > That’s my feeling as well, particularly given no one else is stepping up to > write a draft of the problem statement on behalf of the working group. If > someone does have an alternative in progress please let me know.
Do you plan adopt it as a working group draft? That's a critical step in the process. Anything before that step needn't reflect anything other than the author's opinion (and that's optional). Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
