[AFS3-std] AFS Standardisation

[Jeffrey Altman]

David Boyes wrote:
>> 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. 
Discussions were held with members of the IESG during the Spring 2008
IESG Retreat.
The outcome of those discussions was the suggestion that the OpenAFS
Foundation
make use of the RFC Editor's independent submission process as a forum
for publishing
future AFS standards.

During the workshop in Newark NJ the AFS community voiced concerns over the
standardization of the AFS protocols by the legal organization that
controls the
most popular implementation.

As a result of those discussions, Simon's proposal was drafted.
>
>> 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... 
You are confusing the existence of an RFC with the output of an IETF
Working Group.
Not all RFCs are the result of the standardization process.   SSL, SSH
and XMPP are good
examples of what happens when an existing protocol is submitted for
standardization.

>> 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. 
Lets put it this way.  If you want an IETF AFS Next Generation WG you
will need to
first hold a BOF that puts forth a formal charter of work items that the
WG is intended
to accomplish.  One of the pre-reqs for the BOF is going to be
documentation of the
existing Rx and AFS protocols.  We don't have such documentation.  We
will also have
to show where the resources are going to come from to perform the work
necessary
to complete the WG Charter.
> 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. 
>
> 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. 
>
> 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. 
Many of the members of the AFS mailing list have a long history of
participation in the
IETF as document editors, working group chairs, bof chairs, nomcom
members, and
application area and security area directorate members.  This is a
strong understanding
in this group of what the IETF is good at and what it is poor at.   

At the present time the IETF and AFS are not a particular good fit.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20080821/c720bee0/smime.bin