Jeffrey Altman <[email protected]> writes: > Jason asked what the impact of this decision has on the AFS3 > standardization process. This decision means that the IETF and the RFC > Editor cannot be used to publish archival copies of protocol documents > that are created by this group. This group can still publish documents > on a web site of its own, via mailing list archives, or many other > methods.
I would not worry too much about losing the IETF publication forum. Yes, it has some nice properties, but they're certainly not mandatory. The share of interesting protocol work done under the auspices of the IETF has been dropping rapidly. It's now much more common for new protocol design that's happening in the fast-moving areas of the Internet (such as web services) to be done by some other standards body (OASIS, W3C), industry consortia, or just by people putting forward proposals via their existing web presences and having them be adopted by others. We were using the independent submission track anyway, so what the IETF was giving us was editing and distribution, and while those things are valuable, they're not vital. This issue has never been the serious blocker for standards work around AFS. That blocker has always been the same thing that blocks most things about AFS: simple lack of time among the people who are currently able to do the work. Standards work is both difficult and time-consuming. It requires writing lots of documentation to exacting standards, with a mindset very similar to the mindset that one uses when doing security reviews. Finding a place to publish good-quality results is the least of the challenges. So far, most of the standards documentation around AFS that's been written was written primarily because it was mandatory for merging code into OpenAFS, and even then a lot of work simply stalled out on the standards process. One way to get standards documentation written, if it's considered very important, is to use that sort of stick approach and refuse to take code without standards documents. But I think people need to decide if standardization and reviewed protocol specifications are sufficiently important (and provide sufficient improvement in the resulting quality of implementation) to warrant possibly blocking implementation forever because the standardization work doesn't happen. This isn't an easy tradeoff. It's very easy for poorly-specified protocol changes to cause serious problems years later, long after backing out of them has become quite difficult. But if people consider standards documents to be valuable, then community contributors are going to have to step up and do the work, and the amount of work required is considerably more than we're currently accomplishing here. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
