[OpenAFS-devel] Re: rx throttle counts in rx-debug-peers

[Andrew Deason]

On Mon, 14 Mar 2011 16:15:57 -0500
Andrew Deason <adeason@sinenomine.net> 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
adeason@sinenomine.net