[AFS3-std] draft-brashear-afs3-pts-extended-names to Experimental

[Tom Keiser]

On Fri, Mar 11, 2011 at 6:51 PM, Simon Wilkinson <simon@sxw.org.uk> wrote:
>
> On 11 Mar 2011, at 23:27, Tom Keiser wrote:
>> So, what are we going to do about the GetCapabilities issue? =A0A
>> compliant implementation could cache this data forever, which
>> is.....preposterous. =A0Can 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, a=
nd release products containing the code. It's really important that this me=
an something, which is why I don't think we should accept late challenges o=
r modifications to the document. People should be free to go away and write=
, and release, code based on this groups consensus without worrying that we=
eks 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 clar=
ification (GetCapabilities responses should only be cached for a certain nu=
mber of hours). I think that one is acceptable to bring back as a clarficat=
ion when the document is next advanced (which is the point it will, hopeful=
ly, 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 R=
PCs that have reached experimental. So, we have to decide whether the possi=
ble 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 accep=
table 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 bette=
r 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