> 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. > 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... > 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. > 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. > > 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. 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. -- db _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
