Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
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 wrote: > > On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins 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
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins 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
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/1/2023 8:56 AM, Barry Leiba wrote: The eventual product should point back to the problem statement for the background information. That is certainly a valid approach. However I suggest it's less efficient for this topic and possibly will lose some casual readers of the spec, by virtue of the indirection. (Extra clicks cost usability.) I suggest, instead, whatever spec is produced have a statement of the problem. This is a relatively simple problem to explain. No doubt the text will be drawn from this draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/1/2023 8:28 AM, Laura Atkins wrote: 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? Is the intent to publish the problems statement as an RFC? It isn't immediately clear to me that it's worth the effort to do that, since one would expect any 'solution' specification RFC to contain a basic problem statement. If this were a highly complex problem that required extensive explanation, I could imagine wanting a separate document to be published. Or if this were a research topic, expecting to need a long time to produce a useful engineering response; then a published problem RFC would mark the topic for wider awareness. I think the current case is neither. The problem statement document is useful as working text, for immediate use. So, to answer you question: if the problem statement is NOT going to be published, it doesn't matter whether case analysis details are in it or in a separate draft. 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 think casting it in those terms will likely be more useful and less likely to conjur philosophical debates. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
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
