> To add one observation to SM's comment and other observations > that the scarcity of implementation reports implies that they > are somehow difficult... > --On Friday, August 05, 2011 02:45 -0700 SM <sm@xxxxxxxxxxxx> > wrote: > > I presume that the IESG will only use the following criteria > > for advancement: > > > > - two independent interoperating implementations with > > widespread > > deployment and successful operational experience > > > > - no errata against the specification > > > > - no unused features in the specification > > > > And there won't be any DISCUSSes along the lines of: > > > > "I don't think the implementation reports are adequate for > > me to meet the > > requirements of 2026. It does not clearly identify what > > software was used or > > show support of each of the individual options and > > features." > > > > "Examples througout the document make use of non-example > > domains." > > > > "The implementation report is woefully inadequate to > > document there are > > interoperable implementations of all the features from two > > different code bases." > > > > "My Discuss was not addressed at all - I believe that the > > WG ignored the > > spirit of the implementation report requirement - my > > Discuss said that > > we should know that there are multiple implementations > > that have > > handled the significant changes in the recycling of this > > Draft Standard. > > The group apparently refused to update its implementation > > report" > An alternate hypothesis about the low numbers of implementation > reports on file is that people try them, get responses like the > ones SM lists above, and react with "why bother -- this is a > waste of time that I can better spend in other ways". And that > is the end, not just of the report being commented on, but any > others that could have come from that author or participant. That pretty much nails it. We've allowed exactly these sorts of vague and nonspecific discusses to stand, with the result that the pain of getting to draft or full standard is seen as far greater than the gain. The really surprising thing, frankly, is that we have as many draft and full standards as we do. > While it has not been raised as a specific argument for this > two-maturity-levels proposal, getting rid of formal > implementation reports might, for that reason, be useful in > getting documents advanced. However, it does not improve the > case for two levels instead of three and won't help if IESG > members express the same thoughts --not in terms of > interoperability reports but in terms of lack of conviction the > interoperability had actually been demonstrated in the case of > that particular spec. Actually it does in a way. Part of the problem with going to draft is that in addition to it being painful and difficult, when it's over you're still not done. And you have to wait for the final step, and when you get there it's not all that well defined, either. Really, this is Psych 101 stuff - it's been shown over and over that immediate gratification wins out over long term satisfaction. Our three step process sucks most if not all of the immediate gratification out of moving to draft. And this is why I strongly support a move to a two step process. I think the other changes that have been proposed are also important but I'll take what I can get. > I note that, when RFC 4846 and what became 5742 were under > discussion, a then-IESG member pointed out to me that, despite > the restrictions in those documents, if something in a draft > really offended him, he could always find a way to state his > objections in a way that would conform to the 4846/5742 rules. > The same comment presumably applies to presumed proofs of > independent interoperable implementations. I really have to wonder if the entire yes/no-obj/discuss voting model is appropriate for document advancement. For initial approval at proposed, sure, having the ability to "discuss" the document makes all sorts of sense. But for subsequent steps that virtue is a lot obvious, to me at least. Ned _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf