Re: [Ietf-dkim] Rechartering
On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: > Shouldn't the problem statement explore whether there is a plausible > tractable solution before it moves on to protocol work? That is, if there > isn't a tractable solution the wg should go into hibernation again. I'm > pretty sure that I brought this quite a while ago. Of if not the problem > statement, afterward just evaluating for a go-no go decision before > starting any work. > A working group is implicitly allowed to admit defeat if it decides it can't solve the problem it thought it was supposed to solve. DBOUND comes to mind; it deadlocked on whether the problem was tractable, or even well enough understood, to advance a consensus protocol solution, and closed without producing anything. I don't think the charter has to say that expressly. It's part of the process. The charter stipulates an ordering, and I think that's sufficient. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/23/2022 11:38 AM, Murray S. Kucherawy wrote: Having heard no further feedback, I've moved the draft charter to the next state, which will trigger the first of two IESG reviews early in the new year. It will go out for full IETF review after it passes the first of those. The draft looks good. The specified work tasks are: The DKIM working group will first develop a clear problem statement, which it may choose to publish. Then, it will produce one or more technical specifications that propose replay-resistant mechanisms. A problem statement needs to state the problem well enough for an average reader to understand not just its gist -- which arguably is already provided in the second paragraph of the charter -- but the details of scenarios that produce the problem. A sufficiently detailed characterization might, indeed, warrant a separate document, though I hope that won't be needed. On the other hand, a document with that detail that also explores 'solution' issues -- without diving too far in their details and definitely without choosing winners -- might be a very useful milestone for garnering wider community understanding (and even participation.) It's worth being clear about problem vs. solution. So a problem statement, per se, shouldn't cover solutions, since, well, it's a problem statement and not a solutions statement. The "will produce one or more" is, of course, optimistic, since wg efforts can fail. But noting that in a charter isn't all that useful, especially since it's never part of the plan. More significantly, suggesting more than one nicely alerts to the possibilities that a) we might require more than one to get things under control enough, and/or 2) there might be competing specifications worth pursuing. 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] Rechartering
On 12/23/22 11:38 AM, Murray S. Kucherawy wrote: On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy wrote: I've synthesized the feedback to date into a new update to the charter text. It calls out the order of operations the group seems to prefer, and makes explicit the possible output of a "best practices" update. Let me know if this is a step in the right direction or the wrong one. https://datatracker.ietf.org/doc/charter-ietf-dkim/ Note that the next IESG telechat with room on it won't be until the new year at this point, so this won't advance before then. Having heard no further feedback, I've moved the draft charter to the next state, which will trigger the first of two IESG reviews early in the new year. It will go out for full IETF review after it passes the first of those. Shouldn't the problem statement explore whether there is a plausible tractable solution before it moves on to protocol work? That is, if there isn't a tractable solution the wg should go into hibernation again. I'm pretty sure that I brought this quite a while ago. Of if not the problem statement, afterward just evaluating for a go-no go decision before starting any work. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sun, Dec 11, 2022 at 7:25 PM Murray S. Kucherawy wrote: > > I've synthesized the feedback to date into a new update to the charter > text. It calls out the order of operations the group seems to prefer, and > makes explicit the possible output of a "best practices" update. Let me > know if this is a step in the right direction or the wrong one. > > https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > Note that the next IESG telechat with room on it won't be until the new > year at this point, so this won't advance before then. > Having heard no further feedback, I've moved the draft charter to the next state, which will trigger the first of two IESG reviews early in the new year. It will go out for full IETF review after it passes the first of those. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
