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. 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. 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. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf