On Mon, Mar 14, 2011 at 5:15 PM, Andrew Deason <[email protected]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
