Pete Resnick <presnick@xxxxxxxxxxxx> wrote: > > I *really* want an answer to the issue that Scott raises. Eric and Brian > each refer to a "baby step". A baby step toward what exactly? > > If the answer is simply, "to align documentation with current > procedure", that's fine, but then I want to know: > a) Why is it useful and positive to line up documentation with current > procedure? That is, what are we gaining by publishing this? and > b) This document is identical to neither 2026 *nor* current procedure, > so how is it accomplishing the goal of aligning with current > procedure anyway? Although, to tell truth, I don't care very much whether this I-D becomes an RFC, I am _very_ glad that Pete is raising these questions. We have been wandering in the weeds for years now over "how many steps should there be?" IMHO, the last serious WG effort (newtrk) reached something very like consensus that that was the wrong question. I _seriously_ hope the IESG will either decide to enact this I-D or stop beating this horse. I suggest that we accept the principle that "consensus" process means it will be hard to change something in the future; and admit that "adjust to current practice" isn't a sufficient shibboleth to gain consensus for a change from a previous consensus. It _is_ appropriate for anyone sufficiently bothered by failure to follow current documented rules to appeal actions which don't follow the "rules". That _will_ make you unpopular with the folks that must process the appeal, but it is less harmful than asking the entire IETF to wander in the weeds in seek of consensus to change the "rules". If I may make a suggestion, actual practice could be documented on ietf.org web pages (with some explanation of how it differs from the RFC "rules" and why) -- without all this wandering in the weeds. It is _really_ unlikely that would invoke the full appeal process more than once, and it would save a lot of bandwidth on this list. BTW, while I do intend to be silent if the IESG adopts this I-D for publication, that does _not_ mean I will be silent when the next "adjust to current practice" I-D comes up. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf