[nfsv4] AD Evaluation for draft-ietf-nfsv4-flex-files-14.txt

[Spencer Dawkins at IETF <[e-mail]>]

Hi, authors,

I apologize for not jumping on this draft when publication was requested -
it shows up with that status in the datatracker, but a quick search of my
e-mail archive doesn't show the corresponding notification e-mail to me.
But, having noticed that I should be reading it ...

I have some questions, which I'd like to work through before requesting
Last Call. Most are harmless, and a few are requirements language
questions, but I really need to understand the IANA Considerations section
note about Table 3.

Just administratively, I know that automatic I-D submissions are closed
until next Monday, and NFSv4 isn't meeting at IETF 100, so I'd expect to
wait until after IETF 100 to request Last Call (since we typically extend
Last Calls that overlap meeting weeks anyway). If the chairs would like for
me to handle this in another way, please let me know.

And thanks for your work on this.

Spencer (D)

--

I think

   This document does
   not provide a standard's track control protocol.

should be "standard track control protocol".

I think

   The requirements for the a
   control protocol are specified in [RFC5661] and clarified in
   [pNFSLayouts].

should either be "for a control protocol" or "for the control protocol",
but not both.

I don't understand what "need not be a protocol as normally understood" in

     control protocol:  is the particular mechanism that an implementation
      of a layout type would use to meet the control communication
      requirement for that layout type.  This need not be a protocol as
      normally understood.  In some cases the same protocol may be used
      as a control protocol and storage protocol.

means. You do expand the definition in the next sentence, but only
explaining something about a protocol as I understand protocols. Could you
also add an example of the kind of thing you're thinking of, as "not a
protocol"?

Is it possible to add a sentence or two in Section 2, that explains the
tradeoffs between loose and tight coupling? I understand there are two
alternatives (and the differences are described throughout the doc), but
don't understand at a high level how I'd decide which one to implement, if
I was starting from scratch.

I'm not a genius of "code in drafts", but shouldn't

  /// /*
   ///  * Copyright (c) 2012 IETF Trust and the persons identified
   ///  * as authors of the code. All rights reserved.
   ///  *

be 2017? The template in [LEGAL] is "insert current year" ...

I'm seeing major and minor version numbers, but I'm not seeing mention of
https://datatracker.ietf.org/doc/rfc8178/ -style extensions. Does that
matter? Or would support for extensions simply be detected in the way
described at the end of https://tools.ietf.org/html/rfc8178#section-4.3?

I'm fine with all of the SHOULDs and SHOULD NOTs in

  The client is free to use any of the network addresses as a
   destination to send storage device requests.  If some network
   addresses are less desirable paths to the data than others, then the
   MDS SHOULD NOT include those network addresses in ffda_netaddrs.  If
   less desirable network addresses exist to provide failover, the
   RECOMMENDED method to offer the addresses is to provide them in a
   replacement device-ID-to-device-address mapping, or a replacement
   device ID.  When a client finds no response from the storage device
   using all addresses available in ffda_netaddrs, it SHOULD send a
   GETDEVICEINFO to attempt to replace the existing device-ID-to-device-
   address mappings.  If the MDS detects that all network paths
   represented by ffda_netaddrs are unavailable, the MDS SHOULD send a
   CB_NOTIFY_DEVICEID (if the client has indicated it wants device ID
   notifications for changed device IDs) to change the device-ID-to-
   device-address mappings to the available addresses.  If the device ID
   itself will be replaced, the MDS SHOULD recall all layouts with the
   device ID, and thus force the client to get new layouts and device ID
   mappings via LAYOUTGET and GETDEVICEINFO.

except the last one. Can you help me understand why the MDS would not
recall all layouts and force clients to get new layouts and mappings?

Is it correct that there's no difference between the client's action when
receiving

  NFS4ERR_LAYOUTTRYLATER:  there is some issue preventing the layout
      from being granted.  If the client already has an appropriate
      layout, it should continue with I/O to the storage devices.

and

   NFS4ERR_DELAY:  there is some issue preventing the layout from being
      granted.  If the client already has an appropriate layout, it
      should not continue with I/O to the storage devices.

? That wouldn't surprise me, but I thought I should ask.

I think

  In [RFC5661], the file layout type is defined such that the
   relationship between multipathing and filehandles can result in
   either 0, 1, or N filehandles (see Section 13.3).  Some rationals for
   this are clustered servers which share the same filehandle or
   allowing for multiple read-only copies of the file on the same
   storage device.

should be "rationales".

Could you help me understand why

  The metadata server SHOULD recall any outstanding layouts to allow it
   exclusive write access to the stripes being recovered and to prevent
   other clients from hitting the same error condition.  In these cases,
   the server MUST complete recovery before handing out any new layouts
   to the affected byte ranges.

is not a MUST? ("Why wouldn't the MDS do that?")

Is "hot" a term of art for the NFS community? (If so, is there a reference
with a definition that could be included on first use?)

I'm really confused by

  Note, [RFC5661] should have also defined (see Table 3):

   +-------------------------------+------+-----------+-----+----------+
   | Recallable Object Type Name   | Valu | RFC       | How | Minor    |
   |                               | e    |           |     | Versions |
   +-------------------------------+------+-----------+-----+----------+
   | RCA4_TYPE_MASK_OTHER_LAYOUT_M | 12   | [RFC5661] | L   | 1        |
   | IN                            |      |           |     |          |
   | RCA4_TYPE_MASK_OTHER_LAYOUT_M | 15   | [RFC5661] | L   | 1        |
   | AX                            |      |           |     |          |
   +-------------------------------+------+-----------+-----+----------+

              Table 3: Recallable Object Type Assignments

As best I can tell,
https://www.iana.org/assignments/nfsv4-recallable-object-types/nfsv4-recallable-object-types.xhtml#nfsv4-recallable-object-types-1
defines them as

RCA4_TYPE_MASK_OBJ_LAYOUT_MIN 8 [RFC5661] L 1
RCA4_TYPE_MASK_OBJ_LAYOUT_MAX 9 [RFC5661] L 1

so, the values don't match. What am I missing? Is this a request to IANA to
change the assigned values, or something else?