Re: [nfsv4] Minorversioning [was Re: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt]

[David Noveck <[e-mail]>]

> As I understand RFC8178, this would fall into Section 6. The client would
have to present LAYOUTAUTH > to the mds and hence Section 6.

That's right.

I don't think RFC 8178 specifically addresses the matter but my expectation
was always that extensions  to the base protocol would be done in teir own
standards-track documents.  In this case, your layout specification would
normatively reference the extension.


On Wed, Aug 16, 2017 at 5:21 PM, Thomas Haynes <[e-mail]>
wrote:

>
> On Aug 9, 2017, at 12:17 PM, Trond Myklebust <[e-mail]> wrote:
>
> An alternative that might be worth exploring is to have the LAYOUTGET
> return a stateid representing the credential to use, and then add a
> separate LAYOUTAUTH call to convert the stateid into something that could
> be used to set up the RPCSEC_GSS session to the DS.
> The reason why that might be interesting is that it could allow the client
> to reuse an existing RPCSEC_GSS session if one is already available.
> It might also allow the client to share information such as supported
> encryption types, etc as extra arguments to the LAYOUTAUTH call.
>
>
> I had also been thinking about a LAYOUTAUTH type of procedure. I didn’t
> want to build a handshake into
> RPC-application-defined structured privilege assertion in RPCSEC_GSSv3.
>
> As I understand RFC8178, this would fall into Section 6. The client would
> have to present LAYOUTAUTH to the mds and hence Section 6.
>
> I’d like clarity on that before proposing a new op. :-)
>