On Fri, Mar 11, 2011 at 6:51 PM, Simon Wilkinson <[email protected]> wrote: > > On 11 Mar 2011, at 23:27, Tom Keiser wrote: >> So, what are we going to do about the GetCapabilities issue? A >> compliant implementation could cache this data forever, which >> is.....preposterous. Can we can handle this via the RFC errata >> process? > > It's not an RFC, and we're not the IETF, so no. > > We've never really codified what happens next, beyond that being declared > "experimental" is the point that people can go away and get identifiers, and > release products containing the code. It's really important that this mean > something, which is why I don't think we should accept late challenges or > modifications to the document. People should be free to go away and write, > and release, code based on this groups consensus without worrying that weeks > later someone will go "hang on", and rewrite the standard under them. > > Sure, we may get it wrong. When we do, we have to accept that code may be > deployed containing our mistakes, and we have to consider how to fix those > mistakes without breaking the deployed base. > > In this case, there are two separate issues. The first is a document > clarification (GetCapabilities responses should only be cached for a certain > number of hours). I think that one is acceptable to bring back as a > clarfication when the document is next advanced (which is the point it will, > hopefully, become an RFC).
Hi Simon, Ok. That's perfectly fair. I certainly don't want to hold up the implementation process. If we can introduce a TTL clarification during the transition from afs3-stds experimental to informational RFC, then I'd certainly feel a tad better. However, if that would complicate Derrick's implementation of the GetCaps client, then please let me know and I'll forget I ever brought this up :) > > The second, however, is harder. I don't think that we can add fields to RPCs > that have reached experimental. So, we have to decide whether the possible > race is sufficiently serious to warrant creating a new RPC, with a new code > point, to implement this behaviour. In any event, it's perfectly acceptable > for people to release code and/or ship products that contain the RFC as > described within the current document - all we can do is propose a better > successor. > Indeed. Conveniently enough, my second point is a total nit; if we ever see this race in the wild, I'll honestly be a bit surprised. Anyway, should we ever feel the need, introducing a RemoveAuthName2 RPC with the second argument in a future I-D is quite simple... Cheers, -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
