Internet Small Computer System Interface (iSCSI) SCSI Features Update
draft-ietf-storm-iscsi-sam-09

[Ballot comment]
I find the following text really confusing:

This document
is not a complete revision of [RFC3720]. Instead, this document
is intended as a companion document to [draft-ietf-storm-iscsi-
cons-xx]; this document may also be used as a companion document
to the combination of [RFC3720] and [RFC5048], although both of
those RFCs have been obsolete by [draft-ietf-storm-iscsi-cons-
xx].

.. and will be mostly redundant the day draft-ietf-storm-iscsi-cons
is published.

So given that this draft will wait in the RFC editor's queue until
draft-ietf-storm-iscsi-cons is an RFC, may I suggest that just say
that it is a companion to draft-ietf-storm-iscsi-cons, and put the
text about [RFC3720] and [RFC5048] in the to be deleted
editor's note?
===========

[Ballot comment]
The abstract and the introduction should say what is actually in the document and why this is a companion document (e.g. sections 4-7 are fine. the intro is just ambigious.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-storm-iscsi-sam-08.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have questions for the requested actions.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are six actions which IANA needs to complete.

First, in the iSCSI Task Management Function Codes subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

Four new Task Management Function Codes are added as follows:

TMF Code: 9
Description: QUERY TASK
Reference: [ RFC-to-be ]

TMF Code: 10
Description: QUERY TASK SET
Reference: [ RFC-to-be ]

TMF Code: 11
Description: I_T NEXUS RESET
Reference: [ RFC-to-be ]

TMF Code: 12
Description: QUERY ASYNCHRONOUS EVENT
Reference: [ RFC-to-be ]

Second, in the iSCSI Task Management Function Codes subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

the subregistry name is changed from "iSCSI Task Management Function Codes" to "iSCSI TMF Codes"

QUESTION: Since this document (section 9.1) requests to update the name
of the registry, should this document be cited as the second reference
for the registry?

Third, in the iSCSI Login/Text Keys subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

the name of the registry is changed from "iSCSI Login/Text Keys" to "iSCSI Text Keys"

QUESTION: Since this document (section 9.2) updates the name of
the registry, should this document be cited as the third reference
for the registry?

Fourth, in the iSCSI Text Keys subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

a single text key is added to the subregistry as follows:

Key: iSCSIProtocolLevel
Reference: [ RFC-to-be ]

Fifth, a new subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

is to be created. The new subregistry is to be named the "iSCSI Protocol Level" subregistry. The registry will be made up of values between 0 and 31 inclusive. The registration rule for the new subregistry is Standards Action and Expert Review as defined in RFC 5226. IANA understands that the assignments of these values must be coordinated with the INCITS T10 committee.

There are initial registrations in this new subregistry as follows:

Value Description Reference
-------+----------------------------+--------------------
0 No version claimed [ RFC-to-be ]
1 RFC-cons [ RFC-to-be ]
2 [ RFC-to-be ] [ RFC-to-be ]
3-31 Reserved [ RFC-to-be ]

QUESTIONS: Is the authors intention to use draft-ietf-storm-iscsi-sam
later RFC number as the Description for value 2?

Should values 3-31 be marked as "Unassigned" in the registry, rather
than "Reserved"?  Please see RFC5226.

Sixth, a new subregistry of the Internet Small Computer System Interface (iSCSI) Parameters registry located at:

http://www.iana.org/assignments/iscsi-parameters

is to be created. The new subregistry is to be named the "iSCSI Task Management Function Response Codes" subregistry. The registry will be made up of 8-bit values. The registration rule for the new subregistry is Standards Action as defined by RFC 5226.

There are initial values in the new subregistry as follows:

Value Operation Name Reference
--------+-------------------------------------------+-------------------------------
0x0 Function complete [RFC-ietf-storm-iscsi-cons-10]
0x0 Function complete [RFC-ietf-storm-iscsi-cons-10]
0x1 Task does not exist [RFC-ietf-storm-iscsi-cons-10]
0x2 LUN does not exist [RFC-ietf-storm-iscsi-cons-10]
0x3 Task still allegiant [RFC-ietf-storm-iscsi-cons-10]
0x4 Task allegiance reassignment not supported [RFC-ietf-storm-iscsi-cons-10]
0x5 Task management function not supported [RFC-ietf-storm-iscsi-cons-10]
0x6 Function authorization failed [RFC-ietf-storm-iscsi-cons-10]
0x7 Function succeeded [ RFC-to-be ]
0x08 - Reserved [ RFC-to-be ]
0x254
0x255 Function rejected [RFC-ietf-storm-iscsi-cons-10]

QUESTION: Should values 8-254 be marked as "Unassigned" in the registry,
rather than "Reserved"?  Please see RFC5226.

IANA understands that these six actions are the only ones 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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard


The IESG has received a request from the STORage Maintenance WG (storm)
to consider the following document:
- 'Internet Small Computer Systems Interface (iSCSI) SCSI Features
Update'
  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
ietf@ietf.org mailing lists by 2013-08-22. 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


  Internet Small Computer Systems Interface (iSCSI) is a SCSI
  transport protocol that maps the SCSI family of protocols onto
  TCP/IP. The iSCSI protocol as specified in RFCxxx (and as
  previously specified by the combination of RFC 3720 and RFC
  5048) is based on the SAM-2 (SCSI Architecture Model - 2)
  version of the SCSI family of protocols. This document
  defines enhancements to the iSCSI protocol to support certain
  additional features of the SCSI protocol that were defined in
  SAM-3, SAM-4, and SAM-5.

  This document is a companion document to RFCxxx.

    --------------------------------------------------------
    RFC EDITORS NOTE: The above two references to RFCxxx should
    reference the RFC number assigned to the draft-ietf-storm-
    iscsi-cons-xx document, and this note should be removed.
    --------------------------------------------------------




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/


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

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

David L. Black (david.black@emc.com) is the Document Shepherd.  The
Document Shepherd has reviewed this version of the document
and believes that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had sufficient review from key WG members, from implementers
who work on important iSCSI implementations (both initiator and target
implementations) outside the WG and from key members of INCITS Technical
Committee T10, the organization responsible for SCSI standards.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) 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 WG consensus behind this document is solid; the WG as a whole
understands this document and agrees with the need for these minor
updates.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

Yes. idnits 2.12.17 complained about some missing references, all of
which are covered by RFC Editor Notes in the document, and it also
flagged all references to SCSI standards as possible dowrefs (they aren't).

        Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

N/A.

  (1.h) Has the document split its references into normative and
        informative?

Yes.

        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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

This document normatively references draft-ietf-storm-iscsi-cons-xx,
which is in the RFC Editor's Queue.

In addition, this document normatively references three SCSI standards
that are developed by INCITS Technical Committee T10 (www.t10.org),
namely SAM2, SAM5 and SPC4.  As a completed standard, SAM2 is not a
publicly available document, because T10's parent standards
organizations fund their operations in part by charging for copies of
standards.  The document shepherd, David Black, is also the official
T10 Liaison to the IETF and in that role, he has been authorized by T10
to provide copies of these standards to IETF participants for their
personal use in IETF activities. If copies of SAM2 are desired, please
contact the document shepherd, David Black (david.black@emc.com).

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section has been checked - the text describing
the additions to existing registries and creation of one new registry
is clear.  The new registry does not use the Expert Review process.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) 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

  The Internet Small Computer Systems Interface (iSCSI) is a SCSI
  transport protocol that maps the SCSI family of protocols onto
  TCP/IP. The base iSCSI protocol is based on the SAM-2 (SCSI
  Architecture Model - 2) SCSI standard.  This document specifies
  enhancements to the iSCSI protocol to support certain additional
  SCSI features that have been defined in subsequent versions of
  the SCSI Architecture Model.

    Working Group Summary

  There was very little dissent in the WG over the functionality in this
  document.  Significant WG discussion was devoted to correctly specifying
  SCSI-related identifiers used by this draft.  Rob Elliott and Ralph
  Weber (key members of the T10 SCSI standards organization) provided
  significant assistance in working through the identifier issues.
 
  This document was returned to the WG after IESG evaluation primarily
  to deal with functionality negotiation concerns (iSCSIProtocolLevel key)
  and related IANA Considerations.    The WG has resolved those concerns.
 
    Document Quality

  iSCSI implementers from Dell, EMC, Microsoft, NetApp, RedHat and VMware
  have reviewed this document for quality and consistency with existing
  implementations.  The reviews indicate that the enhancements are clearly
  specified, and are not expected to be significantly disruptive to add to
  existing implementations.

IANA has reviewed draft-ietf-storm-iscsi-sam-06 and has the following comments:

IANA understands that, upon approval of this document, there are four actions that IANA must complete.

All of the actions required are changes or additions to the subregistries in the
Internet Small Computer System Interface (iSCSI) Parameters registries at:

http://www.iana.org/assignments/iscsi-parameters/iscsi-parameters.xml

First, in the iSCSI Task Management Function Codes subregistry, four new values
will be registered:

TMF Code: 9
Description: QUERY TASK
Reference: [ RFC-to-be ]

TMF Code: 10
Description: QUERY TASK SET
Reference: [ RFC-to-be ]

TMF Code: 11
Description: I_T NEXUS RESET
Reference: [ RFC-to-be ]

TMF Code: 12
Description: QUERY ASYNCHRONOUS EVENT
Reference: [ RFC-to-be ]

Second, in the iSCSI Login/Text Keys subregistry, one new value is to be
registered as follows:

Key: iSCSIProtocolLevel
Reference: [ RFC-to-be ]

Third, in the Internet Small Computer System Interface (iSCSI) Parameters
registries at:

http://www.iana.org/assignments/iscsi-parameters/iscsi-parameters.xml

a new subregistry is to be created called the "iSCSI Protocol Level"
subregistry. The registry will consist of numerical values from 0 to 31. The
assignment policy for the new subregistry requires a standards track document,
approved by the IESG and expert review by an expert maintaining an association
with the INCITS T10 committee.

Values, 0 and 2 are assigned by this document. Value 1 is assigned by another
Internet-Draft awaiting approval. The values 3 through 31 are available for
future assignment. There are initial registrations in this subregistry:

Value: 0
Reference: [ RFC-to-be ]

Value: 2
Reference: [ RFC-to-be ]

Fourth, also in the Internet Small Computer System Interface (iSCSI) Parameters
registries at:

http://www.iana.org/assignments/iscsi-parameters/iscsi-parameters.xml

a new subregistry is to be created called the "iSCSI TMF Response Codes"
registry. The registry will be made up of numerical values in the range of 0 to
255. This registry is maintained through standards action as defined in RFC 5226.

There are initial values in the registry:

Assigned Value Operation Name Reference
------------------=-------------------------------=---------------------
0x0 Function complete RFC3720
0x1 Task does not exist RFC3720
0x2 LUN does not exist RFC3720
0x3 Task still allegiant RFC3720
0x4 Task allegiance reassignment not supported RFC3720
0x5 Task management function not supported RFC3720
0x6 Function authorization failed RFC3720
0x7 Function succeeded [ RFC-to-be ]
0x8 - 0x254 Available
0x255 Function rejected RFC3720

IANA understands that these four actions are the only ones 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard


The IESG has received a request from the STORage Maintenance WG (storm)
to consider the following document:
- 'Internet Small Computer Systems Interface (iSCSI) SCSI Features
Update'
  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
ietf@ietf.org mailing lists by 2012-08-13. 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.

Please note the concurrent Last Call for draft-ietf-storm-iscsi-cons, as both
drafts should be reviewed together.

Abstract


  Internet Small Computer Systems Interface (iSCSI) is a SCSI
  transport protocol that maps the SCSI family of protocols onto
  TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm-
  iscsi-cons-xx] (and as previously specified by the combination
  of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI
  Architecture Model - 2) version of the SCSI family of
  protocols. This document defines enhancements to the iSCSI
  protocol to support certain additional features of the SCSI
  protocol that were defined in SAM-3, SAM-4, and SAM-5.

  This document is a companion document to [draft-ietf-storm-
  iscsi-cons-xx].

      --------------------------------------------------------
      RFC EDITORS NOTE: The above references to [draft-ietf-storm-
      iscsi-cons-xx] should reference the RFC number assigned to
      that document, and this note should be removed.
      --------------------------------------------------------

This last call explicitly identifies these downrefs in the normative references
of this document:

    [SAM2]      T10/1157D, SCSI Architecture Model - 2 (SAM-2).

      [SAM4]      ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-
                  4).

      [SAM5]      T10/2104D rev r04, SCSI Architecture Model - 5 (SAM-
                  5), Committee Draft.

      [SPC4]      T10/1731D rev r23, SCSI Primary Commands - 4 (SPC-4),
                  Committee Draft.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/


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

Authors response to my AD review:
- The ref to RFC 3720 should be kept, as this  is very well-known as the original primary reference for iSCSI.
- Waiting with this draft to go for IETF LC until the consolidate STORM draft is updated. Should go together in LC.

AD review, waiting for author's response:
The draft is almost ready to go and I have two comments:

Section 1., paragraph 1:

>      The original [RFC3720] was built based on the [SAM2] model for
>      SCSI. Several new features and capabilities have been added to

  'The original iSCSI protocol', instead of just 'The original'?


Section 5.2.1, paragraph 2:

>      As defined in Section 10, iSCSI PDU Formats of [RFC3720],
>      compliant senders already set this field to zero. Compliant
>      senders MUST NOT set this field to a value other than zero unless
>      the iSCSIProtocolLevel text key with a value of "2" or higher as
>      defined in section 7.1.1 was negotiated on the session.

  I wonder, if all references to RFC 3720 should actually
be replaced with references to draft-ietf-storm-iscsi-cons-05 which will obsolete RFC 3720 soon?

PROTO writeup:

  Internet Small Computer Systems Interface (iSCSI) SCSI Features
                              Update
                draft-ietf-storm-iscsi-sam-05.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (STORM WG Co-Chair)
------------------------------------------------------------------------

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

David L. Black (david.black@emc.com) is the Document Shepherd.  The
Document Shepherd has reviewed this version of the document
and believes that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had sufficient review from key WG members, from implementers
who work on important iSCSI implementations (both initiator and target
implementations) outside the WG and from key members of INCITS Technical
Committee T10, the organization responsible for SCSI standards.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) 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 WG consensus behind this document is solid; the WG as a whole
understands this document and agrees with the need for these minor
updates.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

Yes. idnits 2.12.12 a) couldn't find the Introduction section due to indenting
that idnits apparently didn't expect, b) flagged occurrences of "RFCxxx" in
instructions to the RFC Editor as possible downrefs (they aren't), and flagged
all references to SCSI standards as possible dowrefs (they also aren't).

        Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

N/A.

  (1.h) Has the document split its references into normative and
        informative?

Yes.

        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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

This document normatively references draft-ietf-storm-iscsi-cons-xx
(current version is -05), for which a publication request is being
submitted at the same time as the publication request for this docuemnt.

In addition, this document normatively references four SCSI standards
that are developed by INCITS Technical Committee T10 (www.t10.org),
namely SAM2, SAM4, SAM5 and SPC4.  As completed standards, SAM2 and SAM4
are not publicly available documents, because T10's parent standards
organizations fund their operations in part by charging for copies of
standards.  The document shepherd, David Black, is also the official
T10 Liaison to the IETF and in that role, he has been authorized by T10
to provide copies of these standards to IETF participants for their personal
use in IETF activities. If copies of these standarads are desired, please
contact the document shepherd, David Black (david.black@emc.com), directly.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section has been checked - the text describing
the additions to existing registries and creation of one new registry
is clear.  The new registry does not use the Expert Review process.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) 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

  The Internet Small Computer Systems Interface (iSCSI) is a SCSI
  transport protocol that maps the SCSI family of protocols onto
  TCP/IP. The base iSCSI protocol is based on the SAM-2 (SCSI
  Architecture Model - 2) SCSI standard.  This document specifies
  enhancements to the iSCSI protocol to support certain additional
  SCSI features that have been defined in subsequent versions of
  the SCSI Architecture Model.

    Working Group Summary

  There was very little dissent in the WG over the functionality in this
  document.  Significant WG discussion was devoted to correctly specifying
  SCSI-related identifiers used by this draft.  Rob Elliott and Ralph
  Weber (key members of the T10 SCSI standards organization) provided
  significant assistance in working through the identifier issues.

    Document Quality

  iSCSI implementers from Dell, EMC, Microsoft, NetApp, RedHat and VMware
  have reviewed this document for quality and consistency with existing
  implementations.  The reviews indicate that the enhancements are clearly
  specified, and are not expected to be significantly disruptive to add to
  existing implementations.

Waiting for issue resolution on main iSCSI draft, as this draft references that draft and v.v., hence both have to be submitted for publication at the same time.