+ When a client releases a share reservation, or the reservation + expires, this has the expected effect on future share + reservation requests. That is, such requests must be compatible + with the intersection of still-outstanding share reservations + (if any).
I think I'd just explain the effect and not say it's "expected", which is a value judgement. Other than that this change looks good. On Wed, May 12, 2010 at 5:23 PM, Matt W. Benjamin <[email protected]> wrote: > Hi, > > The following updated draft has been published: > > http://www.ietf.org/id/draft-mbenjamin-afs-file-locking-03.txt > > The key changes are to share reservation flags and semantics, which we think > were not correct in previous drafts. > > Thanks, > > Matt > > -- > > Matt Benjamin > > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > http://linuxbox.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 > > _______________________________________________ > AFS3-standardization mailing list > [email protected] > http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization > -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
