update the Volume Identification section

Be more specific about the identifiers.

From David Black, with updates from me to list all the different places
to retrieve the identifiers and to avoid the 'NVMe device' term.

diff --git a/scsi_nvme_back_references.xml b/scsi_nvme_back_references.xml
index d6fbea806a7dee6c2ce0d7ce56ff4a855eb84d99..3bbfe93a1011c598695e68e68618b1a95f9e1512 100644 (file)
--- a/scsi_nvme_back_references.xml
+++ b/scsi_nvme_back_references.xml
@@ -126,14 +126,4 @@
     <seriesInfo name='RFC' value='8446'/>
     <seriesInfo name='DOI' value='10.17487/RFC8446'/>
   </reference>
-
-  <reference anchor='NVME-STLR'>
-    <front>
-      <title>NVM Express: SCSI Translation Reference Revision 1.5</title>
-      <author>
-         <organization>NVM Express, Inc.</organization>
-      </author>
-      <date month="June" year="2015"/>
-    </front>
-  </reference>
 </references>

diff --git a/scsi_nvme_middle.xml b/scsi_nvme_middle.xml
index ff861fc2684e93734d664f5bab53a3fcf1681acc..839b8f065440ed274fac310fd308194b796f0495 100644 (file)
--- a/scsi_nvme_middle.xml
+++ b/scsi_nvme_middle.xml
@@ -76,20 +76,24 @@
     <t>
       The pNFS SCSI layout uses the Device Identification VPD page (page code
       0x83) from <xref target="SPC5" /> to identify the devices used by
-      a layout. Implementation using NVMe device shall use a mapping from
-      NVMe identifier to the SPC Device Identification VPD page that is
-      compatible to that defined in Section 6.1.4 of
-      <xref target="NVME-STLR" />.
+      a layout. Implementations that use NVMe namespaces as storage devices
+      map NVMe namespace identifiers to a subset of the identifiers
+      that the Device Identification VPD page supports for SCSI logical
+      units.
     </t>
 
     <t>
       To be used as storage devices for the pNFS SCSI layout, NVMe namespaces 
-      MUST support either the EUI64 or NGUID value in the Identify Namespace
-      data, as the methods based on the Serial Number are not be suitable for
-      unique addressing needs and thus MUST NOT be used.
-      If available, the NGUID value SHOULD be used as it is the larger
-      identifier.
-      <!-- XXX also allow the Identifier descriptors -->
+      MUST support either the EUI64 or NGUID value reported in an Namespace
+      Identification Descriptor, the I/O Command Set Independent Identify
+      Namespace Data Structure, and the Identify Namespace Data Structure,
+      NVM Command Set. If available, the NGUID value SHOULD be used as it is
+      the larger identifier.
+    </t>
+
+    <t>
+      Methods based on the Serial Number are not be suitable for unique
+      addressing needs and thus MUST NOT be used.
     </t>
 
     <t>
@@ -99,11 +103,20 @@
       <t>The "sbv_code_set" field SHALL be set to PS_CODE_SET_BINARY.</t>
       <t>The "pnfs_scsi_designator_type" field SHALL be set to
          PS_DESIGNATOR_EUI64.</t>
-      <t>The "sbv_designator" field shall contain either the NGUID or EUI64
-         fields from the Identify Namespace data.</t>
+      <t>The "sbv_designator" field SHALL contain either the NGUID or
+         the EUI64 identifier from NVMe Identify Namespace data.  If
+        both NGUID and EUI64 identifiers are available, then the NGUID
+        identifier SHOULD be used as it is the larger identifier.</t>
       <!-- XXX: add a reference to the persistent reservation section for
            sbv_pr_key -->
       </list>
+   
+      RFC 8154 specifies the "sbv_designator" field as an XDR variable length
+      opaque&lt;&gt;. The length of that XDR opaque&lt;&gt; value (part of
+      its XDR representation) indicates which NVMe identifier is present.
+      That length MUST be 16 octets for an NVMe NGUID identifier and
+      MUST be 8 octets for an NVMe EUI64 identifier.  All other lengths
+      MUST NOT be used with NVMe.
     </t>
   </section>