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

Jeffrey Hutzelman jhutz@cmu.edu
Thu, 30 Aug 2012 17:23:05 -0400


On Thu, 2012-08-30 at 15:34 -0500, Andrew Deason wrote:

> I am saying that the state of that document
> was, and even now continues to be unclear. If the "todo" is "create
> another document to fix those issues" then fine; that is the answer to
> my question earlier. I see nothing decisive in the last thread about
> this:
> <http://thread.gmane.org/gmane.comp.file-systems.afs.standardization/985>
> 
> If the document was "done" and is an "AFS standard" as much as we have
> one, that needs to be announced, or, like, be on a list somewhere.
> _something_

<sigh>
I went back and looked at the actual history of this document.
We had a consensus call to approve this document as "experimental", in
the terminology of our provisional charter.  That call eventually
passed.  Advancement to "standard" requires at least one successful
implementation and another consensus call.  AFAIK we haven't had that,
so the document's status is still "experimental".

My reading of the provisional charter is that this document should not
have been submitted to the ISE until advancing to "standard".  Prior to
that point it should live in the Internet-Drafts repository.


The provisional charter doesn't say much about what changes we can make
to a document that is in "experimental" status, but I believe the
intention is much the same as for an IETF Proposed Standard.  That is,
if there are problems found during implementation or that the group
feels are worth fixing, we can publish a new document which amends or
replaces the previous one.  The original, approved document should not
be revised, because that makes it hard to understand the history and to
have a stable reference for the thing the group approved.  However, the
new document could be a modified copy of the old one.  Whether the new
document has to go through the whole process from scratch or can proceed
directly to "standard" becomes a function of how much and in what way it
differs from the old and, ultimately, of what the group decides it wants
to do.


> So, from what I am assuming from this email and from Jeff's is that
> there are 2 tasks related to that document:
> 
>  1. Write a new document correcting the TTL and RemoveAuthName issues,
>  or ignore the issues and try to deal with them in implementations. It
>  is still not clear which of these is what is intended to be done.

That's a matter for discussion, I think.


>  2. Get the doc on some kind of more 'official' site.

Yes.


> The fact that I have to assume those things and gather them from various
> emails... <rant> _this_ is what makes this so aggravating all the time.
> This is why there is so little interest, so little movement, so little
> progress. This is why, while I believe standards work has some intrinsic
> difficulty and tedium, this particular process currently seems
> borderline impossible to participate in productively. </rant>

You're right, and I'll see what I can do to remedy that.  I recall
offering to provide space for the chairs to set up a web site for this
sort of thing, before I was one of the chairs, but that sort of fizzled.
And I'll be the first to admit that I've not done anything over the last
year to try to get this moving.  However, now I think it's time to
revisit that.


To that end, I'd like to explcitly ask for comments on the notion of
abandoning the RFC-Editor process entirely, in favor of publishing all
of our "experimental" and "standard" documents on a web site maintained
by this group (and specifically, by the chairs or their delegate(s)).

-- Jeff