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

[Derrick Brashear]

On Mon, Mar 14, 2011 at 5:15 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> [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.

those people (who want to be compatible with openafs) presumably would read/
be involved in the openafs discussions (or whatever other implementation is in
question)

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

as long as the "documented as part of the implementation" comes from
the implementation and not from afs3-stds.
that was my only point.

-- 
Derrick