[AFS3-std] IBM will not re-license OpenAFS .xg files

[Russ Allbery]

Jeffrey Altman <jaltman@your-file-system.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>