Summary: Has a DISCUSS. Needs 7 more YES or NO OBJECTION positions to pass.
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?
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.
I agree with Barry’s DISCUSS.
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" ?