Re: [nfsv4] feedback on draft-ietf-nfsv4-versioning-07

[Mike Kupfer <[e-mail]>]

David Noveck <[e-mail]> writes:

> l've looked at how bit flags are dealt with in -07 and believe that enum
> extensions can be dealt with similarly.

Okay.

>    - There is no discussion of adding bit flags in existing responses.
>    Instead, it should be made explicit that doing this would require a new
>    minor version.

Okay.

>    - There is no explicit discussion of the fact that, for these additions,
>    the interest cannot be distinguish between an unknown bit flag and one
>    which is known but unsupported.  This can have implication for how the
>    client and server decide on a common XDR variant.  I'd hope that this issue
>    can treated in a way that allows a future minor version to better address
>    the issue by  reorganizing error codes.  My preference would be for
>    preservng NFS4ERR_INVAL as indicating an unknown bit/enum, while allowing
>    future versions to address unsupported stuff in a way analogous that Tom
>    did for switches in v4.2, i.e. by creating NFS4ERR_FLAGBIT_NOTSUPP and
>    NFS4ERR_ENUMVAL_NOTSUPP.

Adding new "notsupp" error values sounds reasonable to me.

I'm less enthusiastic about using NFS4ERR_INVAL to mean either "unknown
enum/flag" or "understood but invalid request".  We discussed this back
in June, and I accept the argument for minor version 2 that allowing
either meaning matches current server behavior.  And it's probably
manageable as long as sufficient attention is given in an extension
specification to how the requester determines that the extension is
supported.  But in the long run, I still think it would be cleaner to
split those two meanings for NFS4ERR_INVAL into separate error codes.

mike