Re: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-rfc3530bis-33

[Tom Haynes <[e-mail]>]

> On Nov 14, 2014, at 3:05 PM, Tom Haynes <[e-mail]> wrote:
> 
> Hi Elwyn,
> 
> Here is my first set of responses - there are still some open items.
> 
> Thanks,
> Tom
> 
>> On Nov 13, 2014, at 12:27 PM, Elwyn Davies <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi, Tom.
>> 
>> Some comments inline - I have deleted the various things that are agreed.
>> 
>> Regards,
>> E;lwyn
>> 
>> On 12/11/14 22:11, Tom Haynes wrote:
>>> Hi Elwyn,
>>> 
>>> Before I forget, thanks for the review.
>> .. and your prompt response. :-)
>>> 
>>> I have replied inline for the changes I have made or have a question on.
>>> 
>>> Tom
>>> 
>>>> On Nov 11, 2014, at 12:48 PM, Elwyn Davies <[e-mail] <mailto:[e-mail]>
>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
> 
> 
>>> 
>>>> 
>>>> s15.26.4/s15.26.5: What happens if the directory has been modified
>>>> (entries added or deleted) between calls of READDIR intended to
>>>> retrieve segments of the directory information?  Related to this,
>>>> presumably no ordering of entries is implied in the returned
>>>> information - it would be desirable to state this.
>>> 
>>> 
>>> This is where the cookieverf is supposed to come in.
>>> 
>>> In most implementations, the cookie needs to be persistent, which indeed
>>> means an ordering of the information.
>> 
>> AFAICS the text doesn't tie the cookieverf to the change attribute of the directory.  Presumably this is what is intended - it would certainly mean that changes would be picked up and READDIR would have to start from the beginning again.
>>> 
> 
> Asking an expert…

From Trond:

As far as I know, the cookieverf is about validating the cookies
themselves. There is no requirement in any of the descriptions in
RFC1813, RFC3530 or RFC5661 that states that the contents of the
directory need to change when the cookieverf does or vice-versa.
In theory, the server could throw out the cookies and regenerate them
on reboot, for instance.