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. > > If you mean that it is undesirable *to OpenAFS* to do that, then I can > see that as something more appropriate for openafs-devel than > afs3-stds. Which I am resuming here. >>>> Secondly, we already have a mechanism for discussing code changes >>>> to OpenAFS, and I can't see why structure changes can't use that >>>> same mechanism. If it's an OpenAFS implementation detail, then >>>> surely it should be decided in exactly the same way as every other >>>> OpenAFS implementation detail. If a better form of documentation is >>>> required, then I would much rather that that documentation lived >>>> within the source tree, than in some location on the web that's >>>> subject to a far worse degree of bit rot. We've already discussed, >>>> at length, on how we should be using openafs-devel for design >>>> review in advance of coding, and this seems like just another >>>> instance of that. But we don't really discuss protocol architecture and such at any great length on here. The I-D and RFC format and process is a standard way of discussing, documenting, formulating protocols, and I don't see a reason for departing from it, except where we are using on-wire representations for which we explicitly don't care about backwards compatibility (which, without thinking about it too much, I think is true for at least some debug stuff... not sure on rxdebug). For everything else, we must maintain backwards compatibility and adhere to a "standard" (even if it's not called AFS-3) very rigorously. We cannot add/remove/change RPC arguments, for instance, in the same way that we cannot for any of the AFS-3-level standardized RPCs. So any published standard for those protocols will not "rot", as any updates for future versions will just be adding new RPCs (or modifying the protocol in question in a backwards-compatbile manner), which is the same as in AFS-3. I'm not saying it needs to be part of the same AFS-3 process (though that would be easier, as it's already set up), but a common format for the description and discussion of the protocols makes more sense to me. We are much more likely to accidentally do something stupid with some internal protocol without a process like that. I know that the existing protocol-level messes (like xstat) aren't the fault of any OpenAFS-era changes, but if we treat them like any other change it seems like some could appear. But if we treat them separately like protocol changes with set waiting periods and such, we prevent them more robustly, I think. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
