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

[Suresh Krishnan <[e-mail]>]

Hi Ben,

> On Feb 19, 2020, at 11:05 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Wed, Feb 19, 2020 at 07:14:49PM -0800, Suresh Krishnan via Datatracker wrote:
>> 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.
> 
> 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.)

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