I would prefer to see the "what hasn't worked" stuff as part of the problem statement, as those things will inform the work we do so they need to be documented up front, and they will not be part of the product of what we do so it doesn't make sense to include them later. The eventual product should point back to the problem statement for the background information.
Barry On Tue, Aug 1, 2023 at 11:29 AM Laura Atkins <la...@wordtothewise.com> wrote: > > Hi, All, > > > We have a current version of the draft problem statement available on the > data tracker. Murray and a few others made a few comments that were added in > the -03 version. > > > https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp28Y8uSme1Q/ > > > Based on discussions, there seems to be favor to documenting what has been > tried and not worked. > > > Question for the working group: Should the discussion of what hasn’t worked > be in the problem statement as an Appendix? Or should it be in a separate > document as working group output? > > > Along the same lines, do members of the working group feel we should include > some of the solution space in the problem statement? Or should the discussion > be reworked? > > > Perhaps instead of "possible solution space" maybe "scenarios and how they > affect dkim replay" ? We welcome any suggestions of wording changes. > > > laura > > > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > 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
