[nfsv4] Path forward for flex-files

[David Noveck <[e-mail]>]

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.