|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] ISCSI: comments on iSCSI 14.Here are my working group last call on the iSCSI document. This was a review of version 14 of the document. All page and section numbers refer to that document. All comments are my own as an individual contributor, as opposed to WG co-chair. Thanks, Elizabeth Rodriguez Technical 1) Acknowledgements, pg 3, para 3 This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR What about the requirements doc, string profile, SLP and iSNS? Think the first should be present in this list; not certain about the others in this list in particular. 2) Section 2.2.1. p. 34, last paragraph iSCSI targets and initiators MUST support at least one TCP connec- tion and MAY support several connections in a session. For error recovery purposes, targets and initiators that support a single active connection in a session may have to support two connections during recovery. The may in the last sentence (...session may have...) needs to be "MAY need". Assuming MAY, since if the device only supports ErrorRecoveryLevel 0, will not need to support multiple connections. 3) Section 2.2.2.1 p 36, para 2, line 3 Immediate commands can be rejected by the iSCSI target due to lack of resources. Believe the 'can' needs to be a MAY, due to the fact that the initiator must be able to support the target rejecting the immediate command. 4) section 2.2.2.1, pg 36, para 3 With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. Commands marked for immediate delivery may be handed over by the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some commands for execution if required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management request received before all the commands on which it was supposed to act). Delivery for execution means delivery to the SCSI execution engine or an iSCSI-SCSI protocol specific execution engine (e.g., for text requests). a) may needs to be MAY. "Commands marked for immediate delivery may" b) may needs to be MUST in "iSCSI may avoid"..., since cannot deliver immediate command prior to the command execution itself. Alternatively, can change paragraph to state something to the effect of "Commands marked for immediate delivery MUST be handed over by the iSCSI target layer for execution as soon as detected, unless required not to by a prior SCSI or iSCSI action..." 5) section 2.2.4, pg 41, para 2 For an iSCSI request issued over a TCP connection, the corresponding response and/or requested PDU(s) MUST be sent over the same connec- tion. We call this "connection allegiance". If the original connec- tion fails before the command is completed, the connection allegiance of the command may be explicitly reassigned to a different transport connection as described in detail in Section 6.1 Retry and Reassign in Recovery. a) Since an exception follows the MUST, probably should note that here, e.g. following "same connection" add "(connection allegiance) unless a connection failure has occurred and connection allegiance has been reassigned. " and delete the following sentence. b) may in last sentence should be MAY -- connection allegiance of the command may be ... 6) Section 2.2.6.1, pg 44, bullet b b) iSCSI names must be permanent. An iSCSI initiator or target has the same name for its lifetime. Recommend this be changed to ...iSCSI initiator node or target node... 7) Section 2.2.6.3.2, pg 48 The IEEE Registration Authority provides a service for assigning glo- bally unique identifiers [EUI]. The EUI-64 format is in use as a global identifier in other network protocols such as Fibre Channel. See http://standards.ieee.org/regauth/oui/index.shtml - for more information on registering for EUI identifiers. Fibre Channel does not support the EUI-64 directly. Instead, it has a method of encoding an EUI-64 into the WWN. But I know of no place that Fibre Channel uses an EUI-64 directly. 8) Section 2.2.6.3.2, pg 49 Should a caution be added to this section on use of EUI format, since names are not tied to HW. Actuall applies to both formats, so maybe should go in 2.2.6.3. 9) Section 2.2.8.2, pg 51, para following table An implementation may choose to place Sync and Steering somewhere else in the stack... May should be MAY. 10) Section 2.2.8.2, pgs 51-52 The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end address within the stream for every delivered iSCSI PDU. To enable the Sync and Steering operation to perform Steering, addi- tional information, including identifying tags and buffer offsets, MUST also be retained for every sent PDU. The Sync and Steering Layer is required to add enough information to every sent data item (IP packet, TCP packet or some other superstructure) to enable the receiver to steer it to a memory location independent of any other piece. This paragraph needs to be clarified. Sync and steering is optional -- on both send and receive? Is this negotiated somewhere if sync and steering is being used? We have an optional function that has MUSTs associated with it. 11) Section 4.2, pgs 72- Talk about F and T bits through-out this section, but no description of what F and T bits are, no intro, does not point to further information. 12) Section 6, pg 103, para 2 It is further assumed that a target will keep the "status & sense" for a command it has executed if it supports status retransmission. Wording should be changed to something along the lines of "If OPTIONAL status retransmission is supported, (or better yet, since status retransmission only occurs as part of ErrorRecoveryLevel 2, correct?, "If ErrorRecoveryLevel 2 is supported, ) then the device MUST keep status and sense data for a previously completed command." This then leads to the question "For how long must this data be kept around?" Some multiple of Time2Wait or Time2Retain?. 13) Section 6.1.2, p. 104 In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of Exp- DataSN field provided by the Task Management Function Request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. However, targets MAY choose to send/receive the entire data on a reassignment of connection allegiance, and it is not considered an error. For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately. This might possibly involve retransmission of data/R2T/status PDUs as nec- essary. The SHOULDs and MAY need to be re-examined. The paragraph indicates that the command SHOULD be continued from its current state but that it MAY instead choose to send/receive the entire data reassignment, and it will not be in error. That seems to contradict the SHOULD that precedes it. Perhaps change the two SHOULDs in this statement to lower case should. 14 Section 6.1.2, p. 104, last para It is optional for targets to support the allegiance reassignment. This should be OPTIONAL. 15. Section 6.12.3, pg 114 There are MUSTs/SHOULDs/MAYs listed in this section that are only valid if Connection Recovery is supported. While this is noted elsewhere, it needs to be noted in this section as well. 16) Section 7.2, pg 119 During login the target authenticates the initiator and the initia- tor optionally authenticates the target. The authentication is per- formed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method. Since this is a requirement, think this should be "During login the target MUST authenticate the initiator. The Initiator MAY OPTIONALLY authenticate the target." 17) Section 8.1.1, pg 124 To both minimize the disruption of legacy applications and to better facilitate the SCSI features that rely on persistent names for SCSI ports, iSCSI implementations should attempt to provide a stable pre- sentation of SCSI Initiator Ports (both to the upper OS-layers and to should needs to be SHOULD, since this is a requirement. 18) Section 8.1.1, p. 125 In other words, the same ISID should be used in the Login process to multiple target Again, needs to be SHOULD, since this is a requirement. 19) Section 8.1.2, p. 125 For targets, because of the closed environment, implementation of this entity should be straightforward. However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets, should provide mechanisms for configuration of the iSCSI Node Name across the por- tal groups instantiated by multiple instances of these components within a target. Should needs to be SHOULD. 20) Section 8.1.2, p. 126 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in the initiators must allow Since a requirement, must needs to be MUST. 21) 9.1, pg. 130 iSCSI PDUs are padded to the closest integer number of four byte words. The padding bytes SHOULD be 0. Needs to be a MUST instead of a SHOULD 22) 9.2, pg. 131 All PDU segments and digests are padded to the closest integer num- ber of four byte words - i.e., all PDU segments and the digests start at a four byte word boundary and the padding ranges from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. Needs to be a MUST instead of a SHOULD. 23) Section 9.2.1.2, pg. 132 Initiators MUST NOT use target opcodes and targets MUST NOT use ini- tiator opcodes. Do we need a note here indicating that a single device may function in both roles, but must adhere to the rules applicable to each role as independent entities? 24) Section 9.4.6 iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. Contains needs to be changed to "MUST contain" 25) Section 9.5.1, p 148 The TARGET WARM RESET function MAY also be subject to SCSI access controls (see [SPC3]) on the requesting initiator Change 'MAY' to 'is'. This is a SCSI function, not an iSCSI one. It is subject to SCSI access controls. 26) Section 9.5.1, p. 148 When executing the TARGET WARM RESET and TARGET COLD RESET func- tions, the target cancels all pending operations. Should add "across all logical units" of the target device". May also want to add strong warning on Target Reset functions. 27) Section 9.6.1, p 152 For the TARGET COLD RESET and TARGET WARM RESET functions, the tar- get cancels all pending operations. Should add "across all logical units" of the target device". 28) Section 9.7.2, pg. 156 Need to add statement to this section that states "the A bit MUST NOT be set in any sessions in which the ErrorRecoveryLevel is 0". 29) Section 9.7.3 On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1. This is only applicable if the ErrorRecoveryLevel is set to 1 or greater. This should be noted. Also, what action should be taken (error returned, termination, etc) if the A bit is set, and the ErrorRecoveryLevel is 0? 30) Section 9.11.1, pg. 172 A Text Response with the F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. The 'may' should be eliminated. 31) Sections 9.14.1, 9.14.2, pg. 175 Recommend some change here. As of this version of the document, the only value that may be used for either Version-Max or Version-Min is 0x00. That is not clear here. 32) Section 9.14.1, pg 189 If the tasks terminated in any of the above cases are SCSI tasks, they MUST be internally terminated with CHECK CONDITION status with a sense key of unit attention and ASC/ASCQ values of 0x6E/0x00 (COM- MAND TO LOGICAL UNIT FAILED). Note that this status is meaningful only for appropriately handling the internal SCSI state aspects such as queued commands because this status is never communicated back as a terminating status to the initiator. I believe this MUST should be a lower case should. This is defining internal SCSI behavior, not iSCSI behavior. If the SCSI and iSCSI device are self contained, the device may be able to address the issue in some other manner, and should not be in violation of the specification for internal behavior. 33) 9.16.1, pg. 194 Advisable to come up with table, related to ErrorRecoveryLevels/recovery mechanisms as defined in 6.12, that indicates which of these SNACK functions MAY be supported and which are REQUIRED to be supported at the various ErrorRecoveryLevels/mechanisms.. E.g. DataACK is required for ErrorRecoveryLevel 1, but Status ACK only seems to be required for ErrorRecoveryLevel 2, further qualified to if it supports within connection recovery. Q: ErrorRecoveryLevel2 is comprised of both within Connection and Within Command recovery, correct? Is there any relationship as to how these are supported. E.g. is within-connection recovery support required for within-command recovery? Vice Versa? Must both be supported at ErrorRecoveryLevel2? 34) Section 9.16.1, p 195 An iSCSI target that does not support recovery within connection MAY reject the status SNACK with a Reject PDU. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indi- cates "Request Logout". If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached). This section needs clarification. SNACK support is required for ErrorRecoveryLevels 1 and 2. DataACK is required for recovery level 1 & 2 (see 2nd para). The 1st paragraph seems to indicate that if ErrorRecoveryLevel 1 only is supported, the target may reject the status SNACK, so that means that Status SNACK may be supported at level 1, but not required? 35) Section 10.1, pg. 205 The authentication exchange authenticates the initiator to the tar- get, and optionally, the target to the initiator. Authentication is not mandatory to use but must be supported by the target and initia- tor. Need a MUST here instead of must. 36) Section 10.5, pg 209 To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. The SHOULD needs to be changed to MUST. 37) Section 11.7, pg 214 If an initiator has been configured with a human-readable name or description, it may be communicated to the target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an identifier, but can be displayed by the target's user interface in a list of initiators to which it is connected. This key SHOULD be sent by an initiator within the Login Phase, if available. First paragraph indicates may be communicated. Second indicates it SHOULD be communicated. Change first paragraph to ". it SHOULD be communicated. 38) Section 11.12, pg 217 The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or target must state its desire to do so. ImmediateData can be turned on if both the initia- tor and target have ImmediateData=Yes. Believe must needs to be a MUST. 39) Section 11.12, pg. 217 If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in the first burst. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code. If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. The above are the expected actions of the combination of InitialR2T and Immediate Data. Need to clarify that, either in this section, or move these examples elsewhere. In other words, prior to this set of statements, put in a statement something to the following. "ImmediateData and InitialR2T(see 11.10) settings result in the following possible operations data flow: Editorial 1. General - For the version to be submitted to the IESG, we need to make sure the formatting in the txt version is good. Not sure what you are using to generate txt version, erratic in format, especially spacing. 2) (nice to haves) a) Number figures and tables. b) Generate table of figures and table of tables following table of contents. 3. Sync and Steering/Synch and steering. Need consistency. Some places have Sync and Steering, where as other have Synch and steering. Consistent spelling for sync needed. 4. Abstract The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. The current version of iSCSI is 0. EGR: The last sentence needs clarification. I know that for version numbers, we are currently using 0. But, it does not really make sense in the contect of the abstract. 5. Acknowledgements a) NuSpeed is now Cisco. b) Believe Paul Koning spells his name as listed here. Believe he is with EqualLogic. c) This document has to be considered together with the "Naming & Dis- covery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and FCIP"[SEC- IPS] documents. EGR: Suggested rewording to "In addition to this document, the following must be considered in order to get a full understanding of the iSCSI specification", then list documents. Insert "iSCSI" before "Naming & Discovery" Should be "Bootstrapping Clients using the iSCSI Protocol" instead of "Boot" Security draft name change to "Securing Block Storage Protocols over IP" d) We are grateful to all them for their good work and for helping us correlate this document with the ones they produced. EGR: Insert "of" between "to all" and "them" 6) Change Log EGR: This section needs to be eliminated once we get through WG last call, prior to forwarding to IESG. 7) Section 1.2 Acronyms, pg 28 Gbps - GigaBits per Second. EGR: Do not believe B should be capitalized in GigaBits. 8) Section 2.1, pg 32, para 3 SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request ser- vice from a logical unit. The "device server" on the logical unit accepts SCSI commands and processes them. EGR: Since define clients here as initiators, and cannot find similar association for targets, recommend that you add a sentence after ..."called "initiators".", such as: Servers of a SCSI interface are called "Targets". Might also want to put in a description similar to what is in the security draft that the concept of clients and servers and resources associated with each is not necessarily the same in the storage world as it is in many other areas. 9) section 2.2.6.2, p 45, 1st line in 2nd to last para Note that in most cases, the Stringprep process does not need to be implemented if the names are generated using only lower-case (any character set) alpha-numeric characters. Stringprep should be lower case. 10) section 2.2.6.3, p. 47, para 2 The type designator strings that may currently be used are: Change to "The type designator strings currently defined are". Think may in the current sentence is too weak, since one of the two MUST be used, as defined in following paragraph. 11) section 4.2, pg 70, iSCSI-local-name-value Typo -- nul should be null. 12) Section 4.2.1, pg 72, para 1 However, None is a valid selection only if it is explicitly offered. Need "" around None. 13) Section 5.1. pgs 87-94 Decipher of state diagrams in sections 5.1.1 and 5.1.2 without 5.1.3 is virtually impossible. Confused as to why transition numbers were missing, until saw 5.1.3. Recommend either moving section 5.1.3 move before 5.1.1, or adding intro on layout 14) Is there a reason for a blank page 117? 15) Section 7, pg 118 Although technically possible, iSCSI SHOULD NOT be configured with- out security. iSCSI without security should be confined, in extreme cases, to closed environments without any security risk. Suggestion: Add "configured" between "iSCSI" and "without" in second sentence. Though correct, this stresses the configured part, since mandatory to implement. 16) Section 7.2.2, pg 121, para 1 Well- known SRP Extraneous '-' 17) Section 7.3, pg. 121 Carriage Return missing prior to this section 18) section 9.5.1, p 148, para 4 Extraneous carriage return 19) Section 11.8, pg. 215 If the TCP port is not specified, it is assumed to be the IANA- assigned default port for iSCSI (3260) Since the default port number may be changed in the future, recommend referring to the IANA considerations section for the default port number, so that it needs to be updated in a single location in the future, if it is changed 20) Full Copyright Statement. Need to add the following boilerplate: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." Per Allison, this can be added directly to the end of the Full Copyright Statement.
Home Last updated: Mon Jul 08 01:18:51 2002 11167 messages in chronological order |