I actually think this is a good approach and works well within the charter that we have for the group.
Put together a background document - that evolves from the problem statement including all the pieces that you mentioned * problem description * why this wasn’t solved initially * real world scenarios where this happens and some of the consequences of it backed by actual data * what has been tried and hasn’t worked (with some discussion of why it didn’t work) * what we considered and rejected In fact, I think that’s one of the legitimate outcomes of the group from the re-charter (https://datatracker.ietf.org/wg/dkim/about/): "If the working group decides that is unable to identify a consensus technical solution to this problem space, it may instead publish a report describing the problem and summarizing the reasons that none of the proposed approaches are acceptable.” laura (as participant) > On 1 Aug 2023, at 19:40, Barry Leiba <barryle...@computer.org> wrote: > > As someone who has, as an AD, questioned the publication of such > background documents, even in working groups I chartered, I can give a > related opinion about this one: > > I do think the background is important to publish separately for this > work, however easy the problem is to describe. I think it's important > that those interested have access to the problem description, reasons > that it wasn't solved in the original DKIM specification, things that > people have tried and that didn't work, and things that we have > considered and rejected, and any other such background that got us to > where we are now and that eventually gets us to what we propose, if, > indeed, we wind up proposing anything. And I think it's important > *not* to put that into any protocol proposal that we make, so as to > keep that specification clean and concise. > > Yes, we *could* put it into a protocol document as an appendix, but I > think in this case it could be longer than the protocol description > and will likely bloat the document and be distracting. I would rather > see something that that gives a one-paragraph summary of what we're > solving, a reference to the document with the broader background, the > proposed solution, and whatever limitations and cautions we see for > that solution. > > That said, this'll be my last opinion on that point, as I don't think > it's worth a great deal of debate and I'm happy to accept whatever > consensus we wind up with. Better to spend the effort on the > solution. > > Barry > > On Tue, Aug 1, 2023 at 1:30 PM Murray S. Kucherawy <superu...@gmail.com> > wrote: >> >> On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins <la...@wordtothewise.com> wrote: >>> >>> 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. >> >> >> I just did an informal poll of the IESG members that happened to be active >> in the IESG slack channel at the time I asked. >> >> There's a previous IESG statement on this topic that's relevant: >> https://www.ietf.org/about/groups/iesg/statements/support-documents/ >> >> Generally, this informal poll suggests the IESG disfavors a document that is >> nothing more than a problem statement. This aligns, unsurprisingly, with >> the IESG statement. Such documents, by themselves, have uncertain archival >> value. So if we want to publish a problem statement, with or without a >> "what we've tried" appendix, we should consider merging the proposed >> solution(s) into such a document before advancing it to the IESG. >> >> -MSK, ART AD >> _______________________________________________ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-dkim -- 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
