Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices
draft-ietf-nfsv4-scsi-layout-nvme-07

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-nfsv4-scsi-layout-nvme and RFC 9561, changed IESG state to RFC Published)

[Ballot comment]
I didn't understand much of this document, but I also didn't see any Ops Area concerns, so I'm balloting NoObj in the sense of:
"This is outside my area of expertise ", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs.
I read it, and I have no problem with it.

[Ballot comment]
Thank you for the work on this document.

Many thanks to James Gruessing for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Dg5O0z3P2i2aNneg9EYcfui9lHY/. Please consider James' point: I also agree that repeating in the security considerations normative statements from the SCSI layout document (RFC 8154), which is already normatively referenced, is not needed. Does the addition of "with an NVMe layout" (resp "on a NVMe namespace") make having these requirements necessary here, or would have the security considerations from 8154 covered it too?

[Ballot comment]
I support Roman's DISCUSS. Additionally,

        IEEE Extended Unique Identifier (EUI64) or Namespace Globally
        Unique Identifier (NGUID) value reported in a Namespace
        Identification Descriptor,

This needs a reference as it seems normative.

NITS:

        RFC 8154 specifies the

This RFC mention should be a real normative reference with link.

[Ballot comment]
Thanks for the work done.

Just a minor nit: writing the binary / hexadecimal numbers with a trailing "b" or "h" is rather confusing, e.g., "4h" does not mean 4 hours in section 2.2.2 :-)

Consider using 0x4

[Ballot discuss]
Section 3.

==[snip]==
When using IP-based storage protocols such as NVMe over TCP, data confidentiality and integrity SHOULD be provided for traffic between pNFS clients and NVMe storage devices by using a secure communication protocol such as Transport Layer Security (TLS) [RFC8446]. For NVMe over TCP, TLS SHOULD be used as described in [NVME-TCP] to protect traffic between pNFS clients and NVMe namespaces used as storage devices.
==[snip]==

Per “For NVMe over TCP, TLS SHOULD be used as described in [NVME-TCP] to protect traffic between pNFS clients and NVMe namespaces used as storage devices”, is this text saying that the use of TLS is not mandatory with NVMe over TCP or that conformance to the TLS profile in [NVME-TCP] is not mandatory if TLS is used?  If the former, see the follow-up below about TLS guidance in the NVME specs.  If the latter, what TLS profile should be used?

I’m having trouble reconciling the flexibility of NOT using TLS with NVMe over TCP when Section 3.6.1.6 of [NVME-TCP] says “All NVMe/TCP host and subsystem implementations shall be configurable to require that all NVMe/TCP connections use TLS”.  [NVME-TCP] covers TLS 1.3 guidance and references “NVME over Fabrics” (https://nvmexpress.org/wp-content/uploads/NVMe-over-Fabrics-1.1-2019.10.22-Ratified.pdf) for TLS 1.2 guidance.  In Section 7.4.9.2 of the “NVMe over Fabrics” document, this same strict requirement to use TLS is restated (same sentence in both documents).

[Ballot comment]
Thanks to Deb Cooley for the SECDIR review and Roni Even for the security focused GENART review.

** Section 3.

==[snip]==
When using IP-based storage protocols such as NVMe over TCP, data confidentiality and integrity SHOULD be provided for traffic between pNFS clients and NVMe storage devices by using a secure communication protocol such as Transport Layer Security (TLS) [RFC8446]. For NVMe over TCP, TLS SHOULD be used as described in [NVME-TCP] to protect traffic between pNFS clients and NVMe namespaces used as storage devices.
==[snip]==

The GENART and SECDIR reviews both mention this specific text.  My understanding of the first sentence is that confidentiality and integrity services SHOULD (not MUST) be provided to retain flexibility.  Is that accurate? I strongly recommend clarifying text to explain when it is not appropriate/necessary to provide these security services when IP-based storage is used.  See related DISCUSS.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-nfsv4-scsi-layout-nvme-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-11-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-nfsv4-scsi-layout-nvme@ietf.org, inacio@cert.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'Using the Parallel NFS (pNFS)
SCSI Layout to access NVMe storage
  devices'
  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 2023-11-01. 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 how to use the Parallel Network File System
  (pNFS) Small Computer System Interface (SCSI) Layout Type to access
  storage devices using the Non-Volatile Memory Express (NVMe) protocol
  family.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout-nvme/



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


The document contains following normative downward references:

  [NVME-BASE]
              NVM Express, Inc., "NVM Express Base Specification,
              Revision 2.0c", October 2022, .

  [NVME-NVM] NVM Express, Inc., "NVM Express NVM Command Set
              Specification, Revision 1.0c", October 2022,
              .

  [NVME-TCP] NVM Express, Inc., "NVM Express TCP Transport
              Specification, Revision 1.0c", October 2022,
              .

# Document Shepherd Write-Up for draft-ietf-nfsv4-scsi-layout-nvme-04
## Chris Inacio
## 31-Aug-2023


## Document History

### 1

The NFSv4 working group is relatively small, as such the answer to this
question is somewhat difficult.  In the shepherd's opinion, working group
consensus was sufficiently broad across the working group to progress this
document.

### 2

The only controversy about this draft was if IETF and NFSv4 was the right
forum and if this draft was in scope.  There are agreement within the WG and
with the AD that this is within scope.

### 3

No


### 4

Yes, 2 independent implementations have been created.  This is draft
presents an evolution of storage layouts as storage advances and should be
implemented more over time.

## Additional Reviews

### 5

The relevant technical experts to understand NVMe and SCSI are also members
of the NFSv4 working group.  This document uses NVMe and SCSI but only
extends the usage of NFSv4 to newer NVMe and SCSI protocol devices.

### 6

This draft does not include any topics that require formal expert review.

### 7

Not applicable.

### 8

Not applicable for this draft.

## Document Shepherd Checks

### 9

Yes.

### 10

This draft does not require special expert reviews.

### 11

This draft is proposed standard.  This draft supplements existing RFCs which
are on the standards track.

### 12

Yes.

### 13

Yes.

### 14

None remain.

### 15

No.

## 16

No, the "SCSI Primary Commands-5" is not freely available.  The community
appears to have sufficient access to review this, including some WG members
who are also on that SDO committee.

### 17

No, although this draft does reference RFC 8446 (TLS1.3) but the shepherd
does not believe that to be a true DOWNREF, although it is captured in the
DOWNREF registry.

### 18

No, all normative references are published.

### 19

No

### 20

This draft produces no IANA actions.

### 21

Not applicable.

# Document Shepherd Write-Up for draft-ietf-nfsv4-scsi-layout-nvme-04
## Chris Inacio
## 31-Aug-2023


## Document History

### 1

The NFSv4 working group is relatively small, as such the answer to this
question is somewhat difficult.  In the shepherd's opinion, working group
consensus was sufficiently broad across the working group to progress this
document.

### 2

The only controversy about this draft was if IETF and NFSv4 was the right
forum and if this draft was in scope.  There are agreement within the WG and
with the AD that this is within scope.

### 3

No


### 4

Yes, 2 independent implementations have been created.  This is draft
presents an evolution of storage layouts as storage advances and should be
implemented more over time.

## Additional Reviews

### 5

The relevant technical experts to understand NVMe and SCSI are also members
of the NFSv4 working group.  This document uses NVMe and SCSI but only
extends the usage of NFSv4 to newer NVMe and SCSI protocol devices.

### 6

This draft does not include any topics that require formal expert review.

### 7

Not applicable.

### 8

Not applicable for this draft.

## Document Shepherd Checks

### 9

Yes.

### 10

This draft does not require special expert reviews.

### 11

This draft is proposed standard.  This draft supplements existing RFCs which
are on the standards track.

### 12

Yes.

### 13

Yes.

### 14

None remain.

### 15

No.

## 16

No, the "SCSI Primary Commands-5" is not freely available.  The community
appears to have sufficient access to review this, including some WG members
who are also on that SDO committee.

### 17

No, although this draft does reference RFC 8446 (TLS1.3) but the shepherd
does not believe that to be a true DOWNREF, although it is captured in the
DOWNREF registry.

### 18

No, all normative references are published.

### 19

No

### 20

This draft produces no IANA actions.

### 21

Not applicable.