Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt

[Thomas Haynes <[e-mail]>]

> On Aug 29, 2017, at 4:33 PM, Black, David <[e-mail]> wrote:
> 
> Hi Tom,
> 
> Following up on this one item, as everything else in your email is fine with me:
> 
>>> -- Section 3.1 item (2)
>>> 
>>> It might be helpful to add a sentence or two to state that these layout
>> revocation requirements do not apply to layout recall, where the client's
>> cooperative participation is expected (with layout revocation available as a
>> fallback if the client does not cooperate).
>> 
>> 
>> Currently:
>> 
>>          The metadata
>>          server typically would revoke a layout whenever a client fails
>>          to respond to a recall or a client's lease is expired due to
>>          non-renewal.
>> 
>> Is it too subtle?
>> 
>> And remember we did define both revoking and recalling a layout in Section
>> 2.
> 
> Yup - I wrote too much in my comment - "requirements do not apply to layout recall" is the only thing that's not obvious.
> 
> I'd suggest adding one more sentence as a separate paragraph at the end of item (2):
> 
> 	In contrast, there is no requirement to restrict access to a file
> 	on the storage devices when a layout is recalled.
> 
> Thanks, --David
> 

Okay, that took a little bit of thinking to realize that the key point here was the last word.

I think this is a little bit of domain expertise in that I am assuming the reader is aware
that a recall turns into a revocation goes bad.

I have added the following additional paragraph:

          In contrast, there is no requirement to restrict access to a file
          on the storage devices when a layout is recalled.  It is only
          after the metadata server determines that the client is
          not gracefully returning the layout and starts the revocation
          that this requirement is enforced.