[OpenAFS-devel] Re: [AFS3-std] Re: rx throtll counts in rx-debug-peers (was: Re: Re: Request for new fields in rx_statistics)

[Simon Wilkinson]

[On afs3-standardisation, Andrew wrote: ]

>> However, that does not preclude a specification, which raises another
>> question: can/should we publish OpenAFS-specific standards? If we =
make
>> I-Ds that clearly demarcate themselves as for OpenAFS and not AFS-3 =
in
>> general, it would seem valuable as a standard specification for these
>> kinds of things. The same thing could go for the Ubik voting/beacon
>> protocols, cmdebug, and other things that so far have appeared to be
>> considered "internal" to OpenAFS, but still travel over the wire.

[and Tom replied ... ]

> As one of the people Andrew spoke with about this earlier today, I'd
> like to second this proposal.  Even if we merely use the I-D
> format--yet publish via our own OpenAFS-specific document submission
> stream--I think there would be a lot of value in formalizing the
> process of changing/documenting OpenAFS-specific behavior.

This is the wrong place to be having this discussion - it really belongs =
on the OpenAFS lists. I've CC'd openafs-devel with this response, =
hopefully we can continue this discussion there.

I have a number of concerns with this approach. Firstly, it's important =
to note that I-Ds are not an archival document series. Publishing an I-D =
may serve as a useful, if heavyweight, means of encouraging discussion, =
but it does nothing in terms of ensuring that the document is available =
in the future. The only way to do so is to advance the I-D to an RFC. =
However, discussing OpenAFS implementation details within the RFC series =
is definitely inappropriate.

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.

Cheers,

Simon.