Subject: [nfsv4] Suresh Krishnan's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 19:14:49 -0800

Suresh Krishnan has entered the following ballot position for
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: 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-rpcrdma-cm-pvt-data/

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

I would like to see a resolution of Barry's DISCUSS as well. In addition if you
are using division by 1024, I think the appropriate range needs to be
1KiB-256KiB instead of 1KB-256KB as defined in the draft.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Feb 2020 20:05:40 -0800

> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/

I'm not sure there's really much of an issue there; the stated procedure
(round-tripping through the encoding and decoding processes) seems to have
the effect of rounding down to the next multiple of 1024 bytes, which might
waste a little space but should produce safe operation.  Furthermore, it
can't reduce the buffer size below the current default value.

(That said, I don't object to the diff that was proposed in response to
Barry.)

-Ben

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 20 Feb 2020 04:42:33 +0000

Hi Ben,

> On Feb 19, 2020, at 11:05 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

> (That said, I don't object to the diff that was proposed in response to

The range of possible values is still off in the -07 draft but I checked the -latest diff posted by Chuck and it seems to have updated the range to read "1024 to 262144 octets” which matches my suggestion for 1KiB-256KiB. So consider me satisfied :-).

Regards
Suresh

---

From: Chuck Lever <[email-masked]>
Date: Thu, 20 Feb 2020 08:59:06 -0500

> On Feb 19, 2020, at 11:42 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Ben,
> 

Suresh, thanks for having a look at the Editor's copy, and thanks for your
comment! I was uncertain about exactly how to spell out the size range.

--
Chuck Lever