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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCD6C6D84E0150829CC027296
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/11/2011 6:10 PM, Tom Keiser wrote:
> On Mon, Mar 7, 2011 at 6:55 PM, Derrick Brashear <shadow@gmail.com> wro=
te:
>> -09 in a moment with only that change.
>>
>=20
> Hi Derrick,
>=20
> I just re-read, and I have two eleventh-hour nits (given how close
> this document is to publication, please feel free to tell me to shut
> up!!!):

I agree with Simon that at some point people need to be able to trust
that the standard is a standard so that code can be deployed.  This
process is supposed to permit sites to be able to do so without fear
that their deployed clients and servers will suddenly fail to
inter-operate with the rest of the community.

> 1) Section 7.3 (GetCapabilities RPC): imho, we should add a paragraph
> specifying a cache TTL for the capabilities bit vector, e.g.:
>=20
> "Client implementations MAY cache the returned capability bit vector
> for up to two hours.  If a client needs to invoke any RPC dependent
> upon knowledge of the server's capabilities, and AFSVolGetCapabilities
> has not been invoked within the last two hours, then the client MUST
> re-fetch the capability bit vector using AFSVolGetCapabilities--and
> verify that the now-present capabilities are consistent with the
> desired invocation--before invoking the dependent RPC."

This document at the present time says nothing about caching of
capabilities data which puts this GetCapabilities RPC in exactly the
same situation as that for the other GetCapabilities RPCs that we have
in use.  The other GetCapabilities RPCS (and I'm include VL_ProbeServer
as a pre-GetCaps RPC) is that they are called on a very frequent basis.
 On the order of every ten minutes or less and immediately when a cache
manager receives an RXAFSCB_InitCallBackState() from the server in
question (for RXAFS_GetCapabilities).

What I think would be appropriate in this instance would be to not
modify this standard but instead write a new document that describes
proper client use of GetCapabilities RPCs in general since we expect
them to be added to each service over time.

> 2) Section 7.4.6 (RemoveAuthName): this design is racy (since we have
> no notion of record lock/transactions); is there any chance we could
> agree to add an "IN afs_int64 id" parameter to the RPC in order to
> eliminate the race?

There are actually two problems.  The first is that as a double check we
should have the full mapping specified.   The second is that it isn't
specified what happens when the last mapping is removed from an id.
Does the id at that point become deleted?

While I agree with Simon that the principal of standards publication is
important.  I also believe that it is important to ship code that works
properly.  Therefore, I believe it should be left up to the implementer
to decide whether or not it is acceptable for the standard to be altered
once it has been approved by the group.  Only the implementer knows what
the impact of such a change would be.

By that rationale, if Derrick wishes to submit a change I will support
him.  If Derrick decides that a change at this point is too hard to
make, I will support that decision as well.  If anyone else is
implementing this document, please speak up.

Jeffrey Altman


--------------enigCD6C6D84E0150829CC027296
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJNe8C4AAoJEPd6c1WStpoEgIoP/3PRVu9WSO3v5l7Y4nrZDNl1
yvs3rA1w/zL/tef/sqT40d6q/gFilDr8ehpPXfCmRCZYOqMyRICEzq8T7zOk7zyY
3jarZeKylWXs0+1ZKu+E0q78QDlVt7a3JZKzvRdO9Z5CJz0z9qOX/SoLDaFhiXpv
04/yq4jPX/fpvqMnZQxILn1ElezAu1UYFt+hrYulvDUO2E95crfhtJC9Ch4T8AJz
ScToQ4p9ar3PM6izTTO0fUaw673HsDyRGe84LGZZZ5/eZ+G6GqikHMleYVyfwgLj
wbYhJINcIiMTUd+XvK4BHkGrwVcmGo2o2ftyhwHGj3GPJmo91jJ8FlImkTTM98+j
np00xQU4iD/aLPouBE2AjLY/Pq/Pbl3k5K37UHupFuzUKutzuZzNkwFwBCLNdowY
89BuocIEfw8RkqDgkPbr1kbFrH0Gp+0QXY91a7V/HZmu6gLeetSPzT5tfbej6I2O
DHLhOw5CR1Yj8hRxfHAF1jpbOpPzVwdVQGhNRk67ppwzc9KC9j48gL8YdFEbJc9M
Z/892oOet3fW0gmhq1sY6thwhzdYgHWGUlVO7UzqDNReYJMHBhazua7jtbEKq1v1
Au6/W0z2DtcN2sI41KnyQYaUwaBzcjTUZY1QkO3TwMYSQrr+1fLUWIFg1KBsA32Z
1O/Jn5Z78uX3m5iiddx/
=gHk7
-----END PGP SIGNATURE-----

--------------enigCD6C6D84E0150829CC027296--