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

[Chuck Lever <[e-mail]>]

Hello Éric -

Thanks for your comments! More responses below.


> On Feb 16, 2020, at 4:49 PM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke 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:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. I found this document not so
> easy to read as many acronyms are used without expansion (Stag, CM, ...)
> notably in the abstract. While the introduction simply refers to RFC 8166, a
> little more textual introduction would have been welcome.

The document assumes the reader is already knowledgeable about this specific
domain, true enough. I'm open to specific suggestions of what could be added
to the Introduction to assist readers less familiar with the topic. I'm never
sure how far back to start an Introduction section.

Barry Leiba has already pointed out several unexpanded acronyms that I have
corrected for the next revision. These include XDR, STag, RNIC, and the
reference to RDMA-CM in the Abstract.

Btw, here's what's been done to the document since -07:

https://chucklever.github.io/i-d-rpcrdma-cm-pvt-data/#go.draft-ietf-nfsv4-rpcrdma-cm-pvt-data.diff


> Nevertheless, please find below some non-blocking COMMENTs (and I would
> appreciate a response from the authors but this is not required).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 4 --
> Just by sheer curiosity, I wonder where the value "0xf6ab0e18" comes from ?

I used the center 32 bits of a randomly-generated uuid, iirc.


> -- Section 4.1.1 --
> "bit 15 of the Flags field" but the Flags field is only 8-bit long (to be
> honest, I am sure that I understand the meaning of this but being clearer would
> be better). Wording in section 5.1 should be used in section 4 when describing
> the Flags field.

> I would also suggest to name the different bits of the Flags field as usually
> done in other IETF documents.

Seeing an example or two would help me pick a name consistent with other IETF
publications. Please send one my way if you have a favorite.

If I define a name for the one flag used in Version 1, then Section 4.1.1 can
refer to that flag by name instead of "bit 15 of the Flags field".

Perhaps Section 5.1 should be moved to Section 4 as well.


> -- Section 5.1 --
> About the reserved bits, why not using the usual wording of "set to 0 when
> sending and ignored when received" ?

Barry also commented on this. See Section 5.1 in the pending revised draft
above for the corrected text.


--
Chuck Lever