On Mon, Mar 14, 2011 at 7:03 PM, Simon Wilkinson <[email protected]> wrote: > > On 14 Mar 2011, at 21:42, Andrew Deason wrote: > >> On Mon, 14 Mar 2011 16:15:57 -0500 >> Andrew Deason <[email protected]> wrote: >> >>>>>> However, discussing OpenAFS implementation details within the RFC >>>>>> series is definitely inappropriate. >>> >>> I don't agree with this as an unqualified statement. The parts of the >>> wire protocol that are OpenAFS-specific are still a wire protocol >>> (though not necessarily AFS-3), and my limited understanding of the >>> IETF is that pretty much any wire protocol is appropriate/eligible as >>> at least some kind of RFC (in this case, Informational). At least, >>> from the perspective of the IETF / the RFC series. > > I think you are misunderstanding some fundamentals of how the IETF works, and > the relationship between the IETF, the RFC series, and the > afs3-standardisation group. The AFS-3 standardisation group does not exist > within the umbrella of the IETF - in fact, it was felt that it would be very > difficult for it to do so. The IETF has a proud history of not rubber > stamping existing protocols, are keen not to duplicate the work of existing > working groups (in our case, NFSv4), and require the granting of change > control that it would have been politically difficult to secure. It would be > difficult to get any AFS-3 documents past IETF Last Call, even as > informational publications. > > Instead, the afs3-standardisation group has its own model, which is based > loosely upon the IETF's (because those drafting the process had some > familiarity with the IETF, and believed that what worked there was worth > emulating). Where we converge is in our use of tools, and in particular, in > our archival document series. RFCs contain far more than just IETF documents. > There has been a long history of the Independent Submission Stream (note that > these are distinct from independent submissions to the IETF, which ultimately > end up being IETF documents) - a series of documents from independent > authors, which don't pass through the IETF process, and receive minimal > scrutiny from the IESG. RFC5742 describes the process for publishing within > this series. > > It should be noted that publishing an RFC is not a lightweight process. It > requires the work of the RFC Production Centre to proof, sub edit, and > generally turn our drafts into publishable documents. It requires the > Independent Submissions Editor and their advisory board to review that > document for technical content, and to solicit external reviews as required. > It requires the IESG to review the document for conflicts with work being > done within the IETF. This is a substantial outlay of time and effort. > > We have yet to establish whether publishing AFS-3 standardisation documents > within the Independent Submission Stream is seen as a suitable use of that > effort by those administering it. Doing so is one of the outstanding actions > on our standardisation group chairs. I firmly believe that doing so for > OpenAFS specific documents would be an entirely inappropriate squandering of > scarce resources. >
When I voiced my support last week, it was not for wasting the IETF's time. Rather, it was for utilizing the I-D format and tooling specifically to publish our own independent OpenAFS-specific document stream. I was envisioning something along the lines of submitting xml2rfc files to gerrit, and then letting them go into the tree somewhere under doc/, or, perhaps, a new repository on git.openafs.org, following some period for discussion on openafs-devel... Cheers, -Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
