|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Draft 04 remarksJulian, Some remarks (protocol and typos) for version 04: Section 1.2.3 says: “Any message except login and text reaching a target on a TCP connection before the full feature phase MUST be silently ignored by the target.” However, the reject message state the possibility for “full feature phase before login (15)” in section 2.20.1. I suggest changing it to: Any message except login and text reaching a target on a TCP connection before the full feature phase MAY be silently ignored by the target, or reported to the initiator by a reject message. Section 2.2 says “Each segment is preceded by a 4 byte Next-Qualifier.” Should be: Each Header Segment”. Data segment doesn’t need a qualifier. In section 2.4, the SCSI response scheme states the sense data as part of the BHS. It should be part of the AHS or the data segment. Section 2.4.2 says: “If a SCSI device error is detected while data from the initiator are still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a Data PDU with the F bit set before sending the Response PDU.” This means that any outstanding R2Ts must be closed before issuing a bad response. How can one set a timer for the end of data transfer in such a situation? The target might wait forever if it must wait for the data PDU before issuing a response. Besides, why wait for redundant data to reach the target when the target already knows that it is going to fail the command? In 2.4.2, a response status code is “3 - Unsolicited data rejected”. However, chapter 1 instructs a target to terminate the session if it experiences an initiator violating the agreed upon values for unsolicited data. Section 2.4.5: SR-length states the sense data length. However, if it is a data segment, it should be in the data length field in the WN. Section 2.7.3 says: “...or by the Target Task Tag and LUN (for data solicited through R2T).” Should clarify that the DataSN starts from 0 for each R2T. Section 2.7.5 says: “b7 P (poll)”, should be F bit - P was removed. Section 2.8.3 says: “If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target”. In previous chapter it was determined that not responding equal none. The phrase should combine these. 2.10.5 says that “CIDs MUST NOT be reused during the life of a session (every connection ever used in a session MUST have a unique CID)” but a Login Command with the retry bit, allows using the same CID. Section 2.11.4, redirections, says: “...All of the 3 status class”. Should be: “all of the Status-Detail responses MUST …”. In section 2.11.5, “A 0 in the returned TSID indicates that either the target supports only a single connection or that the ISID has already been used as a leading ISID.” Since we already have error codes (Status-Class/Status-Detail) it is much better to add the error using them instead of encoding it in the TSID field. Besides, this is an Initiator Error (class = 2) but we do not have a matching Status-Detail code. In section 2.12.2, “The LUN field MUST be set whenever the Target Transfer Tag is set”. This is a ping command, there are no LUNs in here. In 2.12.4, “The NOP-Out MUST have the Target Tag set only if it issued in response to a NOP-In or a Data-IN...”. Data In was removed, should only be for NOP In. And then “When the Target Transfer Tag is set the LUN field must have the correct value for the task.” Again, no LUNs required here. In section 2.14, “.On sessions with a single connection, this might imply opening a second connection with the sole purpose of cleaning-up the first.” This means that the logout command is sent on the same connection that is to be loged out. But the connection is bad (isn’t this the reason for closing it) so how can we send a command on a bad connection? Another thing is if we first logout the connection it means that the session has no connections hence it must be terminated. I think that since Login Command with a retry has been suggested this should be the only way to replace a connection. Section 1.2.3 says: “The target indicates a successful authentication and authorization by sending a login response with "login accept". Otherwise, it sends a response with a "login reject", indicating a session is not established.” Should be updated to the new statuses. Section 2.3.4 says”... this field will contain the last input DataSN number seen by the initiator”. If the initiator received packets 1,2 and 5, it should acknowledge just number 2 and not 5. Otherwise 3 and 4 will be considered as acked. Should be “the last DataSN in a sequence”. Also in 2.4.7. In 2.11, login response code should be 0x43 and not 0x83. Also says: “The Login Response indicates the end of the login phase.” Can also be partial response, so it does not necessary indicates the end of the phase. Section 2.4.8 says: “For responses sent because of retry the StatSN used MUST be the same as the first time the PDU was sent unless the connection was restarted since then.” This implies that a retry can be send on the same connection. However, this is what we have SACK now. Therefore, the protocol should define SACK for this purpose. Yaron
Home Last updated: Tue Sep 04 01:05:31 2001 6315 messages in chronological order |