Skip to main content

Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)
draft-ietf-storm-iscsi-cons-10

Revision differences

Document history

Date Rev. By Action
2014-03-28
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-02-19
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-02-10
10 (System) RFC Editor state changed to RFC-EDITOR from REF
2014-02-06
10 (System) RFC Editor state changed to REF from EDIT
2013-11-27
10 (System) RFC Editor state changed to EDIT from MISSREF
2013-10-08
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-10-08
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2013-10-08
10 (System) IANA Action state changed to In Progress from Waiting on ADs
2013-09-11
10 (System) IANA Action state changed to Waiting on ADs from Waiting on Authors
2013-08-27
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-08-27
10 (System) IANA Action state changed to In Progress from Waiting on ADs
2013-08-13
10 (System) IANA Action state changed to Waiting on ADs from Waiting on Authors
2013-07-30
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-07-29
10 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-07-29
10 (System) RFC Editor state changed to MISSREF
2013-07-29
10 (System) Announcement was received by RFC Editor
2013-07-29
10 (System) IANA Action state changed to In Progress
2013-07-28
10 Cindy Morgan State changed to Approved-announcement sent from Approved-announcement to be sent
2013-07-28
10 Cindy Morgan IESG has approved the document
2013-07-28
10 Cindy Morgan Closed "Approve" ballot
2013-07-28
10 Cindy Morgan Ballot approval text was generated
2013-07-28
10 Martin Stiemerling Changed consensus to Yes from Unknown
2013-07-28
10 Martin Stiemerling State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-07-28
10 Martin Stiemerling Ballot writeup was changed
2013-07-15
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-07-15
10 Mallikarjun Chadalapaka New version available: draft-ietf-storm-iscsi-cons-10.txt
2013-07-01
09 Martin Stiemerling waiting for the latest edits to be applied.
2013-07-01
09 Martin Stiemerling State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::External Party
2013-06-30
09 Brian Haberman [Ballot comment]
Thanks for resolving my discuss points.
2013-06-30
09 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2013-06-28
09 Stephen Farrell
[Ballot comment]

Thanks for adding the Kerberos details which look good.

I didn't check these with -09, so these are comments I
made on -07 …
[Ballot comment]

Thanks for adding the Kerberos details which look good.

I didn't check these with -09, so these are comments I
made on -07 with no changes.

- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. It may have seemed like a good plan
to merge a lot into one document, but this goes beyond
what's useful IMO.

- There seem to be many cases of terms being used that are
not (well) defined.  4.2.3.2 refers to [SPC3] for "task
set" which is the basis for a bunch of definitions I can't
understand, not having access to [SPC3].  And for example,
response fencing is all over section 4 but never defined. I
think a general pass for this probably would be worthwhile.

- Can you explain how a 2nd TCP connection for a session is
as secure as the first? I think that the login phase has to
be repeated but wasn't sure.

- 4.2.5 says that a connection is in full feature phase if
some (possibly other) connection has successfully passed
through the login phase. That seems to imply that only IP
level security can work for iSCSI (since TLS would be
connection specific) and that MPTCP couldn't be just
substutited for TCP. Is that correct? Where is that stated?

- 6.3.5 - I don't quite get the security model for session
reinstatement. It appears to be the case that if any user
that can login (if that's needed) could guess and ISID then
they could take over someone else's session - is that
right?  If not, what prevents that occurring? If so, where
does it say that ISID's MUST/SHOULD be hard to guess?

- Is it clear how iSCSI names are mapped to X.509 certs
used in IPsec?

- Just wondering if anyone's look at the recovery features
to check if flipping a bit in an ecrypted packet could
trigger any bad behaviour?

- section 7: What if IPsec goes wrong? Any specific
recovery for that?

- p158/9 is it not now time to make 3DES a SHOULD and AES a
MUST?

- CHAP has some weaknesses, but MUST only be used here when
sent via IPsec, is that correct? How would an
implementation know that IPsec is in use?

From the secdir review [1]:

- 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
the reference correct?

- 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
All outstanding tasks from all initiators for the LU
identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.  Are there any access control facilities for
this operation?

(Please also consider the other comments from the secdir
review as well.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html


nitty comments

- abstract: funny use of "standardized" - isn't that what
we're doing here?

- abstract: "difference in semantics" isn't all, I assume
this wins for all differences incl. syntax, prose etc.

- There's a lot of repetitive text. I think I read about
the direction of transfer 4-5 times in the first 30 pages.

- 2.2, initiator name: "woldwide unique" hmm, odd phrase.
What if a node is on the ISS or the Moon? Or if you have a
bad PRNG? (CHECK)

- 2.2, NAA - could I implement this without access to
[FC-FS3]? That appears to be a paywalled spec - is it?  I
guess there are others too.

- 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
used inside the definition)

- 2.2, "Third-party" - this definition is not
understandable.

- 4.2.2.3.2, "response fence" is used without definition

- 4.2.2.3.3, "I_T_L nexus" isn't defined.

- 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
what are UA, TMF, ACA...

- At this point I gave up on noting use of undefined terms.
("TTT" was the straw for this camel's back:-)

- 4.2.4, saying that a security association can be built in
"many different" ways is a bad idea. Surely the only ways
are those for which you have defined mechanisms?

- 4.2.4, "The login PDU includes..." why is it enough to
say what this includes without specifying precisely what it
is? (I include carbon atoms but am not a diamond;-)

- 4.2.5, "...is authorized to do so..." is vague. I think
you mean something succeeded but you've not defined what.

- 4.2.5.2, you don't say how the length of the first
unsolicited burst can be negotiated.

- 4.6.2 is an odd section with no text and just one 4 line
subsection. So is section 5. If you're following the
structure of some other document(s) it'd be nice to say
which. (If you did, I've already forgotten;-)

- section 6, is the continuation bit "C" really needed when
sending over TCP?

- p95, "new public keys" registerded with IANA trips up the
crypto geek in me:-) suggest s/public// and the same with
"private key"

- 9.2.2: is SRP really in use with iSCSI? If not, it'd
probaly be good to say so.

- p213, I don't get what Parameter1,2,3 are.
2013-06-28
09 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-06-24
09 Mallikarjun Chadalapaka New version available: draft-ietf-storm-iscsi-cons-09.txt
2013-01-23
08 Martin Stiemerling waiting for an update of draft-ietf-storm-iscsi-sam to clarify the usage of Version 0.
2013-01-23
08 Martin Stiemerling State changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup
2013-01-15
08 Sean Turner [Ballot comment]
I'm clearing based on the new text about getting rid of CHAP in future versions.

I support Stephen's discuss positions.
2013-01-15
08 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-01-15
08 Brian Haberman
[Ballot discuss]
Thanks resolving two of my three DISCUSS points.  Upon reviewing the e-mail exchanges about these issues, I am curious as to the lack …
[Ballot discuss]
Thanks resolving two of my three DISCUSS points.  Upon reviewing the e-mail exchanges about these issues, I am curious as to the lack of document changes for the 2nd point below.  The response from David indicated that the referenced text in 6.2 will either be revised or removed based on edits to the iscsi-sam draft. Was something missed?

* [RESOLVED] In section 4.2.2.3.4, the first paragraph states : "This Section lists the situations in which fenced response behavior is REQUIRED in iSCSI target implementations. However, this is not an exhaustive enumeration."

Is the list of use cases exhaustive as currently known within the existing implementations?  If it is, the second sentence is not needed.  No one should expect a spec to be able to address use cases created after its publication.  If it is not, why not?

* Section 6.2 states : "The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. An iSCSI implementation MUST comprehend all text keys defined in iSCSI Protocol specifications from RFC 3720 through the RFC associated with the highest protocol version that the implementation has offered (or has negotiated, in the case of an acceptor) for the iSCSIProtocolLevel key in a negotiation.

If I understand all of the relevant RFCs and this draft, iSCSIProtocolLevel is still 1.  Is there a spec for level 0?  I am unsure why this draft would reference back to 3720, when it is making that RFC obsolete and subsuming all of its functionality.  The above text is making assumptions about what future iSCSI specifications may or may not require.  Why is the requirement for handling NotUnderstood responses not more concrete and contained within this spec?

* [RESOLVED] This spec states that it is updating RFCs 3721 and 3723.  If that is the case, why is RFC 3721 listed as an Informative reference while 3723 is a Normative reference?
2013-01-15
08 Brian Haberman Ballot comment and discuss text updated for Brian Haberman
2013-01-15
08 Stephen Farrell
[Ballot discuss]

Looks like -08 cleared all my discuss points except the kerberos
encoding issue.

(1) cleared based on -08

(2) cleared

(3) cleared based …
[Ballot discuss]

Looks like -08 cleared all my discuss points except the kerberos
encoding issue.

(1) cleared based on -08

(2) cleared

(3) cleared based on -08

(4) cleared based on -08

(5) 12.1.1: how are the krb-ap-req & rep encoded? Those are
binary messages. I don't get how that's handled.  (Same for
12.1.2) - I don't see any change here yet in -08, so leaving
this one for now.
2013-01-15
08 Stephen Farrell
[Ballot comment]

I didn't check these with -08, so these are comments I
made on -07 with no changes.

- There's a lot of repetition …
[Ballot comment]

I didn't check these with -08, so these are comments I
made on -07 with no changes.

- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. It may have seemed like a good plan
to merge a lot into one document, but this goes beyond
what's useful IMO.

- There seem to be many cases of terms being used that are
not (well) defined.  4.2.3.2 refers to [SPC3] for "task
set" which is the basis for a bunch of definitions I can't
understand, not having access to [SPC3].  And for example,
response fencing is all over section 4 but never defined. I
think a general pass for this probably would be worthwhile.

- Can you explain how a 2nd TCP connection for a session is
as secure as the first? I think that the login phase has to
be repeated but wasn't sure.

- 4.2.5 says that a connection is in full feature phase if
some (possibly other) connection has successfully passed
through the login phase. That seems to imply that only IP
level security can work for iSCSI (since TLS would be
connection specific) and that MPTCP couldn't be just
substutited for TCP. Is that correct? Where is that stated?

- 6.3.5 - I don't quite get the security model for session
reinstatement. It appears to be the case that if any user
that can login (if that's needed) could guess and ISID then
they could take over someone else's session - is that
right?  If not, what prevents that occurring? If so, where
does it say that ISID's MUST/SHOULD be hard to guess?

- Is it clear how iSCSI names are mapped to X.509 certs
used in IPsec?

- Just wondering if anyone's look at the recovery features
to check if flipping a bit in an ecrypted packet could
trigger any bad behaviour?

- section 7: What if IPsec goes wrong? Any specific
recovery for that?

- p158/9 is it not now time to make 3DES a SHOULD and AES a
MUST?

- CHAP has some weaknesses, but MUST only be used here when
sent via IPsec, is that correct? How would an
implementation know that IPsec is in use?

From the secdir review [1]:

- 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
the reference correct?

- 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
All outstanding tasks from all initiators for the LU
identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.  Are there any access control facilities for
this operation?

(Please also consider the other comments from the secdir
review as well.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html


nitty comments

- abstract: funny use of "standardized" - isn't that what
we're doing here?

- abstract: "difference in semantics" isn't all, I assume
this wins for all differences incl. syntax, prose etc.

- There's a lot of repetitive text. I think I read about
the direction of transfer 4-5 times in the first 30 pages.

- 2.2, initiator name: "woldwide unique" hmm, odd phrase.
What if a node is on the ISS or the Moon? Or if you have a
bad PRNG? (CHECK)

- 2.2, NAA - could I implement this without access to
[FC-FS3]? That appears to be a paywalled spec - is it?  I
guess there are others too.

- 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
used inside the definition)

- 2.2, "Third-party" - this definition is not
understandable.

- 4.2.2.3.2, "response fence" is used without definition

- 4.2.2.3.3, "I_T_L nexus" isn't defined.

- 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
what are UA, TMF, ACA...

- At this point I gave up on noting use of undefined terms.
("TTT" was the straw for this camel's back:-)

- 4.2.4, saying that a security association can be built in
"many different" ways is a bad idea. Surely the only ways
are those for which you have defined mechanisms?

- 4.2.4, "The login PDU includes..." why is it enough to
say what this includes without specifying precisely what it
is? (I include carbon atoms but am not a diamond;-)

- 4.2.5, "...is authorized to do so..." is vague. I think
you mean something succeeded but you've not defined what.

- 4.2.5.2, you don't say how the length of the first
unsolicited burst can be negotiated.

- 4.6.2 is an odd section with no text and just one 4 line
subsection. So is section 5. If you're following the
structure of some other document(s) it'd be nice to say
which. (If you did, I've already forgotten;-)

- section 6, is the continuation bit "C" really needed when
sending over TCP?

- p95, "new public keys" registerded with IANA trips up the
crypto geek in me:-) suggest s/public// and the same with
"private key"

- 9.2.2: is SRP really in use with iSCSI? If not, it'd
probaly be good to say so.

- p213, I don't get what Parameter1,2,3 are.
2013-01-15
08 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2013-01-15
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-01-15
08 Mallikarjun Chadalapaka New version available: draft-ietf-storm-iscsi-cons-08.txt
2012-10-18
07 Tero Kivinen Request for Telechat review by SECDIR Completed. Reviewer: Alexey Melnikov.
2012-10-12
07 Stephen Farrell
[Ballot discuss]
(1) Is IPsec mandatory to implement or not? While it might
be ok to omit that detail for an initiator running on a …
[Ballot discuss]
(1) Is IPsec mandatory to implement or not? While it might
be ok to omit that detail for an initiator running on a
standard OS, it needs to be clear for e.g. a LUN that runs
on an embedded OS.

(2) cleared

(3) Why are sections 2.4.x and the intro to 11 both needed?
Do they even say the same thing? Having text like that
twice is bad. Section 11 seems clearer.

(4) If there is a conflict between the text in section
11/12/13 and earlier text, which wins? Where's that stated?
I think you need that given how much overlap there is.

(5) 12.1.1: how are the krb-ap-req & rep encoded? Those are
binary messages. I don't get how that's handled.  (Same for
12.1.2)
2012-10-12
07 Stephen Farrell
[Ballot comment]
- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. …
[Ballot comment]
- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. It may have seemed like a good plan
to merge a lot into one document, but this goes beyond
what's useful IMO.

- There seem to be many cases of terms being used that are
not (well) defined.  4.2.3.2 refers to [SPC3] for "task
set" which is the basis for a bunch of definitions I can't
understand, not having access to [SPC3].  And for example,
response fencing is all over section 4 but never defined. I
think a general pass for this probably would be worthwhile.

- Can you explain how a 2nd TCP connection for a session is
as secure as the first? I think that the login phase has to
be repeated but wasn't sure.

- 4.2.5 says that a connection is in full feature phase if
some (possibly other) connection has successfully passed
through the login phase. That seems to imply that only IP
level security can work for iSCSI (since TLS would be
connection specific) and that MPTCP couldn't be just
substutited for TCP. Is that correct? Where is that stated?

- 6.3.5 - I don't quite get the security model for session
reinstatement. It appears to be the case that if any user
that can login (if that's needed) could guess and ISID then
they could take over someone else's session - is that
right?  If not, what prevents that occurring? If so, where
does it say that ISID's MUST/SHOULD be hard to guess?

- Is it clear how iSCSI names are mapped to X.509 certs
used in IPsec?

- Just wondering if anyone's look at the recovery features
to check if flipping a bit in an ecrypted packet could
trigger any bad behaviour?

- section 7: What if IPsec goes wrong? Any specific
recovery for that?

- p158/9 is it not now time to make 3DES a SHOULD and AES a
MUST?

- CHAP has some weaknesses, but MUST only be used here when
sent via IPsec, is that correct? How would an
implementation know that IPsec is in use?

From the secdir review [1]:

- 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
the reference correct?

- 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
All outstanding tasks from all initiators for the LU
identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.  Are there any access control facilities for
this operation?

(Please also consider the other comments from the secdir
review as well.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html


nitty comments

- abstract: funny use of "standardized" - isn't that what
we're doing here?

- abstract: "difference in semantics" isn't all, I assume
this wins for all differences incl. syntax, prose etc.

- There's a lot of repetitive text. I think I read about
the direction of transfer 4-5 times in the first 30 pages.

- 2.2, initiator name: "woldwide unique" hmm, odd phrase.
What if a node is on the ISS or the Moon? Or if you have a
bad PRNG? (CHECK)

- 2.2, NAA - could I implement this without access to
[FC-FS3]? That appears to be a paywalled spec - is it?  I
guess there are others too.

- 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
used inside the definition)

- 2.2, "Third-party" - this definition is not
understandable.

- 4.2.2.3.2, "response fence" is used without definition

- 4.2.2.3.3, "I_T_L nexus" isn't defined.

- 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
what are UA, TMF, ACA...

- At this point I gave up on noting use of undefined terms.
("TTT" was the straw for this camel's back:-)

- 4.2.4, saying that a security association can be built in
"many different" ways is a bad idea. Surely the only ways
are those for which you have defined mechanisms?

- 4.2.4, "The login PDU includes..." why is it enough to
say what this includes without specifying precisely what it
is? (I include carbon atoms but am not a diamond;-)

- 4.2.5, "...is authorized to do so..." is vague. I think
you mean something succeeded but you've not defined what.

- 4.2.5.2, you don't say how the length of the first
unsolicited burst can be negotiated.

- 4.6.2 is an odd section with no text and just one 4 line
subsection. So is section 5. If you're following the
structure of some other document(s) it'd be nice to say
which. (If you did, I've already forgotten;-)

- section 6, is the continuation bit "C" really needed when
sending over TCP?

- p95, "new public keys" registerded with IANA trips up the
crypto geek in me:-) suggest s/public// and the same with
"private key"

- 9.2.2: is SRP really in use with iSCSI? If not, it'd
probaly be good to say so.

- p213, I don't get what Parameter1,2,3 are.
2012-10-12
07 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2012-10-11
07 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-10-11
07 Adrian Farrel
[Ballot comment]
340 pages is too much for an out-of-area AD to give a detailed review. On a light read I don't find any worries …
[Ballot comment]
340 pages is too much for an out-of-area AD to give a detailed review. On a light read I don't find any worries from a routing perspective, and so I am balloting "No Objection" on the understanding that this work is primarily a consolidation of pre-existing work.
2012-10-11
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-10-11
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-10-10
07 Benoît Claise
[Ballot comment]
I am voting no objection on the basis that a quick review indicates no implications for OPS for this draft, and that the …
[Ballot comment]
I am voting no objection on the basis that a quick review indicates no implications for OPS for this draft, and that the OPS aspects will be covered in draft-ietf-storm-iscsimib.
2012-10-10
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-10-10
07 Pete Resnick
[Ballot comment]
2.2:

  - SCSI Port Name: A name made up as UTF-8 characters and includes
  the iSCSI Name + 'i' or 't' …
[Ballot comment]
2.2:

  - SCSI Port Name: A name made up as UTF-8 characters and includes
  the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.

s/made up as/encoded as

4.2.3.5:

  If the issuing session is a FastAbort session, the iSCSI target
  implementation is FastAbort-capable, and the third-party affected
  session is an RFC 3720 session, the following behavior MUST be
  exhibited by the iSCSI target layer: Asynchronous Message PDUs
  MUST NOT be sent on the third-party session to prompt the
  FastAbort behavior.

I don't understand what counts as "following" in "the following behavior MUST be exhibited". Why not simplify to:

  If the issuing session is a FastAbort session, the iSCSI target
  implementation is FastAbort-capable, and the third-party affected
  session is an RFC 3720 session, the iSCSI target layer MUST NOT
  send Asynchronous Message PDUs on the third-party session to prompt
  the FastAbort behavior.

Is there something else "following" that needs to be accounted for?

(The following is about text that was in the original document. Because of that, I will not put a DISCUS on this, but gee would I like to see this clarified.

4.2.7.1 says:

    - iSCSI names are composed only of displayable characters.
      iSCSI names allow the use of international character sets
      but are not case sensitive. No whitespace characters are
      used in iSCSI names.

and 4.2.7.2 says:

    - It is in Normalization Form C (see "Unicode Normalization
      Forms" [UNICODE]).

    - It only contains characters allowed by the output of the
      iSCSI stringprep template (described in [RFC3722]).

"not case sensitive" in 4.2.7.1 is weird. That would seem to imply that you *can* have uppercase characters, but that they compare equally to lowercase characters. But 4.2.7.2 (and in particular 3722) says that it's only going to be lowercase. Something seems amiss. Do you mean only ASCII characters are compared case-insensitively?


All this said, I am bummed that we didn't get PRECIS far enough along to include in this version. Ah, well.
2012-10-10
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-10-10
07 Barry Leiba
[Ballot comment]
I haven't been able to give this a full review.  Some non-blocking comments here, based on what I've had time to cover.  If …
[Ballot comment]
I haven't been able to give this a full review.  Some non-blocking comments here, based on what I've had time to cover.  If I get more before tomorrow's telechat, I'll add them and re-send this.

-- Section 4.2.4 --
  To protect the TCP connection, an IPsec security association MAY
  be established before the Login request.

Related to Stephen's DISUCSS point (1), why is *use* of IPSec a MAY?  It's clear to me why neither authentication nor connection-level security is always needed (for example, using iSCSI to access a read-only repository of public information), so performing login is a SHOULD.  Why isn't IPSec also SHOULD?

-- Section 6.1 --
You give Unicode code points for the non-alphanumeric characters, but not for the alphanumeric ones.  Just to be complete, and to recognize that there are multiple Unicode characters that look like "a", for example, you should probably do this:

OLD
  (a-z, A-Z) - letters
  (0-9) - digits
NEW
  (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
  (0-9) (0x30-0x39) - digits

Consider whether RFC 4648 would be a better reference for base64 encoding than RFC 2045.

I see that Mallikarjun and Alexey are engaged in conversation about Alexey's AppsDir review, with resultant changes.  And my esteemed colleague from Illinois has said that he's covering the stringprep stuff and related issues.  Apart from that, I don't see any App-layer issues raised here, and trust that the ADs at the lower layers will handle those.
2012-10-10
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-10-10
07 Sean Turner
[Ballot discuss]
CHAP has long been known to be vulnerable to dictionary attacks (prior to '07).  You've got considerations for how to use it, but …
[Ballot discuss]
CHAP has long been known to be vulnerable to dictionary attacks (prior to '07).  You've got considerations for how to use it, but can we please put something in to support will be dropped in the next version?
2012-10-10
07 Sean Turner [Ballot comment]
I support Stephen's discuss positions.
2012-10-10
07 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2012-10-09
07 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-10-09
07 Brian Haberman
[Ballot discuss]
* In section 4.2.2.3.4, the first paragraph states : "This Section lists the situations in which fenced response behavior is REQUIRED in iSCSI …
[Ballot discuss]
* In section 4.2.2.3.4, the first paragraph states : "This Section lists the situations in which fenced response behavior is REQUIRED in iSCSI target implementations. However, this is not an exhaustive enumeration."

Is the list of use cases exhaustive as currently known within the existing implementations?  If it is, the second sentence is not needed.  No one should expect a spec to be able to address use cases created after its publication.  If it is not, why not?

* Section 6.2 states : "The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. An iSCSI implementation MUST comprehend all text keys defined in iSCSI Protocol specifications from RFC 3720 through the RFC associated with the highest protocol version that the implementation has offered (or has negotiated, in the case of an acceptor) for the iSCSIProtocolLevel key in a negotiation.

If I understand all of the relevant RFCs and this draft, iSCSIProtocolLevel is still 1.  Is there a spec for level 0?  I am unsure why this draft would reference back to 3720, when it is making that RFC obsolete and subsuming all of its functionality.  The above text is making assumptions about what future iSCSI specifications may or may not require.  Why is the requirement for handling NotUnderstood responses not more concrete and contained within this spec?

* This spec states that it is updating RFCs 3721 and 3723.  If that is the case, why is RFC 3721 listed as an Informative reference while 3723 is a Normative reference?
2012-10-09
07 Brian Haberman
[Ballot comment]
* The text in section 2.3 is useful, but it does not discuss what is being updated in RFCs 3721 and 3723.

* …
[Ballot comment]
* The text in section 2.3 is useful, but it does not discuss what is being updated in RFCs 3721 and 3723.

* The References section is un-numbered and not included in the TOC.

* Section 4.2.7 makes a reference to SLP.  The acronym is not expanded and RFC 2608 is not referenced.

* Section 4.2.7.3 (way minor typo) : s/assists.in/assists in/

* Section 9.4 : s/wellknown/well-known/
2012-10-09
07 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2012-10-09
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-10-09
07 Stephen Farrell
[Ballot discuss]

(1) Is IPsec mandatory to implement or not? While it might
be ok to omit that detail for an initiator running on a …
[Ballot discuss]

(1) Is IPsec mandatory to implement or not? While it might
be ok to omit that detail for an initiator running on a
standard OS, it needs to be clear for e.g. a LUN that runs
on an embedded OS.

(2) p153, 2nd last para: how can an implementation above
TCP verify that IPsec encryption is being used?  Same at
the end of setion 9.3.

(3) Why are sections 2.4.x and the intro to 11 both needed?
Do they even say the same thing? Having text like that
twice is bad. Section 11 seems clearer.

(4) If there is a conflict between the text in section
11/12/13 and earlier text, which wins? Where's that stated?
I think you need that given how much overlap there is.

(5) 12.1.1: how are the krb-ap-req & rep encoded? Those are
binary messages. I don't get how that's handled.  (Same for
12.1.2)
2012-10-09
07 Stephen Farrell
[Ballot comment]

- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. …
[Ballot comment]

- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. It may have seemed like a good plan
to merge a lot into one document, but this goes beyond
what's useful IMO.

- There seem to be many cases of terms being used that are
not (well) defined.  4.2.3.2 refers to [SPC3] for "task
set" which is the basis for a bunch of definitions I can't
understand, not having access to [SPC3].  And for example,
response fencing is all over section 4 but never defined. I
think a general pass for this probably would be worthwhile.

- Can you explain how a 2nd TCP connection for a session is
as secure as the first? I think that the login phase has to
be repeated but wasn't sure.

- 4.2.5 says that a connection is in full feature phase if
some (possibly other) connection has successfully passed
through the login phase. That seems to imply that only IP
level security can work for iSCSI (since TLS would be
connection specific) and that MPTCP couldn't be just
substutited for TCP. Is that correct? Where is that stated?

- 6.3.5 - I don't quite get the security model for session
reinstatement. It appears to be the case that if any user
that can login (if that's needed) could guess and ISID then
they could take over someone else's session - is that
right?  If not, what prevents that occurring? If so, where
does it say that ISID's MUST/SHOULD be hard to guess?

- Is it clear how iSCSI names are mapped to X.509 certs
used in IPsec?

- Just wondering if anyone's look at the recovery features
to check if flipping a bit in an ecrypted packet could
trigger any bad behaviour?

- section 7: What if IPsec goes wrong? Any specific
recovery for that?

- p158/9 is it not now time to make 3DES a SHOULD and AES a
MUST?

- CHAP has some weaknesses, but MUST only be used here when
sent via IPsec, is that correct? How would an
implementation know that IPsec is in use?

From the secdir review [1]:

- 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
the reference correct?

- 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
All outstanding tasks from all initiators for the LU
identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.  Are there any access control facilities for
this operation?

(Please also consider the other comments from the secdir
review as well.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html


nitty comments

- abstract: funny use of "standardized" - isn't that what
we're doing here?

- abstract: "difference in semantics" isn't all, I assume
this wins for all differences incl. syntax, prose etc.

- There's a lot of repetitive text. I think I read about
the direction of transfer 4-5 times in the first 30 pages.

- 2.2, initiator name: "woldwide unique" hmm, odd phrase.
What if a node is on the ISS or the Moon? Or if you have a
bad PRNG? (CHECK)

- 2.2, NAA - could I implement this without access to
[FC-FS3]? That appears to be a paywalled spec - is it?  I
guess there are others too.

- 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
used inside the definition)

- 2.2, "Third-party" - this definition is not
understandable.

- 4.2.2.3.2, "response fence" is used without definition

- 4.2.2.3.3, "I_T_L nexus" isn't defined.

- 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
what are UA, TMF, ACA...

- At this point I gave up on noting use of undefined terms.
("TTT" was the straw for this camel's back:-)

- 4.2.4, saying that a security association can be built in
"many different" ways is a bad idea. Surely the only ways
are those for which you have defined mechanisms?

- 4.2.4, "The login PDU includes..." why is it enough to
say what this includes without specifying precisely what it
is? (I include carbon atoms but am not a diamond;-)

- 4.2.5, "...is authorized to do so..." is vague. I think
you mean something succeeded but you've not defined what.

- 4.2.5.2, you don't say how the length of the first
unsolicited burst can be negotiated.

- 4.6.2 is an odd section with no text and just one 4 line
subsection. So is section 5. If you're following the
structure of some other document(s) it'd be nice to say
which. (If you did, I've already forgotten;-)

- section 6, is the continuation bit "C" really needed when
sending over TCP?

- p95, "new public keys" registerded with IANA trips up the
crypto geek in me:-) suggest s/public// and the same with
"private key"

- 9.2.2: is SRP really in use with iSCSI? If not, it'd
probaly be good to say so.

- p213, I don't get what Parameter1,2,3 are.
2012-10-09
07 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2012-10-08
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-10-08
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-10-07
07 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from No Record
2012-10-07
07 Stewart Bryant [Ballot comment]
I am voting no objection on the basis that a quick review indicates no implications for the routing system.
2012-10-07
07 Stewart Bryant Ballot comment text updated for Stewart Bryant
2012-10-04
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Alexey Melnikov
2012-10-04
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Alexey Melnikov
2012-10-04
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready with Issues. Reviewer: Alexey Melnikov.
2012-10-02
07 Martin Stiemerling Removed telechat returning item indication
2012-10-02
07 Martin Stiemerling State changed to IESG Evaluation from AD Evaluation::AD Followup
2012-10-01
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-10-01
07 Mallikarjun Chadalapaka New version available: draft-ietf-storm-iscsi-cons-07.txt
2012-09-14
06 Martin Stiemerling Telechat date has been changed to 2012-10-11 from 2012-09-27
2012-09-04
06 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from Waiting for AD Go-Ahead
2012-09-04
06 Martin Stiemerling State changed to Waiting for AD Go-Ahead from IESG Evaluation
2012-09-04
06 Martin Stiemerling Telechat date has been changed to 2012-09-27 from 2012-09-13
2012-09-04
06 Martin Stiemerling Ballot has been issued
2012-09-04
06 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2012-09-04
06 Martin Stiemerling Created "Approve" ballot
2012-09-04
06 Martin Stiemerling Ballot writeup was changed
2012-09-04
06 Martin Stiemerling State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-08-13
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-08-10
06 Pearl Liang
IANA has reviewed draft-ietf-storm-iscsi-cons-06 and has the following comments:

IANA notes that one of the IANA actions requested in this document is
dependent on the …
IANA has reviewed draft-ietf-storm-iscsi-cons-06 and has the following comments:

IANA notes that one of the IANA actions requested in this document is
dependent on the approval of other Internet-Drafts.

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

First, IANA notes that the well-known TCP port number for iSCSI connections
assigned by IANA is 3260 and this is the default iSCSI port. This port is
already assigned for TCP and UDP at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

IANA understands that no further port numbers or service names are required upon
approval of this document.

Second, in the Internet Small Computer System Interface (iSCSI) Parameters
registries located in:

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

IANA will update all references to RFC 3720, RFC 4850 and RFC 5048 to instead
reference this RFC [ RFC-to-be ]. IANA understands that this change reflects the
fact that those three RFCs are obsoleted by [ RFC-to-be ]. In addition, the
IANA Registry Matrix at:

http://www.iana.org/protocols

will also be updated to reflect this change. IANA will take care that any iSCSI
references to other RFCs that are not being obsoleted (e.g., RFC 3723, RFC 5046)
will not be changed.

Third, in the iSCSI Login/Text Keys registry located at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

IANA will make the following four changes:

1] The registration procedure will be changed from IETF Review to Statndard
Required;
2] Change the reference from RFC 5048 to [ RFC-to-be ];
3] Add the following key to the iSCSI Login/Text Keys registry using a reference
of [ RFC-to-be ]
X#NodeArchitecture
4] Change all references of RFC 3720 and RFC 5048 to reference [ RFC-to-be ].

Fourth, remove the iSCSI extended key subregistry from the Internet Small
Computer System Interface (iSCSI) Parameters registries located in:

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

Fifth, in the iSCSI authentication methods subregistry of the Internet Small
Computer System Interface (iSCSI) Parameters registries located in:

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

change the registration procedure from IETF Review to RFC required.

Sixth, in the iSCSI digests subregistry of the Internet Small Computer System
Interface (iSCSI) Parameters registries located in:

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

change the registration procedure from IETF Review to RFC required.

Seventh, in a new registry to be created by the approval of the Internet-Draft [
draft-ietf-storm-iscsi-sam ], IANA is requested to add a new registration in the
newly created registry.

In the newly created subregistry called "iSCSI Protocol Level" created by
Section 9 of [ draft-ietf-storm-iscsi-sam ]:

Assigned value: 1
RFC Reference: [ RFC-to-be ]

IANA notes that the values 0 and 2 are to be assigned by the approval of [
draft-ietf-storm-iscsi-sam ].

Eighth, in the iSCSI authentication methods subregistry of the the Internet
Small Computer System Interface (iSCSI) Parameters registries located in:

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

the values 4 and 5, for SPKM1 and SPKM2 respectively, will be marked obsolete.

IANA understands that these eight actions are the only ones required 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.
2012-07-21
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2012-07-21
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2012-07-20
06 Martin Stiemerling Telechat date has been changed to 2012-09-13 from 2012-08-16
2012-07-19
06 Jean Mahoney Request for Last Call review by GENART is assigned to Kathleen Moriarty
2012-07-19
06 Jean Mahoney Request for Last Call review by GENART is assigned to Kathleen Moriarty
2012-07-17
06 Martin Stiemerling Placed on agenda for telechat - 2012-08-16
2012-07-16
06 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (iSCSI Protocol (Consolidated)) to Proposed Standard …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (iSCSI Protocol (Consolidated)) to Proposed Standard


The IESG has received a request from the STORage Maintenance WG (storm)
to consider the following document:
- 'iSCSI Protocol (Consolidated)'
  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-sam, as both
drafts should be reviewed together.

Abstract


  This document describes a transport protocol for SCSI that works
  on top of TCP. The iSCSI protocol aims to be fully compliant with
  the standardized SCSI Architecture Model (SAM-2). RFC 3720
  defined the original iSCSI protocol. RFC 3721 discusses iSCSI
  Naming examples and discovery techniques. Subsequently, RFC 3980
  added an additional naming format to iSCSI protocol. RFC 4850
  followed up by adding a new public extension key to iSCSI. RFC
  5048
offered a number of clarifications and a few improvements and
  corrections to the original iSCSI protocol.


  This document obsoletes RFCs 3720, 3980, 4850 and 5048 by
  consolidating them into a single document and making additional
  updates to the consolidated specification. This document also
  updates RFC 3721 and RFC 3723. The text in this document thus
  supersedes the text in all the noted RFCs wherever there is a
  difference in semantics.

This last call explicitly identifies these downrefs in the normative references
of this document:
    [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)",
      http://standards.ieee.org/regauth/oui/tutorials/EUI64.html

    [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling
      Interface (FC-FS).

    [OUI] "IEEE OUI and Company_Id Assignments",
      http://standards.ieee.org/regauth/oui

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

    [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3).

    [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4).

    [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2).

    [SPC3] T10/1416-D, SCSI Primary Commands-3.

    [UML]  ISO/IEC 19501, Unified Modeling Language
      Specification Version 1.4.2.

    [UNICODE] Unicode Standard Annex #15, "Unicode Normalization
      Forms", http://www.unicode.org/unicode/reports/tr15



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

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


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


2012-07-16
06 Cindy Morgan State changed to In Last Call from Last Call Requested
2012-07-16
06 Martin Stiemerling Last call was requested
2012-07-16
06 Martin Stiemerling State changed to Last Call Requested from Last Call Requested
2012-07-16
06 Martin Stiemerling Last call announcement was changed
2012-07-16
06 Martin Stiemerling Last call was requested
2012-07-16
06 Martin Stiemerling Ballot approval text was generated
2012-07-16
06 Martin Stiemerling State changed to Last Call Requested from AD Evaluation::AD Followup
2012-07-16
06 Martin Stiemerling Last call announcement was changed
2012-07-16
06 Martin Stiemerling Last call announcement was generated
2012-07-16
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-07-16
06 Mallikarjun Chadalapaka New version available: draft-ietf-storm-iscsi-cons-06.txt
2012-06-12
05 Martin Stiemerling
AD review:

Two nits:
- Figures are not labelled at all (neither numbering nor textual description).
- Tables are not labelled at all (neither numbering …
AD review:

Two nits:
- Figures are not labelled at all (neither numbering nor textual description).
- Tables are not labelled at all (neither numbering nor textual description).


Section 2.1., paragraph 34:

>  - SCSI Port: This is the SAM2 term for an entity in a SCSI Device
>  that provides the SCSI functionality to interface with a service
>  delivery subsystem. For iSCSI, the definition of the SCSI
>  Initiator Port and the SCSI Target Port are different.

  How about moving this definition one up, above the SCSI#
Initiator Port? This will improve the reading flow.


Section 2.1., paragraph 44:

>  - Third-party: A term used in this document to denote nexus
>  objects (I_T or I_T_L) and iSCSI sessions that reap the side
>  effects of actions that take place in the context of a separate
>  iSCSI session, while being third parties to the action that caused
>  the side effects. One example of a third-party session is an
>  iSCSI session hosting an I_T_L nexus to an LU that is reset with
>  an LU Reset TMF via a separate I_T nexus.

  I_T_L is not defined in here but only later on in the abbrev.
It might be good to introduce here shortly, otherwise the reader
might get confused about the differenece between I_T and I_T_L.


Section 4.2.2.1., paragraph 5:

>  Commands meant for immediate delivery are marked with an immediate
>  delivery flag; they MUST also carry the current CmdSN. CmdSN does
>  not advance after a command marked for immediate delivery is sent.

  Shouldn't the last sentence say "MUST NOT advanced"?


Section 4.2.2.1., paragraph 6:

>  Command numbering starts with the first login request on the first
>  connection of a session (the leading login on the leading
>  connection) and command numbers are incremented by 1 for every
>  non-immediate command issued afterwards.

  Shouldn't the it say "MUST be incremented by 1"?


Section 4.2.2.1., paragraph 7:

>  If immediate delivery is used with task management commands, these
>  commands may reach the target before the tasks on which they are
>  supposed to act. However their CmdSN serves as a marker of their
>  position in the stream of commands. The initiator and target must
>  ensure that the task management commands act as specified by
>  [SAM2]. For example, both commands and responses appear as if
>  delivered in order. Whenever CmdSN for an outgoing PDU is not
>  specified by an explicit rule, CmdSN will carry the current value
>  of the local CmdSN variable (see later in this section).

  Shouldn't is read "initiator and target MUST ensure that
the task management..."?


Section 4.2.2.1., paragraph 9:

>  The number of commands used for immediate delivery is not limited
>  and their delivery to execution is not acknowledged through the
>  numbering scheme. Immediate commands MAY be rejected by the iSCSI
>  target layer due to lack of resources. An iSCSI target MUST be
>  able to handle at least one immediate task management command and
>  one immediate non-task-management iSCSI command per connection at
>  any time.

  A question about the "MAY be rejected by the iSCSI": This
'MAY' with 'lack of resources' makes me wondering. If there are no
resources left, I have to reject any command. So what is the MAY
here about?


Section 4.2.2.1., paragraph 13:

>      - CmdSN - the current command Sequence Number, advanced by 1
>        on each command shipped except for commands marked for
>        immediate delivery. CmdSN always contains the number to be
>        assigned to the next Command PDU.

What happens to the CmdSN, if it wraps over? A reference to Section 10.4.
would be good.


Section 4.2.2.1., paragraph 14:

>      - ExpCmdSN - the next expected command by the target. The
>        target acknowledges all commands up to, but not including,
>        this number. The initiator treats all commands with CmdSN
>        less than ExpCmdSN as acknowledged. The target iSCSI layer
>        sets the ExpCmdSN to the largest non-immediate CmdSN that it
>        can deliver for execution "plus 1" per [RFC1982]. There
>        MUST NOT be any holes in the acknowledged CmdSN sequence.

What happens if there are holes?


Section 4.2.2.4., paragraph 2:

>  For any read or bidirectional command, a target MUST issue less
>  than 2**32 combined R2T and Data-In PDUs. Any output data sequence
>  MUST contain less than 2**32 Data-Out PDUs.

  Just for curiosity: how to handled more than 2**32 PDUs?


Section 4.2.3.3., paragraph 3:

>  The target iSCSI layer:
>    a. MUST wait for responses on currently valid target-transfer
>        tags of the affected tasks from the issuing initiator. MAY
>        wait for responses on currently valid target-transfer tags
>        of the affected tasks from third-party initiators.
>    b. MUST wait (concurrent with the wait in Step a) for all
>        commands of the affected tasks to be received based on the
>        CmdSN ordering. SHOULD NOT wait for new commands on third-
>        party affected sessions -- only the instantiated tasks have
>        to be considered for the purpose of determining the
>        affected tasks. In the case of target-scoped requests
>        (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the
>        commands that are not yet received on the issuing session
>        in the command stream however can be considered to have
>        been received with no command waiting period -- i.e., the
>        entire CmdSN space up to the CmdSN of the task management
>        function can be "plugged".

  What exactly does "plugged" mean here? Also for the following
occurencs of "plugged" later on.


Section 4.2.5.2., paragraph 4:

>  The maximum amount of unsolicited data that can be sent with a
>  command is negotiated at login through the FirstBurstLength key. A
>  target MAY separately enable immediate data (through the
>  ImmediateData key) without enabling the more general (separate
>  data PDUs) form of unsolicited data (through the InitialR2T key).

  I wonder if the feature negotiation should be described
just before this section, right after the login description.
This would help the reader to better understand the feature
negotiation.


Section 4.2.5.2., paragraph 7:

>  It is considered an error for an initiator to send unsolicited
>  data PDUs to a target that operates in R2T mode (only solicited
>  data are allowed). It is also an error for an initiator to send
>  more unsolicited data, whether immediate or as separate PDUs, than
>  FirstBurstLength.

  It is not clear to me, at least at this point of the draft,
what the error handling in such a case is.


Section 4.2.5.3., paragraph 2:

>  As the Initiator Task Tag is used to identify a task during its
>  execution the iSCSI initiator and target MUST verify that all
>  other fields used in task related PDUs have values that are
>  consistent with the values used at the task instantiation based on
>  Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the
>  same as the one used in the SCSI command PDU used to instantiate
>  the task). Using inconsistent field values is considered a
>  protocol error.

  What type of protocol error?



Section 6.2., paragraph 24:

>  All keys in this document, except for the X extension formats,
>  MUST be supported by iSCSI initiators and targets when used as
>  specified here. If used as specified, these keys MUST NOT be
>  answered with NotUnderstood.

There has been a related discussion about the x-dash feature in
the apps area (draft is in the RFC editor's queue):
http://tools.ietf.org/html/draft-ietf-appsawg-xdash-05
Have you considered removing the x extension formats, or asking you
differently, are you prepared to answer IESG comments about the X
extension formats in the light of the above draft?


Section 6.2., paragraph 33:

>  An iSCSI initiator or target MAY terminate a negotiation that does
>  not end within a reasonable time or number of exchanges.

This is pretty vague statement for a standards track document.
What is such a 'reasonable time or number of exchanges'?


Section 6.2.2., paragraph 2:

>  Proposing a value not admissible (e.g., not within the specified
>  bounds) MAY be answered with the constant "Reject" or the acceptor
>  MAY select an admissible value.

  I'm not sure about the MAY here, as this reads as this MUST
be answered either with "Reject" or an admissible value. It is not
an option to just forget the answer, isn't it?


Section 6.2.2., paragraph 4:

>  For a numerical range the value selected must be an integer within
>  the proposed range or "Reject" (if the range is unacceptable).

  must -> MUST?


Section 6.4., paragraph 3:

>  If the target responds to a Text request with the F bit set to 1
>  with a Text response with the F bit set to 0, the initiator should
>  keep sending the Text request (even empty) with the F bit set to
>  1, while it still wants to finish the negotiation, until it
>  receives the Text response with the F bit set to 1. Responding to
>  a Text request with the F bit set to 1 with an empty (no key=value
>  pairs) response with the F bit set to 0 is discouraged.

  The first 2 lines do not make sense to me, i.e., there is
something missing, probably a comma? Also, the term 'discourage' is
not a MUST or SHOULD. Can you clarify this?


Section 7.1.5., paragraph 10:

>  When either party attempts to use error recovery functionality
>  beyond what is negotiated, the recovery attempts MAY fail unless
>  an apriori agreement outside the scope of this document exists
>  between the two parties to provide such support.

  What does this paragraph mean? I would guess that it is
a clear failure if the above happens. Why is this handwaiving so
much?


Section 7.12., paragraph 6:

>      - During Login, any failure in negotiation MUST be considered
>        a login process failure and the Login Phase must be
>        terminated, and with it, the connection. If the target
>        detects the failure, it must terminate the login with the
>        appropriate login response code.

  S/must be terminated/MUST be terminated


Section 9., paragraph 1:

>  Historically, native storage systems have not had to consider
>  security because their environments offered minimal security
>  risks. That is, these environments consisted of storage devices
>  either directly attached to hosts or connected via a Storage Area
>  Network (SAN) distinctly separate from the communications network.
>  The use of storage protocols, such as SCSI, over IP-networks
>  requires that security concerns be addressed. iSCSI
>  implementations MUST provide means of protection against active
>  attacks (e.g., pretending to be another identity, message
>  insertion, deletion, modification, and replaying) and passive
>  attacks (e.g.,eavesdropping, gaining advantage by analyzing the
>  data sent over the line).

  This 'MUST' isn't that useful here, as there is no
word about how this is achieved. s/MUST/must/


Section 9.2., paragraph 2:

>  The authentication method cannot assume an underlying IPsec
>  protection, because IPsec is optional to use. An attacker should
>  gain as little advantage as possible by inspecting the
>  authentication phase PDUs. Therefore, a method using clear text
>  (or equivalent) passwords is not acceptable; on the other hand,
>  identity protection is not strictly required.

  'not acceptable' does this mean 'MUST NOT'?


Section 11.3.1., paragraph 14:

>  Setting both the W and the F bit to 0 is an error.

  what exact type of error?



Section 11.4.3., paragraph 9:

>    A non-zero response field indicates a failure to execute the
>    command in which case the Status and Flag fields are undefined.

What about saying this:  '...undefined and MUST be ignored when received'?


Section 11.4.5.1., paragraph 1:

>    The Residual Count field MUST be valid in the case where either
>    the U bit or the O bit is set. If neither bit is set, the Residual
>    Count field is reserved. Targets may set the residual count and

  reserved means, MUST be ignored on reception and SHOULD be
set to 0 when sending?


Section 11.5.1., paragraph 9:

>      8    - TASK REASSIGN - reassigns connection allegiance for the
>          task identified by the Initiator Task Tag field to this
>          connection, thus resuming the iSCSI exchanges for the task.

  What's up with the remaining values of 'Function'? Should they
be reserved?


Section 11.12.4., paragraph 1:

>    The version number of the current draft is 0x00. As such, all
>    devices MUST carry version 0x00 for both Version-min and Version-
>    max.

  Is it intentionally to have the same version number as
RFC 3720?



Section 13.23., paragraph 2:

>  Default is RFC3720.

  How can RFC 3720 be the default, if this memo is
obsoleting RFC 3720?


Appendix C., paragraph 1:

>  To reduce the amount of configuration required on an initiator,
>  iSCSI provides the SendTargets text request. The initiator uses
>  the SendTargets request to get a list of targets to which it may
>  have access, as well as the list of addresses (IP address and TCP
>  port) on which these targets may be accessed.

  Is appendix C normative? It uses 'MUST' and therefore it
looks normative but it is not stated here. Please add a statement
whether it is normative or not.
2012-06-12
05 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2012-05-23
05 Martin Stiemerling State changed to AD Evaluation from Expert Review
2012-03-29
05 Martin Stiemerling Responsible AD changed to Martin Stiemerling from David Harrington
2012-03-16
05 Martin Stiemerling Ballot writeup was generated
2012-02-03
05 David Harrington Request for Early review by TSVDIR is assigned to Spencer Shepler
2012-02-03
05 David Harrington Request for Early review by TSVDIR is assigned to Spencer Shepler
2012-02-03
05 David Harrington State changed to Expert Review from Publication Requested.
tsvdir
2012-01-12
05 Cindy Morgan
PROTO writeup:
                      iSCSI Protocol (Consolidated)
                  …
PROTO writeup:
                      iSCSI Protocol (Consolidated)
                    draft-ietf-storm-iscsi-cons-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 and a co-author
of the draft.  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) 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?

Yes - the document updates the iSCSI profile of IPsec to include IPsec v3
(4300-series RFCs).  The security directorate has already designated a
well-qualified reviewer for this draft, Paul Hoffman, co-chair of the
ipsecme WG.  The document shepherd will work with the SecDir reviewer
to ensure that this concern is addressed in the Sec-Dir review.

  (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 a single
consolidated iSCSI spec and the minor updates contained in this draft.

  (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 generates a number of comments that do not represent
actual problems with the draft.

        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-sam-05, for
which an RFC publication request is being submitted along with the
publication request for this document.

In addition, this document normatively references five SCSI standards
that have been developed by INCITS Technical Committee T10 (www.t10.org),
namely SAM2, SAM3, SAM4, SBC and SPC3.  As completed standards, these
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 IANA Considerations
are clear and do not require any actions by IANA.

  (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

  This document describes a transport protocol for SCSI that works
  on top of TCP. The iSCSI protocol aims to be fully compliant with
  the standardized SCSI Architecture Model (SAM-2). RFC 3720
  defined the original iSCSI protocol. RFC 3721 discusses iSCSI
  Naming examples and discovery techniques. Subsequently, RFC 3980
  added an additional naming format to iSCSI protocol. RFC 4850
  followed up by adding a new public extension key to iSCSI. RFC
  5048
offered a number of clarifications and a few improvements and
  corrections to the original iSCSI protocol.

  This document obsoletes RFCs 3720, 3980, 4850 and 5048 by
  consolidating them into a single document and making additional
  updates to the consolidated specification. This document also
  updates RFC 3721 and RFC 3723. The text in this document thus
  supersedes the text in all the noted RFCs wherever there is a
  difference in semantics.

    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 changes are clearly
  specified, and are not expected to be significantly disruptive to add to
  existing implementations.
2012-01-12
05 Cindy Morgan Draft added in state Publication Requested
2012-01-12
05 Cindy Morgan [Note]: 'David Black (david.black@emc.com) is the document shepherd.' added
2012-01-12
05 David Black IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2012-01-12
05 David Black Publication requested (finally!)
2012-01-12
05 David Black Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2012-01-12
05 David Black Changed protocol writeup
2012-01-10
05 (System) New version available: draft-ietf-storm-iscsi-cons-05.txt
2012-01-02
05 David Black Reference citation problems found by idnits requqire a revised I-D before RFC publication can be requested.
2012-01-02
05 David Black Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2011-12-15
05 David Black Waiting for writeup
2011-12-15
05 David Black IETF state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2011-12-15
05 David Black Waiting for writeup
2011-12-15
05 David Black Annotation tags Revised I-D Needed - Issue raised by WGLC, Waiting for Referenced Document cleared.
2011-11-27
05 David Black Needs a minor change to definition of I_T Nexus
2011-11-27
05 David Black Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2011-11-21
05 David Black Waiting for revised version of new features (SAM) draft.
2011-11-21
05 David Black Annotation tag Waiting for Referenced Document set. Annotation tag Revised I-D Needed - Issue raised by WGLC cleared.
2011-10-31
04 (System) New version available: draft-ietf-storm-iscsi-cons-04.txt
2011-09-30
05 David Black IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2011-09-30
05 David Black WG Last Call finished
2011-09-30
05 David Black Annotation tag Revised I-D Needed - Issue raised by WGLC set.
2011-07-27
05 David Black In Last call
2011-07-27
05 David Black IETF state changed to In WG Last Call from WG Document
2011-07-08
03 (System) New version available: draft-ietf-storm-iscsi-cons-03.txt
2011-03-14
02 (System) New version available: draft-ietf-storm-iscsi-cons-02.txt
2011-03-07
05 (System) Document has expired
2010-09-03
01 (System) New version available: draft-ietf-storm-iscsi-cons-01.txt
2009-12-16
00 (System) New version available: draft-ietf-storm-iscsi-cons-00.txt