Skip to main content

Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08

Revision differences

Document history

Date Rev. By Action
2020-06-22
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-06-15
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-03-27
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-03-04
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-03-03
08 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-03-03
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-03-02
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-03-02
08 (System) RFC Editor state changed to EDIT
2020-03-02
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-03-02
08 (System) Announcement was received by RFC Editor
2020-03-02
08 (System) IANA Action state changed to In Progress
2020-03-02
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-03-02
08 Amy Vezza IESG has approved the document
2020-03-02
08 Amy Vezza Closed "Approve" ballot
2020-03-02
08 Amy Vezza Ballot approval text was generated
2020-03-02
08 Magnus Westerlund IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-02-23
08 Barry Leiba [Ballot comment]
Thanks for addressing my DISCUSS point and editorial comments.
2020-02-23
08 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2020-02-21
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-21
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-02-21
08 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08.txt
2020-02-21
08 (System) New version approved
2020-02-21
08 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2020-02-21
08 Chuck Lever Uploaded new revision
2020-02-21
08 Chuck Lever Uploaded new revision
2020-02-20
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-02-20
07 Yaron Sheffer Request for Telechat review by SECDIR Completed: Ready. Reviewer: Yaron Sheffer. Sent review to list.
2020-02-19
07 Suresh Krishnan
[Ballot 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 …
[Ballot 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.
2020-02-19
07 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2020-02-19
07 Suresh Krishnan
[Ballot 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 …
[Ballot 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.
2020-02-19
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-02-19
07 Benjamin Kaduk
[Ballot comment]
I agree with Alissa.

Section 4

  For RPC-over-RDMA version 1, the CM Private Data field is formatted
  as described in the …
[Ballot comment]
I agree with Alissa.

Section 4

  For RPC-over-RDMA version 1, the CM Private Data field is formatted
  as described in the following subsection.  RPC clients and servers
  use the same format.  If the capacity of the Private Data field is
  too small to contain this message format, the underlying RDMA
  transport is not managed by a Connection Manager, or the underlying
  RDMA transport uses Private Data for its own purposes, the CM Private
  Data field cannot be used on behalf of RPC-over-RDMA version 1.

How will an implementation know if "the underlying RDMA transport uses
Private Data for its own purposes"?

Section 5

  Although it is possible to reorganize the last three of the eight
  bytes in the existing format, extended formats are unlikely to do so.
  New formats would take the form of extensions of the format described
  in this document with added fields starting at byte eight of the
  format and changes to the definition of previously reserved flags.

I would suggest making it a (mandatory) invariant of this format to
retain these last three bytes' interpretation, requiring the use of a
different "magic word" for future versions that need to diverge from it.
The current text does not really give an implementation anything that it
can rely on.

Section 6

  The RPC-over-RDMA version 1 protocol framework depends on the
  semantics of the Reliable Connected (RC) queue pair (QP) type, as
  defined in Section 9.7.7 of [IBA].  The integrity of CM Private Data

It's interesting to see such a reference to [IBA], when IIUC the RFC
8166
protocol is not limited to Infiniband as the underlying transport.

  Additional analysis of RDMA transport security appears in the
  Security Considerations section of [RFC5042].  That document

nit: the actual analysis isn't *in* the security considerations section
(but is referenced from it).

  Improperly setting one of the fields in a version 1 Private Message
  can result in an increased risk of disconnection (i.e., self-imposed
  Denial of Service).  There is no additional risk of exposing upper-
  layer payloads after exchanging the Private Message format defined in
  the current document.

I'm not entirely sure where or how one might have expected such
additional exposures to occur.


We should probably mention the risk that some (other) CM-private data
item might inadvertenly produce in its payload the "magic number" that
we use to identify this protocol's data structure.  I *think* (but
please confirm) that erroneously doing so would lead only to (likely)
RDMA-channel disconnection and could not introduce (e.g.) data
corruption.

  In addition to describing the structure of a new format version, any
  document that extends the Private Data format described in the
  current document must discuss security considerations of new data
  items exchanged between connection peers.

In a similar vein, future extensions should consider what the risks of
erroneously identifying "random" data as the new format would be.

Section 7

Should the registry also include the length of the private data?

Similarly to the previous section's comments, should prospective
registrations also be analyzing the risks to their protocol of
interpreting "random" data as the data structure (as would happen upon
an inadvertent match of the "magic number")?

Section 7.1

  The new Reference field should contain a reference to that
  documentation.  The DE can assign new Format Identifiers at random as
  long as they do not conflict with existing entries in this registry.

Random may not be the best choice for this, if there are ways to produce
values that are less-likely-than-random to occur inadvertently in the
payload of any of the registered formats.
2020-02-19
07 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-02-19
07 Adam Roach
[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." …
[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.
2020-02-19
07 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-02-19
07 Alissa Cooper
[Ballot comment]
I'm not sure how strict we usually are about this, but the guidance in Section 7.1 makes it sound like the proper registration …
[Ballot comment]
I'm not sure how strict we usually are about this, but the guidance in Section 7.1 makes it sound like the proper registration policy is actually Specification Required, not Expert Review.
2020-02-19
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-02-19
07 Roman Danyliw
[Ballot comment]
Thanks for all of the changes made in response to the LC SECDIR review.  Also, thank you for the LC SECDIR review, Yaron …
[Ballot comment]
Thanks for all of the changes made in response to the LC SECDIR review.  Also, thank you for the LC SECDIR review, Yaron (Sheffer)!

Section 6.  As there is dependence on the behavior defined in [IBA], this reference should be normative.
2020-02-19
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-02-19
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-02-19
07 Mirja Kühlewind
[Ballot comment]
One quick thought/comment: Another option for extensibility would be to use one of the reserved flags to e.g. extend the fields of the …
[Ballot comment]
One quick thought/comment: Another option for extensibility would be to use one of the reserved flags to e.g. extend the fields of the private data field. However, the draft states at all reserved flags need to be zero with version 1. This seems to be a bit of a waste of space but moreover it's a lost opportunity for an easy way to extend the private data field. Why was that decided?
2020-02-19
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2020-02-16
07 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I found this document not so easy to read as many acronyms are used …
[Ballot 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" ?
2020-02-16
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-02-14
07 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-02-13
07 Alexey Melnikov [Ballot comment]
I agree with Barry’s DISCUSS.
2020-02-13
07 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2020-02-13
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2020-02-13
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2020-02-12
07 Barry Leiba
[Ballot discuss]
Thanks for this document.  This is a simple DISCUSS point that should be very easy to resolve:

— Section 5.2 —

  A …
[Ballot discuss]
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?
2020-02-12
07 Barry Leiba
[Ballot comment]
Some purely editorial comments:

— Abstract —
The abstract needs to stand alone, so you should expand the term RDMA-CM in the abstract.  …
[Ballot comment]
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.
2020-02-12
07 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2020-02-12
07 Magnus Westerlund IESG state changed to IESG Evaluation from Waiting for Writeup
2020-02-12
07 Amy Vezza Placed on agenda for telechat - 2020-02-20
2020-02-12
07 Magnus Westerlund Ballot has been issued
2020-02-12
07 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2020-02-12
07 Magnus Westerlund Created "Approve" ballot
2020-02-12
07 Magnus Westerlund Ballot writeup was changed
2020-02-10
07 Niclas Comstedt Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Niclas Comstedt.
2020-01-31
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-01-31
07 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07.txt
2020-01-31
07 (System) New version approved
2020-01-31
07 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2020-01-31
07 Chuck Lever Uploaded new revision
2020-01-31
07 Chuck Lever Uploaded new revision
2020-01-30
06 Jean Mahoney Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Suhas Nandakumar. Submission of review completed at an earlier date.
2020-01-27
06 Niclas Comstedt Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Niclas Comstedt. Sent review to list.
2020-01-27
06 Jean Mahoney Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Suhas Nandakumar.
2020-01-27
06 Suhas Nandakumar Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Suhas Nandakumar. Sent review to list.
2020-01-27
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-01-26
06 Yaron Sheffer Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list.
2020-01-24
06 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-01-24
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the RDMA-CM Private Data Identifier Registry. The new registry is to be created on the Remote Direct Data Placement (RDDP) registry page located at:

https://www.iana.org/assignments/rddp/

The new registry is to be managed via Expert Review as defined in RFC 8126. There is a single registration as an initial value in the new registry as follows:

+------------------+------------------------------------+-------------+
| Format | Format Description | Reference |
| Identifier | | |
+------------------+------------------------------------+-------------+
| 0xf6ab0e18 | RPC-over-RDMA version 1 CM Private |[ RFC-to-be ]|
| | Data | |
+------------------+------------------------------------+-------------+

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-01-19
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2020-01-19
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2020-01-19
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-01-19
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-01-16
06 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2020-01-16
06 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2020-01-13
06 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-01-13
06 Amy Vezza
The following Last Call announcement was sent out (ends 2020-01-27):

From: The IESG
To: IETF-Announce
CC: Spencer Shepler , magnus.westerlund@ericsson.com, Brian Pawlowski , beepee@gmail.com …
The following Last Call announcement was sent out (ends 2020-01-27):

From: The IESG
To: IETF-Announce
CC: Spencer Shepler , magnus.westerlund@ericsson.com, Brian Pawlowski , beepee@gmail.com, nfsv4-chairs@ietf.org, nfsv4@ietf.org, Thomas Haynes , draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'RDMA Connection Manager
Private Data For RPC-Over-RDMA Version 1'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-01-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the format of RDMA-CM Private Data exchanged
  between RPC-over-RDMA version 1 peers as part of establishing a
  connection.  The addition of the private data payload specified in
  this document is an optional extension that does not alter the RPC-
  over-RDMA version 1 protocol.  This document updates RFC 8166.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/ballot/


No IPR declarations have been submitted directly on this I-D.




2020-01-13
06 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-01-13
06 Magnus Westerlund Last call was requested
2020-01-13
06 Magnus Westerlund Ballot approval text was generated
2020-01-13
06 Magnus Westerlund Ballot writeup was generated
2020-01-13
06 Magnus Westerlund IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-01-13
06 Magnus Westerlund Last call announcement was generated
2020-01-02
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-02
06 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06.txt
2020-01-02
06 (System) New version approved
2020-01-02
06 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2020-01-02
06 Chuck Lever Uploaded new revision
2020-01-02
06 Chuck Lever Uploaded new revision
2020-01-02
05 Magnus Westerlund Waiting for one more set of changes to address Expert Review before IETF last call.
2020-01-02
05 Magnus Westerlund IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-11-15
05 Cindy Morgan New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-05.txt
2019-11-15
05 (System) Posted submission manually
2019-11-04
04 Magnus Westerlund Intended Status changed to Proposed Standard from Informational
2019-11-04
04 Magnus Westerlund IESG state changed to AD Evaluation from Publication Requested
2019-11-04
04 Magnus Westerlund Changed consensus to Yes from Unknown
2019-10-31
04 Spencer Shepler
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version …
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is a standards track document and represents an optional
extension to RPC-over-RDMA version 1 transport protocol [RFC8166].
It does not replace that document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
 
  This document specifies the format of RDMA-CM Private Data exchanged
  between RPC-over-RDMA version 1 peers as part of establishing a
  connection.  Such private data is used to indicate peer support for
  remote invalidation and larger-than-default inline thresholds.  The
  addition of the private data payload specified in this document is an
  OPTIONAL extension.  The RPC-over-RDMA version 1 protocol does not
  require the payload to be present.


Working Group Summary

  The working group was aligned on this work and it moved
  through the review process with good input but nothing contentious.


Document Quality

  This document represents input from the NFSv4 community with long
  standing experience.  The authors represent the quality work of the
  working group and are trusted in the community with their
  experience and abilty to draft quality, useful text. Key comments
  and reviewers included Christoph Hellwig and Devesh Sharma for suggesting
  this approach, and Tom Talpey and Dave Noveck for extensive review.
  All are experts in this technical area.

  This document reflects the experience of implementation and deployment
  in the Linux NFS client and server both support the message format specified
  in the document. Support was merged in fall of 2019 with Linux v4.9. Other
  implementations have expressed interest in adopting the work, including
  the support for Remote Invalidation


Personnel

  Brian Pawlowski is the document shepherd.
  Magnus Westerlund is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

As shepherd, I have read and reviewed the document as part of the
working group last call. I have discussed the document with the author, and
my co-chair and reaffirmed during our last WG meeting that there is continued
interest in completing the release of this specification.

This version of the document is ready for review by the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As shepherd, I have no concerns about the document and believe it is
needed and adds value to the overall NFSv4 RFC collection.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is required for this document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns for this document.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group is supportive of this document without exception. Affirmed
at last face-to-face meeting.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor copyright dates and minor issues will need to be updated.
These can be done during final edits, if required.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes to existing RFCs, RFC 8166 interoperability is described in
detail on how the extension co-exists with unmodified implementations.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA registry addition has been clearly identified and described by the
document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-10-31
04 Spencer Shepler Responsible AD changed to Magnus Westerlund
2019-10-31
04 Spencer Shepler IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-10-31
04 Spencer Shepler IESG state changed to Publication Requested from I-D Exists
2019-10-31
04 Spencer Shepler IESG process started in state Publication Requested
2019-10-31
04 Spencer Shepler Intended Status changed to Informational from None
2019-10-30
04 Brian Pawlowski
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version …
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is a standards track document and represents an optional
extension to RPC-over-RDMA version 1 transport protocol [RFC8166].
It does not replace that document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
 
  This document specifies the format of RDMA-CM Private Data exchanged
  between RPC-over-RDMA version 1 peers as part of establishing a
  connection.  Such private data is used to indicate peer support for
  remote invalidation and larger-than-default inline thresholds.  The
  addition of the private data payload specified in this document is an
  OPTIONAL extension.  The RPC-over-RDMA version 1 protocol does not
  require the payload to be present.


Working Group Summary

  The working group was aligned on this work and it moved
  through the review process with good input but nothing contentious.


Document Quality

  This document represents input from the NFSv4 community with long
  standing experience.  The authors represent the quality work of the
  working group and are trusted in the community with their
  experience and abilty to draft quality, useful text. Key comments
  and reviewers included Christoph Hellwig and Devesh Sharma for suggesting
  this approach, and Tom Talpey and Dave Noveck for extensive review.
  All are experts in this technical area.

  This document reflects the experience of implementation and deployment
  in the Linux NFS client and server both support the message format specified
  in the document. Support was merged in fall of 2019 with Linux v4.9. Other
  implementations have expressed interest in adopting the work, including
  the support for Remote Invalidation


Personnel

  Brian Pawlowski is the document shepherd.
  Magnus Westerlund is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

As shepherd, I have read and reviewed the document as part of the
working group last call. I have discussed the document with the author, and
my co-chair and reaffirmed during our last WG meeting that there is continued
interest in completing the release of this specification.

This version of the document is ready for review by the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As shepherd, I have no concerns about the document and believe it is
needed and adds value to the overall NFSv4 RFC collection.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is required for this document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns for this document.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group is supportive of this document without exception. Affirmed
at last face-to-face meeting.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor copyright dates and minor issues will need to be updated.
These can be done during final edits, if required.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes to existing RFCs, RFC 8166 interoperability is described in
detail on how the extension co-exists with unmodified implementations.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA registry addition has been clearly identified and described by the
document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-10-30
04 Brian Pawlowski
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version …
Working Group: NFSv4
Area Director: Magnus Westerlund
Document Author: Chuck Lever
Document Shepherd:  Brian Pawlowski

Internet Draft:

RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is a standards track document and represents an optional
extension to RPC-over-RDMA version 1 transport protocol [RFC8166].
It does not replace that document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
 
  This document specifies the format of RDMA-CM Private Data exchanged
  between RPC-over-RDMA version 1 peers as part of establishing a
  connection.  Such private data is used to indicate peer support for
  remote invalidation and larger-than-default inline thresholds.  The
  addition of the private data payload specified in this document is an
  OPTIONAL extension.  The RPC-over-RDMA version 1 protocol does not
  require the payload to be present.


Working Group Summary

  The working group was aligned on this work and it moved
  through the review process with good input but nothing contentious.


Document Quality

  This document represents input from the NFSv4 community with long
  standing experience.  The authors represent the quality work of the
  working group and are trusted in the community with their
  experience and abilty to draft quality, useful text. Key comments
  and reviewers included Christoph Hellwig and Devesh Sharma for suggesting
  this approach, and Tom Talpey and Dave Noveck for extensive review.
  All are experts in this technical area.

  This document reflects the experience of implementation and deployment
  in the Linux NFS client and server both support the message format specified
  in the document. Support was merged in fall of 2019 with Linux v4.9. Other
  implementations have expressed interest in adopting the work, including
  the support for Remote Invalidation


Personnel

  Brian Pawlowski is the document shepherd.
  Magnus Westerlund is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

As shepherd, I have read and reviewed the document as part of the
working group last call. I have discussed the document with the author, and
my co-chair and reaffirmed during our last WG meeting that there is continued
interest in completing the release of this specification.

This version of the document is ready for review by the IESG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

As shepherd, I have no concerns about the document and believe it is
needed and adds value to the overall NFSv4 RFC collection.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is required for this document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns for this document.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group is supportive of this document without exception. Affirmed
at last face-to-face meeting.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Minor copyright dates and minor issues will need to be updated.
These can be done during final edits, if required.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No changes to existing RFCs, RFC 8166 interoperability is described in
detail on how the extension co-exists with unmodified implementations.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA registry addition has been clearly identified and described by the
document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-10-02
04 Spencer Shepler
Notification list changed to Spencer Shepler <spencer.shepler@gmail.com>, Thomas Haynes <loghyr@gmail.com>, Brian Pawlowski <beepee@gmail.com> from Spencer Shepler <spencer.shepler@gmail.com>, …
Notification list changed to Spencer Shepler <spencer.shepler@gmail.com>, Thomas Haynes <loghyr@gmail.com>, Brian Pawlowski <beepee@gmail.com> from Spencer Shepler <spencer.shepler@gmail.com>, Thomas Haynes <loghyr@gmail.com>
2019-10-02
04 Spencer Shepler Document shepherd changed to Brian Pawlowski
2019-09-14
04 Spencer Shepler <spencer.shepler@gmail.com>, Thomas Haynes <loghyr@gmail.com> from Spencer Shepler <spencer.shepler@gmail.com>
2019-09-14
04 Spencer Shepler Document shepherd changed to Thomas Haynes
2019-07-17
04 Spencer Shepler Notification list changed to Spencer Shepler <spencer.shepler@gmail.com>
2019-07-17
04 Spencer Shepler Document shepherd changed to Spencer Shepler
2019-07-17
04 Spencer Shepler IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2019-06-13
04 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04.txt
2019-06-13
04 (System) New version approved
2019-06-13
04 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2019-06-13
04 Chuck Lever Uploaded new revision
2019-06-13
04 Chuck Lever Uploaded new revision
2019-06-13
03 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-03.txt
2019-06-13
03 (System) New version approved
2019-06-13
03 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2019-06-13
03 Chuck Lever Uploaded new revision
2019-06-13
03 Chuck Lever Uploaded new revision
2019-05-05
02 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt
2019-05-05
02 (System) New version approved
2019-05-05
02 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2019-05-05
02 Chuck Lever Uploaded new revision
2019-05-05
02 Chuck Lever Uploaded new revision
2018-11-06
01 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-01.txt
2018-11-06
01 (System) New version approved
2018-11-06
01 (System) Request for posting confirmation emailed to previous authors: Chuck Lever
2018-11-06
01 Chuck Lever Uploaded new revision
2018-07-25
00 Chuck Lever New version available: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-00.txt
2018-07-25
00 (System) WG -00 approved
2018-07-25
00 Chuck Lever Set submitter to "Charles Lever ", replaces to (none) and sent approval email to group chairs: nfsv4-chairs@ietf.org
2018-07-25
00 Chuck Lever Uploaded new revision