--On Thursday, December 13, 2012 23:51 +0200 Yaron Sheffer <yaronf.ietf@xxxxxxxxx> wrote: > Hi Randy, > > the RPKI report is very impressive and probably very useful. > But: > > - Other areas (e.g. the Security Area, where I'm coming form) > may not have this tradition. If it is important, nothing prevents establishing it. > - For "smaller" protocols the gain does not justify the effort > of writing a separate implementation report. A section in the > base document is much simpler to maintain. I'm not at all clear why it is more effort to write a separate report. But, assuming it is, I am aware of nothing in any IETF or RFC Editor procedure that prohibits including a discussion of implementation experience in a standards track RFC. > - And as I noted earlier on this thread, a wiki is a good > alternative, provided everyone reading the base draft is > referred to the "implementation status" wiki. They should not > have to guess that one exists, or to search for it. That is a more complicated problem because the RFC Editor is somewhat reluctant (for good reasons, IMO) to accept references to web pages whose permanency is not assured. There are, however, lots of other ways by which one could imagine creating and maintaining such pointers. For example, if you could convince the community that this was important, and likely to be done often enough, you might lobby the IESG to negotiate an additional sentence in the "Status" section of standards track RFCs that provided a stable pointer to an index of implementation reports. My concern remains that we not create new formal procedures to do (or even experiment with) things that can be done under existing rules either for the whole IETF or on an area by area or even document by document basis, Let me suggest, as co-author of the "process experiment" doc, that it was intended to deal to allow experiments that would otherwise be in violation of existing procedures. As far as I can see, that situation doesn't apply with either of these proposals. And, given the number of experiments carried out with reference to RFC 3933 that did not result in useful and formal reports back to the community, I'm unconvinced that formally identifying any particular exercise in identifying implementations or handling some specifications with implementations differently in the IESG review process than other specifications will increase the odds of the results being examined carefully and critically enough to generate a report and, through it, permanently change behavior. YMMD but, if either of these ideas are interesting, persuade a friendly AD to try it on whatever scale makes sense, and then let the rest of us know how it worked out for you. Since no existing rules would thereby be violated, IETF consensus is not required for such an exercise... or any number of such exercises. best, john