[nfsv4] Re: Late discovery in the delstid draft

[Rick Macklem <[e-mail]>]

On Thu, Oct 10, 2024 at 7:21 AM Thomas Haynes <[e-mail]> wrote:
>
> In reviewing the delstid draft, we discovered we had dropped two flags in the draft.
>
> I’m waiting for a window in the AUTH48 state to fix the draft, but the changes are:
>
>   When the server grants a delegation stateid, it MUST set either
>   OPEN_DELEGATE_READ_ATTRS_DELEG or OPEN_DELEGATE_WRITE_ATTRS_DELEG in
>   the open_delegation_type4 (see Section 18.16.1 of [RFC8881]) response
>   to indicate whether the client has been granted read or write
>   attribute support via the delegation.
>
>   /// enum open_delegation_type4 {
>   ///        OPEN_DELEGATE_NONE                  = 0,
>   ///        OPEN_DELEGATE_READ                  = 1,
>   ///        OPEN_DELEGATE_WRITE                 = 2,
>   ///        OPEN_DELEGATE_NONE_EXT              = 3, /* new to v4.1 */
>   ///        OPEN_DELEGATE_READ_ATTRS_DELEG      = 4,
>   ///        OPEN_DELEGATE_WRITE_ATTRS_DELEG     = 5
>   /// };
>
> Without this, the client does not know it has been granted the ability to cache the attrs.
Btw Tom, maybe I just missed it, but I cannot see anywhere in the
draft where it states
the new attributes are read-only or read-write. I think
FATTR4_OFFLINE, FATTR4_OPEN_ARGUMENTS
are read-only and FATTR4_TIME_DELEG_ACCESS, FATTR4_TIME_DELEG_MODIFY are
read-write (although only writable by the client holding the write delegation).
Is that correct?

Thanks, rick

>
> Does anyone have any issues with this wording?
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]