Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-rfc5661sesqui-msns-04

I conducted this review in the spirit of draft-roach-bis-documents-00 and the significant security caveats enumerated in Appendix C.  A big thanks to Sean Turner for his SECDIR reviews and the authors for incorporating this feedback where appropriate.

** Section 1.1.  The motivation for the editorial approach taken in this document is cited as being in [I.D-roach-bis-documents] but there is not such reference in the document.

** The SECDIR review asked about retaining id-sha1 in Section 14.3.  The WG was going to be consulted.  What was the resolution?  In the spirit of this focused review, keeping it REQUIRED doesn’t present an issue, IMO.  However, would there be a reduced set of algorithms that could be RECOMMENDED in the Security Considerations?

** Section 21, Per “When DNS is used to convert server names to addresses and DNSSEC [29] is not available, the validity of the network addresses returned cannot be relied upon.”, this concern about the fidelity of the DNS information is a helpful consideration.  It would be worth mentioning/recommending the use of other DNS technologies such as DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] that could provide additional/alternatives confidence mechanisms in the DNS data.

Kerphew!

Thanks for the work put into this revision, and especially for the
work that went into creating a minimal set of changes to the predecessor
document, and for the careful documentation of the changes and their
rationale. This is a model update document.

I have only editorial comments on the document.

---------------------------------------------------------------------------

Abstract:

>  This document obsoletes RFC5661.  It substantialy revises the
>  treatment of features relating to multi-server namesapce superseding
>  the description of those features appearing in RFC5661.

Nit: "RFC 5661" (see RFC 7322 §3.5)

---------------------------------------------------------------------------

§1.1:

>  description of the NFS 4.1 protocol previously defined in RFC5661

Nit: "RFC 5661"

>  [62].  RFC5661 is obsoleted by this document.  However, the update

Nit: "RFC 5661"

>  o  Work would have to be done with regard to RFC8178 [63] which

Nit: "RFC 8178"

>     establishes NFSv4-wide versioning rules.  As RFC5661 is curretly

Nit: "RFC 5661"

>     arrive at a situation in which there would be no need for RFC8178

Nit: "RFC 8178"

>  o  Work would have to be done with regard to RFC8434 [66], which

Nit: "RFC 8434"

>     clearly defined in RFC5661.  When that work is done and the

Nit: "RFC 5661"

---------------------------------------------------------------------------

§11.1.1:

>     Despite the support for trunking detection there was no
>     description of trunking discovery provided in RFC5661 [62], making
>     it necessary to provide those means in this document.

Nit: "RFC 5661"

>  Two network addresses connected to the same server are said to be
>  server-trunkable.  Two such addresses support the use of clientid ID
>  trunking, as described in Section 2.10.5.

Nit: "client ID trunking"

---------------------------------------------------------------------------

§11.1.1:

>  Note that two addresses may be server-
>  trunkable without being session-trunkable and that when two
>  connections of different connection types are made to the same
>  network address and are based on a single file system location entry
>  they are always session-trunkable, independent of the connection
>  type, as specified by Section 2.10.5, since their derivation from the
>  same file system location entry together with the identity of their
>  network addresses assures that both connections are to the same
>  server and will return server-owner information allowing session
>  trunking to be used.

This is a long and complex sentence, and is difficult to understand. Consider
breaking up into several smaller sentences.

---------------------------------------------------------------------------

§11.1.2:

>  Discussion of the term "replica" is complicated by the fact that the
>  term was used in RFC5661 [62], with a meaning different from that in

Nit: "RFC 5661"

---------------------------------------------------------------------------

§22.1:

>  This update does not require any modification of or additions to
>  registry entries or registry rules associated with NFSv4.1.  However,
>  since this document is intended to obsolete RFC5661, it will be

Nit: "RFC 5661"

---------------------------------------------------------------------------

Appendix A:

>  As a result of the following problems in RFC5661 [62], it is

Nit: "RFC 5661"

>  o  RFC5661 [62], while it dealt with situations in which various

Nit: "RFC 5661"

>     Migration was first explained cearly in RFC7530 [64] and corrected

Nit: "early... RFC 7530"

>     and clarified by RFC7931 [65].  No correesponding explanation for

Nit: "RFC 7931"

>     simultaneously in RFC5661 [62] was not clear as it covered the two

Nit: "RFC 5661"

>  presenting in Section 11 a replacement for Section 11 within RFC5661

Nit: "RFC 5661"

>  In addition, there are also updates to other sections of RFC5661

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.1:

>  replacing existing sub-sections within section 11 of RFC5661 [62]:

Nit: "RFC 5661"

>     replaces the existing material in RFC5661 [62] ranging from the

Nit: "RFC 5661"

>     Sections 11.4 and 11.5 (of RFC5661 [62]) is necessary.  The

Nit: "RFC 5661"

>  o  A major replacement for the existing Section 11.7 of RFC5661 [62]

Nit: "RFC 5661"

>  o  A replacement for the existing Section 11.10 of RFC5661 [62]

Nit: "RFC 5661"

>     addressed in RFC5661 [62] where the concepts of a replica and a

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.1.1:

>  in a separate Section 11.5 of RFC5661 [62].  Because of the new

Nit: "RFC 5661"

>  As a result, Section 11.5 which will replace Section 11.4 of RFC5661

Nit: "RFC 5661"

>     the material in Section 11.4 of RFC5661 [62] exclusive of

Nit: "RFC 5661"

>     11.4.3 of RFC5661 [62].  11.4.4, and 11.4.5.

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.1.2:

>  in Section 11.7 of RFC5661 [62] has been reorganized and augmented as

Nit: "RFC 5661"

>     transitions while the bulk of the former Section 11.7 (in RFC5661

Nit: "RFC 5661"

>  As part of this general re-organization, Section 11.7 of RFC5661 [62]

Nit: "RFC 5661"

>  o  Sections 11.7 and 11.7.1 of RFC5661 [62] are to be replaced by

Nit: "RFC 5661"

>  o  Section 11.7.2 (and included subsections) of RFC5661 [62] are to

Nit: "RFC 5661"

>  o  Sections 11.7.3, 11.7.4. 11.7.5, 11.7.5.1, and 11.7.6 of RFC5661

Nit: "RFC 5661"

>  o  Section 11.7.7 of RFC5661 [62] is to be replaced by

Nit: "RFC 5661"

>  o  Sections 11.7.8, 11.7.9. and 11.7.10 of RFC5661 [62] are to be

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.1.3:

>  Section 11.10 of RFC5661 [62]) does not clearly distinguish these

Nit: "RFC 5661"

>     in effect at the time RFC5661 [62] was written, and needed to be

Nit: "RFC 5661"

>     RFC8178 [63].

Nit: "RFC 8178"

----------------------------------------------------------------------

§B.2:

>  o  The existing treatment of EXCHANGE_ID (in Section 18.35 of RFC5661

Nit: "RFC 5661"

>     RFC5661 [62]) is not sufficiently clear about the purpose and use

Nit: "RFC 5661"

>     differences between it and the treatment within RFC5661 [62] are

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.2.1:

>  (in RFC5661 [62]) that cause problems for Transparent State Migration

Nit: "RFC 5661"

>  intended to supersede the treatment in Section 18.35 of RFC5661 [62].

Nit: "RFC 5661"

>  RFC5661 [62].

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.2.2:

>  in RFC5661 [62] to arrive at the treatment in Section 18.51.

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.3:

>     issues, some uses of the term "replica" in RFC5661 [62] have

Nit: "RFC 5661"

>     RFC5661 [62]) needs to be updated to reflect the different

Nit: "RFC 5661"

>     of reclaim-related errors in Section 15 of RFC5661 [62], so the

Nit: "RFC 5661"

>     many other RFC5661 erratas, is addressed in this document because

Nit: "RFC 5661"

----------------------------------------------------------------------

§B.4:

>  o  The summary that appeared in Section 1.7.3.3 of RFC5661 [62] was

Nit: "RFC 5661"

>     RFC5661 [62] needed to be replaced, since the previous text

Nit: "RFC 5661"

>     RFC5661 [62] needed to be revised, to more clearly explain the

Nit: "RFC 5661"

----------------------------------------------------------------------

Appendix C:

>  o  The Security Considerations Section of RFC5661 [62] is not written

Nit: "RFC 5661"

>     in accord with RFC3552 [68] (also BCP72).  Of particular concern

Nit: "RFC 3552"

>     pervasive monitoring attacks such as those described in RFC7258

Nit: "RFC 7258"

>     type of protocol artifact alluded to in RFC7258, which can enable

Nit: "RFC 7258"

Thank you for this well written document.

I have a few nits to report:

The new section 1.1 should be spellchecked. (I given up reporting them.)

In 14.1.1:

   o  If NFS4ERR_DELAY is returned on an operation other than SEQUENCE	
 	      which validly appears as the first operation of a request,	
 	      handling is similar.  The request can be retired in full without	

s/retired/retried ?

 	      modification.

In 21:

   The use of the multi-server bamespace features described in

s/bamespace/namespace

   Section 11 raises the possibility that requests to determine the set
   of network addresses corresponding to a given server might be
   interfered with or have their responses modified in flight.  In light
   of this possibility, the following considerations should be taken
   note of:

Thank you for addressing my Discuss and Comment points!
[I did not exhaustively check all the comments but I think the updates generally look good.]

A few final remarks on the -04, which do not necessarily need any changes or response:

The RFC Editor is probably going to tweak a lot of commas, but perhaps
it's best to leave it to them and not try to churn things around more
ourselves.

Section 11.1.2

   o  File system location entries provide the individual file system
      locations within the file system location attributes.  Each such
      entry specifies a server, in the form of a host name or an
      address, and an fs name, which designates the location of the file
      system within the server's local namespace.  A file system
      location entry designates a set of server endpoints to which the
      client may establish connections.  There may be multiple endpoints
      because a host name may map to multiple network addresses and
      because multiple connection types may be used to communicate with
      a single network address.  However, except where an explicit port
      numbers are used to designate a set of server within a single
      server node, all such endpoints MUST designate a way of connecting
      to a single server.  The exact form of the location entry varies
      with the particular file system location attribute used, as
      described in Section 11.2.

I'm not entirely sure I understand what is being excluded in the
"designate a set of server [sic] within a single server node".

Section 11.5.4.1

   o  When the fs_locations_info attribute shows the two entries as not
      having the same simultaneous-use class, trunking is inhibited and
      the two access paths cannot be used together.
      In this case the two paths can be used serially with no transition
      activity required on the part of the client.  In this case, any

I expect that most readers will know what "used serially" means, so it
may not be necessary to clarify.