Sent from my iPhone
> On Mar 27, 2023, at 6:40 PM, Scott Kitterman <ietf-d...@kitterman.com> wrote: > > 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). In the absence of a competing draft and if that’s the consensus of the group, yes. Laura > > Scott K > > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
