[nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-04: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 02 March 2020 04:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F09D93A0B1E; Sun, 1 Mar 2020 20:39:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, magnus.westerlund@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158312398995.32692.7127161053159044901@ietfa.amsl.com>
Date: Sun, 01 Mar 2020 20:39:49 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/rfIyrLkqw1aRvDCVFodbBYLxUxs>
Subject: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-04: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 04:39:52 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-nfsv4-rfc5661sesqui-msns-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661sesqui-msns/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.