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 |