Re: [nfsv4] Path forward for flex-files

[Thomas Haynes <[e-mail]>]

On Aug 5, 2017, at 6:18 AM, David Noveck <[e-mail]<mailto:[e-mail]>> 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 anticipate that the initial flex-files RFC would include 1) and 2).

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. :-)



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.