[AFS3-std] Re: rx throttle counts in rx-debug-peers

[Andrew Deason]

[Simon Wilkinson wrote]
>>> 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.

One of the questions here is what is appropriate for the
afs3-standardization list. I cannot see how it is a good idea to have
that conversation without involving afs3-standardization.

>>> 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.

Yeah, I meant I-Ds as part of their journey to becoming informational
RFCs or whatever.

>>> 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.

[Derrick Brashear wrote]
> 3) Implementation-specific details. Aside from where feedback from a
> larger community of implementors might provide perspective missing
> (did someone else solve this already and it's not widely known?) this
> is really an "internal" matter for whichever implementation.

I don't see why this is just assumed to be useless for other
implementors. What if someone wants to interoperate with OpenAFS, or any
other AFS implementation? That is, they want to read the rx debug packet
statistics from OpenAFS machines, or they want to interact with the ubik
beacon/voting protocols.

> [Mike Meffie wrote]
> > Personally, at this point I do think the debugging or introspection
> > structures are inherently implementation (and version) specific, and
> > should be out-of-scope for afs3 standardization, and should be
> > documented as part of an implementation. It would be important for
> > afs3 I-Ds to explicitly document such portions are implementation
> > specific and may change from version to version.
> 
> Actually, I'd think that would be limited to disclaiming items which
> are explicitly not standardized (for afs3) and thus up to
> implementations.

I'm not sure if I'm misreading you or Mike; isn't that what Mike said?
"This part is an implementation-specific blob; see the implementation
documentation for what it is."

-- 
Andrew Deason
adeason@sinenomine.net