Subject: Re: [nfsv4] Proposed language for NFSv4 minor version 2 draft

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 5 Jun 2012 14:20:09 +0000

On 5/30/12 12:26 PM, "David Quigley" <[email-masked]> wrote:

>On 05/30/2012 13:16, J. Bruce Fields wrote:
>> That makes sense to me.
>>
>> But this is starting to sound like a bigger change for this point in
>> the
>> process.
>>
>> And I still don't understand exactly what the labelled NFS folks
>> *need*:
>>
>> 	- Are these callbacks required, or just nice to have?  (Is it OK
>> 	  if a client doesn't notice a label change until its attribute
>> 	  cache times out, whenever that may be?)
>> 	- Why do "open files" get special mention in the requirements
>> 	  document?  Is timely notification less important for regular
>> 	  files that aren't open, or for objects other than regular
>> 	  files?
>>
>> If we leave 4.2 as it is, would it be good enough to have some use as
>> it
>> is, or are the incomplete notifications a show stopper?
>>
>> --b.
>>
>
>In our current implementation we have settled on it being ok if we
>don't get the label notification until the cached attribute times out.
>We don't see it being that big of an issue. If we want to provide a
>callback mechanism that is great because it provides less of a window
>where the label is consistent. As it stands right now its not a hard
>requirement for it being usable just icing on the cake.
>
>For opened/vs non opened files. I think that the wording is just a bit
>weird there. Files which we have label information for due to a lookup
>but aren't open are important as well. The problem is though that it
>will be hard to notify all clients of any given change to a file label.
>I think we settled just on open files for an efficiency standpoint.
>However I can see a situation where we lookup a and get its label. We
>make the local policy decision based on that label but it has changed on
>the server. If the server isn't enforcing a policy it will still allow
>us to go through even though the new label may have been denied. I
>believe this falls under the acceptable window comment above dealing
>with the cached attribute timeout.
>
>Dave

Peter had asked about whether we wanted to keep CB_ATTR_CHANGED generic or
only apply it to the security label. In the discussions, we've seen
utility to keeping it generic.

With that in mind, we need to decide between these two options:

1) Restrict CB_ATTR_CHANGED to only notify clients about security labels
changes in NFSv4.2 and open it up in NFSv4.3 to support other attributes.

2) Implement the proposed ATTR_WATCH in NFSv4.2. Note as this is state on
the server, we need a stateid, we need a way to recover it, etc. As Bruce
states, this is a bigger change. And this would be the work we would do in
1) for NFSv4.3.

Comments?