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 _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
