I agree with Mike and Scott on the point that it’s worth explicitly allowing the result to be a “can’t do it” publication. Implicit “couldn’t do it” is fine in most cases, but here we might say something like, “If the working group decides that none of the proposed approaches will work acceptably well and is unable to find an acceptable alternative, it may instead publish a report describing the problem and summarizing the reasons that proposed approaches are not acceptable.” Making that explicit will avoid arguments about whether such a document is within the charter scope.
Barry On Sat, Dec 24, 2022 at 4:17 PM Michael Thomas <m...@mtcc.com> wrote: > > On 12/24/22 1:08 PM, Scott Kitterman wrote: > > > > On December 24, 2022 8:22:45 PM UTC, Michael Thomas <m...@mtcc.com> > wrote: > >> On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: > >>> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas <m...@mtcc.com> 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. > >>> > >> I think it's worthwhile for the charter to have a step which is to > determine whether the problem is 1) tractable and 2) requires IETF to do > something. If either of those are false, the charter should say that it is > completed. There has been quite a bit of skepticism expressed (and not just > by me) about both of those points so it would be good to have a checkpoint > before doing something to do something. > > > > +1. I think it's a mistake to assume deciding not to make protocol > changes by the group is a failure. A reasoned decision that additional > protocol changes would not be helpful would be a success, if that's where > the facts lead us (I have opinions on this, but have reached no definitive > conclusions). > > and write an informational RFC explaining the outcome. heck, it would > probably be worthwhile to keep an ID going during that period to > document the various ideas/approaches. > > Mike > > _______________________________________________ > 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
