|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iscsi: comments to iSCSI rev 6reply from Julian... -------- Original Message -------- From: julian_satran@il.ibm.com Subject: Re: iscsi: comments to iSCSI rev 6 To: Matt Wakeley <matt_wakeley@agilent.com> Comments in text. Thanks, Julo "Matt Wakeley" <matt_wakeley@agilent.com> on 01-05-2001 03:53:24 Please respond to Matt Wakeley <matt_wakeley@agilent.com> To: IPS Reflector <ips@ece.cmu.edu> cc: Subject: iscsi: comments to iSCSI rev 6 Section 2.2.3: The AHSLength field where it is requires RISC type processors to shift the length left by 8 bytes. +++ good point - I will make length the first field. +++ Section 2.3.5, 3rd paragraph: contradicts itself. First it states that a AHS header "MUST" be present, then goes on to define what the bi-di read length is if the header is not present. If it's not present, it's a protocol error. +++ will fix - it MUST be present +++ Section 2.4.1, last sentance: "b0-b3 MUST be 0" s/b "b1-b4 MUST be 0". +++ will fix +++ Section 2.7.7: why have residual bits/fields in a data PDU? If there is residual, then send a status PDU indicating the residual value. +++ residual counts are not necessarily errors. Interpretation is by target and many commands for undefined length transfer end having a residual count. The space is available in the header so I see no point in not sending the counts. SAM2 is somewhat ambivalent about overflow though. +++ Section 2.8.3: Keys not understood by the target should be expicitely indicated as not being understood. Silence is not a good way to indicate that one does not understand something. Also, something more ascii friendly such as a semi-colon (;) should be used to separate key-value pairs instead of a null (0x00) character. This would allow generic text manipulation libraries to be used. +++ generic text manipulation libraries use 0 as an end of string - our eyes don't :-) as for keys not understood the intent is to have new or vendor specific keys not interfering with the old or standrd only implementations +++ Section 2.9.3: why "MUST" key-value pairs be returned in the same order they were issued? Seems like a rather strong requirement for no apparent reason. +++ I've changed it into lower-case should +++ Section 2.12.3: indicate that the LUN is copied from the NOP-IN. This is much more clear than "the correct value for the task". +++ and open it up to strange thing like LU5 asking a nop-out to LU7 ? +++ Section 2.14: Why is there no CmdSN for the logout command? Also, 2 ways of performing the same operation (cleaning up) are stated in the 3rd paragraph. In the interest of reducing "options", I suggest that one be picked as the only method. +++ silly mistake - i've fixed it +++ Section 2.17.4: "The target assigns" should be "The target may assign". +++ ??? it always put something there +++ Section 6.3 & 6.7.2: why "MUST" a target reissue missing responses? What if it is not able to? There should be the option to reject the SNACK. +++ I am counting - you are number 2 +++ Appendix: "Initial Marker-less Interval" - I say again, there should not be a "minimum markerless interval". This should be whatever is negotiated. +++ The negotiation itself can't proceed if there are markers that nobody knows how to take out +++ -Matt Wakeley Agilent Technologies
Home Last updated: Tue Sep 04 01:04:48 2001 6315 messages in chronological order |