[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
iSCSI: draft-10 more editorial
Julian, The following are some more comments about the iSCSI draft 10 document. These are primarily editorial comments. Thanks, Nick As previously noted, the section numbers and page numbers are different between the text and pdf versions of the document. All my comments are based on the pdf version. Page 26 "Initiator that identifying elements, such as..." The word "that" does not fit. One of the words "unique", "defined", "specific" or "assigned" may have been intended, or perhaps it can just be removed. On page 33, The capitalization of the quoted keyword "None" is confusing "(literal constants which may include "None")". I have previously believed that keywords were case sensitive and that "none" (not "None") was the correct string. I note however that nearly all other keywords have been capitalized ("Reject", "NotUnderstood", etc.). For consistency with other keywords perhaps we should use "None". (As someone else noted, "yes" and "no" are also not currently capitalized.) On page 35, I presume the text "(up to the mode page limit)" is obsolete since iSCSI mode pages have been removed. On page 36 "It is also an error ..., than the SCSI limit for first burst." Should "SCSI" not be "iSCSI"? In the next sentence, which mentions "MAY request to send data blocks and a first burst of any size;..." This looks like it might have been a reference to 0 meaning any value which is now removed. On page 44, the sentence "During login, each end of the iSCSI session specifies the maximum iSCSI PDU size it will accept." This sounds like the PDU size could be negotiated differently in each direction. This is not how I think it works. On page 87, one paragraph starts with "LS:When". I presume the LS: should be removed. This may be more of an issue than editorial: On page 89, section 7.7 Negotiation Failures, I believe another reason needs to be listed. - The text request was answered with Irrelevant. Alternatively perhaps Irrelevant was added as a way to avoid sending a reject. If a negotiation ending in Irrelevant is to be considered a successful negotiation, this needs to be clearly stated. On page 115, in "than no more data PDUs are expected", "than" should be "then". On page 124, in the section Referenced Task Tag, ABORT TASK is referred to as TASK ABORT. On page 134, in the section R2TSN, the maximum number of R2Ts is given in hexadecimal 0xffffffff. In most other cases (like DataSN on page 131) the limits are expressed in decimal 2**32 or 2**32-1. The form 0xffffffff is generally used when specifying a reserved value. On page 141, for the list of characters valid in a text value, I would suggest also allowing the character '@' as would be used in e-mail addresses. On page 141, it is explained that binary items may be expressed in decimal, hex, or Base64. Are the protocol defined binary values, such as MaxRecvPDULength required to be accepted in all these formats? Request for clarification/restriction of text key=value continuations: Are there any special rules for text key=value pairs spanning PDUs? Is a pair of length less than MaxRecvPDULength permitted to span PDUs? Is the sender required to fill MaxRecvPDULength before continuing to the next PDU? Can a key=value pair which will require continuation begin somewhere in the middle of a PDU text buffer due to other key=value pairs already in the buffer? If so, can a key=value pair be continued before the "=" ? Is the text buffer to be continued required to fill a multiple of 4 bytes in the current text buffer (no padding required)? I would personally prefer to see key=value continuation restricted to cases where the key=value string exceeds MaxRecvPDULength. In other cases when the next key=value will not fit in the remaining space in the current PDU, one could put the entire key=value in the next text PDU. This would eliminate the possibility that one could be expected to correctly parse small strings such as ImmediateData=yes or MaxBurstSize=16384 with PDU breaks within them (MaxBurstSize=16<PDU-break>384). On page 149, in the section Login Parameters, the text appears contradictory. "All keys in Chapter 12, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Chapter 12, only need to be supported when the function to which they refer is mandatory to implement." On page 173, there is no section header (and number) for the beginning of CHAP protocol. On page 179, an example for TargetAlias uses an apostrophe (') although this is not among the permitted characters (on page 141). On page 181, InitialR2T has no section number. On page 184, LogoutLoginMaxTime has no section number.
Last updated: Mon Feb 11 01:18:02 2002
8720 messages in chronological order