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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 16 Feb 2020 13:49:47 -0800

É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.

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 ?

-- 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.

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 17 Feb 2020 10:27:18 -0500

Hello Éric -

Thanks for your comments! More responses below.

> On Feb 16, 2020, at 4:49 PM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

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

> Just by sheer curiosity, I wonder where the value "0xf6ab0e18" comes from ?

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

> 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.

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 17 Feb 2020 21:37:21 +0000

Chuck

Thank you for your reply. 

For naming the bits in a flags field, here are some examples:
- RFC 8200 section 4.5
- RFC 4861 section 4.2
- ...

It really makes the text more readable but as written before, this is a non-blocking COMMENT only there to improve the clarity of the text.

-éric

PS: thank you for finding the É on your keyboard ;-)

On 17/02/2020, 16:27, "Chuck Lever" <[email-masked]> wrote:

    Hello Éric -

    

    

    

    

    --
    Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 18 Feb 2020 10:23:09 -0500

Hi Éric-

> On Feb 17, 2020, at 4:37 PM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Chuck
> 

As discussed, Sections 4 and 5 are reorganized, and the Flags field is split
into a 7-bit Reserved field and a 1-bit R field. It's definitely an improvement!

> PS: thank you for finding the É on your keyboard ;-)

No problem!

--
Chuck Lever