Subject: [nfsv4] Path forward for flex-files

From: David Noveck <[email-masked]>
Date: Sat, 5 Aug 2017 09:18:50 -0400

I've been holding off on doing a detailed review of flex-files-12 since Tom
has previously indicated there would be -13.

I've been following the discussion of the details of loose-coupling
security, but my lack of understanding of Kerberos meant
that most of the discussion went over my head.  However, I think it is
pretty clear that if Olga doesn't think the approach in -12
will work and Tom agrees, then it won't work and I'm glad we are moving
on.  I don't think that the deletion of RPCSEC_GSS
support for loose-coupling will be an issue for the IESG, since there is
support for this when used with tight couplling.

I'd like to see this document and layout-types go forward in the near
future and my initial comments will focused on making
sure that that happens.  Later I'll discuss the issues with regard to the
future work that Tom is thinking about.

As I understand things, -13 will include the changes that Chuck has
suggested to tie this document more closely to layout-types
and I think that's a good thing. When that change is made, it will need to
address the fact that these two documents define the
term "control protocol" differently, although there probably aren't
differences in actual usage to address.

As far as I am concerned, there is no need for another WGLC cycle for
layout-types-06, although Chuck (or others) might feel differently.

If we consider the longer-term perspective including the work Tom has
discussed, it seems to be that we have to decide on
how to divide the following items into RFCs:

   1. The definition of the XDR for the initial flex-files layout type
   (currently FLEX_FILES but I think FLEX_FILES_v1 should be considered) along
   with registration request for it.
   2. The registration request for the follow-on layout type, FLEX_FILES_v2
   (I briefly considered FLEXIER_FILES but somhow, sanity returned :-).  This
   one would not have an explicit RFC # but I believe that there is a way
   around that to create some sort of early registration with an RFC to be
   named later.
   3. The XDR corresponding to the follow-on layout type.
   4. The framework allowing co-operation between MDS and client to
   implement RPCSEC_GSS for loose coupling.  I expect this would allow use of
   RPCSEC_GSSV3 but see no need to say  so explicitly.
   5. The actual coordination scheme that Tom wants to standardize.

If this organization of the work does not make sense or is missing
something, please let me know.

I anticipate that the initial flex-files RFC would include 1) and 2).

The reasons that I don't want to include 3) are:

   - 3) doesn't make much sense without 4) and adding 4) would push the RFC
   off a while.
   - There's a small possibility further XDR issues will arise so we might
   as well avoid committing to a specific XDR until we have to.

It might make sense to do 3), 4) and 5) together but Tom might want to
divide these into multiple RFCs.

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 7 Aug 2017 16:27:49 +0000

On Aug 5, 2017, at 6:18 AM, David Noveck <[email-masked]<mailto:[email-masked]>> wrote:

I've been holding off on doing a detailed review of flex-files-12 since Tom has previously indicated there would be -13.

I've been following the discussion of the details of loose-coupling security, but my lack of understanding of Kerberos meant
that most of the discussion went over my head.  However, I think it is pretty clear that if Olga doesn't think the approach in -12
will work and Tom agrees, then it won't work and I'm glad we are moving on.  I don't think that the deletion of RPCSEC_GSS
support for loose-coupling will be an issue for the IESG, since there is support for this when used with tight couplling.

I'd like to see this document and layout-types go forward in the near future and my initial comments will focused on making
sure that that happens.  Later I'll discuss the issues with regard to the future work that Tom is thinking about.

As I understand things, -13 will include the changes that Chuck has suggested to tie this document more closely to layout-types
and I think that's a good thing. When that change is made, it will need to address the fact that these two documents define the
term "control protocol" differently, although there probably aren't differences in actual usage to address.

I was in the middle of making the changes on Friday, I’ll continue today and post a v13 soon.

As far as I am concerned, there is no need for another WGLC cycle for layout-types-06, although Chuck (or others) might feel differently.

If we consider the longer-term perspective including the work Tom has discussed, it seems to be that we have to decide on
how to divide the following items into RFCs:

  1.  The definition of the XDR for the initial flex-files layout type (currently FLEX_FILES but I think FLEX_FILES_v1 should be considered) along with registration request for it.
  2.  The registration request for the follow-on layout type, FLEX_FILES_v2 (I briefly considered FLEXIER_FILES but somhow, sanity returned :-).  This one would not have an explicit RFC # but I believe that there is a way around that to create some sort of early registration with an RFC to be named later.

Actually, all we have to do is decide as a WG to not register the number for any other layout type.

We’ve already done this by assigning 5 to the Christoph’s document and skipping 4 for this one.

  1.  The XDR corresponding to the follow-on layout type.
  2.  The framework allowing co-operation between MDS and client to implement RPCSEC_GSS for loose coupling.  I expect this would allow use of RPCSEC_GSSV3 but see no need to say  so explicitly.
  3.  The actual coordination scheme that Tom wants to standardize.

If this organization of the work does not make sense or is missing something, please let me know.

I’m fine with that and we can have a personal draft for the second document
soon - I am envisioning a very small and focused document.

And this can be a good candidate for the WG milestones. :-)

  *   3) doesn't make much sense without 4) and adding 4) would push the RFC off a while.
  *   There's a small possibility further XDR issues will arise so we might as well avoid committing to a specific XDR until we have to.

It might make sense to do 3), 4) and 5) together but Tom might want to divide these into multiple RFCs.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 7 Aug 2017 18:52:30 -0500

> on.  I don't think that the deletion of RPCSEC_GSS

I also agree with Olga and Tom -- there just isn't the proper (opaque)
hole in which to stuff the needed data, and the XDR is already in the wild.

If one was super-desparate, one could imagine running a separate service
on the MDS that maintained a database of synthetic uid/gid against the
GSS entity that's authorized to access that file, and issues the synthetic
GSS credentials.  But that doesn't really help us here, since there would
need to be a whole separate protocol specified for this separate service,
all entities would need to know it's in use, etc..  It doesn't seem worth
trying to graft properl RPCSEC_GSS support onto flex-files within the
constraints of the current XDR; I'm sorry I didn't notice that in my
earlier review, and thanks to Olga for pointing it out.

>    (I briefly considered FLEXIER_FILES but somhow, sanity returned :-).  This

Can I suggest putting in a typed opaque auth blob instead of explicit
synthetic uid/gid fields?  Then if someone actually wants to implement
one of these crazy loosely-coupled RPCSEC_GSS schemes (Rick's seems like
it would work fine, and I had a couple as well), they can write a spec
and allocate a new type to use for it.

>    RPCSEC_GSSV3 but see no need to say  so explicitly.

Er, right, that.

> divide these into multiple RFCs.

I have no particular preference on that.

-Ben