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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
