[AFS3-std] AFS Standardisation

[David Boyes]

> 1. The IETF is not interested in another file system to standardize.
> The actively developed IETF distributed file system protocols are
NFSv4,
> WebDAV, and SCP.

I think that's a matter of opinion, but Simon's proposal is adequate to
the day. We can at least publish it and move forward as opposed to
debating it interminably. Moving it into a WG can be done later if
considered desirable.=20

> 2. The IETF does not standardize pre-existing protocols.

Other than LPR, http, BGP, IS-IS...? Hmm. I was rather under the
impression that the RFC process also captured general practice as well
as new items, but...=20

> Assuming that
> the IESG was convinced to permit AFS3 to become an IETF standard
> protocol the chances of it remaining backward compatible is close to
NIL.

Mmf. This bothers me. There needs to be conscious attention paid to
migration and deployment, then -- otherwise you run the ISO-style
"well-documented but undeployable" standards risk. Haven't seen much
discussion on that topic yet.=20

> 3. The IETF standards process is very heavy weight.  We want a process
> that does not require years to move extensions forward.

On the other hand, it does tend to weed out poorly thought out or
operationally unusable extensions. Having to put the necessary reasoning
and effort behind something that will be written as required matter into
the stone of the protocol *ought* to be something that is not taken
lightly or done frequently.=20

> > At least I hope that's what we're trying to do.
> What we are attempting to do is separate protocol standardization from
> the code that is committed to OpenAFS.   Protocol standardization
should
> be a community design process not simply the submission of code
written
> behind a closed doors and committed to the OpenAFS repository.   We
want
> to ensure that any organization that wants to build an AFS client or
> server can do so.  In order for that to happen there needs to be
> documentation that specifies how code should work, not just code that
> happens to work in a particular way.
> Jeffrey Altman

I think we're all aware of the purpose of standards, Jeff.=20

My concern is that what is *standard* be reasonably stable and tested as
interoperable, and that the consensus that captures those function be
something that is carried out in a well-understood way that tests those
mandatory features in ways that demonstrate independently and in a
documented manner that they are worth requiring.=20

That's why I don't much care for inventing Yet Another Process if
someone else's process is already available and accepted as an industry
vehicle for delivering credible standards documents. If that's not an
option, then Simon's draft draws in as much useful stuff as I've seen,
and it's a good working draft as a first iteration -- let's test it and
see where it gets dinged.=20

That doesn't change the fact that using an existing model is likely to
get you further acceptance in the process simply because the existing
processes *are* excruciatingly well documented, and more people know how
to play in that arena. Niches don't *have* to be pointlessly unique.=20

-- db