[nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with DISCUSS and COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Thu, 13 February 2020 05:45 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 F35DE12007A; Wed, 12 Feb 2020 21:45:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org, Thomas Haynes <loghyr@gmail.com>, Spencer Shepler <spencer.shepler@gmail.com>, Brian Pawlowski <beepee@gmail.com>, nfsv4-chairs@ietf.org, beepee@gmail.com, nfsv4@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <158157273498.18108.1561637139623742133.idtracker@ietfa.amsl.com>
Date: Wed, 12 Feb 2020 21:45:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/FJ9zWlRb3XlP-d2m41_OD92a-J8>
Subject: [nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with DISCUSS and 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: Thu, 13 Feb 2020 05:45:35 -0000
Barry Leiba has entered the following ballot position for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: Discuss 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-rpcrdma-cm-pvt-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. This is a simple DISCUSS point that should be very easy to resolve: — Section 5.2 — A sender computes the encoded value by dividing the buffer size, in octets, by 1024 and subtracting one from the result. Is the buffer size necessarily a multiple of 1024? If so, where is that specified? If not, what is the encoded value when the buffer size is, say, 2000? Is it zero? Or one? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some purely editorial comments: — Abstract — The abstract needs to stand alone, so you should expand the term RDMA-CM in the abstract. (RPC doesn’t need expanding, so once you’ve expanded RDMA-CM, RPC-over-RDMA should be OK.) — Introduction — Please expand “XDR” on first use. Section 7 of the current document “of this document” is better, I think. — Section 3.2 — Please expand “RNIC” and “STag”. invalidation without the need for additional protocol to be defined. Either “an additional protocol” or “additional protocols”. — Section 4.1 — Realizing these goals require that implementations of this extension follow the practices The subject is “realizing”, which is singular. So, “requires’. — Section 5.1 — Bits 14 - 8: These bits are reserved and are always zero when the Version field contains 1. In other protocols, leaving it unspecified as to what happens if not all reserved bits are zero has caused interoperability problems. If you know that’s not a concern here, that’s fine. Otherwise, it might be good to say explicitly that either they are ignored on receipt or non-zero bits result in an error.
- [nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4… Barry Leiba via Datatracker
- Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-n… Chuck Lever
- Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-n… Barry Leiba
- Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-n… Chuck Lever
- Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-n… Chuck Lever
- Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-n… Barry Leiba