|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Comments on v12 of iSCSI SpecificationMy comments are in line. Bob Barry > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, May 05, 2002 12:33 PM > To: BARRY,BOB (HP-Roseville,ex1) > Cc: 'ips@ece.cmu.edu'; owner-ips@ece.cmu.edu > Subject: Re: Comments on v12 of iSCSI Specification > > > > Thanks for tanking your time to do such a thorough review. > > my comments in text -Thanks again - Julo > > The following comments are submitted against the April 17, 2002, > draft-ietf-ips-iSCSI-12.txt. > > Bob Barry > ==================================================== > > General Comments > 1) An acronym section would make it easier to read > this document. Acronyms such as SW for session > wide, IO for initialize-only, and others are not > immediately obvious. > +++ If you volunteer to do it, I will volunteer to review it > and add it > with proper acknowledgements +++ > An acronym section is attached. This is the list of acronyms that I found in v12 of the spec. A special thanks to Michael Fischer of Adaptec for the starting list. > 4) Each table should be numbered and titled. Currently, > there is no way to reference an individual table, accept > a page number which may change over revisions. > > +++ All references - are made with a tool that takes care of it. I am thinking about references to tables in the spec by developers/users. It would help if the table had numbers or titles. > > > 3) p 31: second paragraph, sixth line, how the > parathesized example applies to the preceding > sentence is not immediately obvous. > +++ wht do you suggest? +++ I spoke with Mallikarjun about this and he has some ideas. > > 6) p 36: third paragraph, third line: the sentence ends > right in the middle; need to complete the thought. > +++ I can't locate it - context would help ++ Sorry, I meant second paragraph, third line: "is negotiated at login as the. A target . . ." > 15) p 118: section 9 - why are some bits marked as reserved > and some marked as '0' or '1' in the PDU definitions. If > the bits marked as '0' or '1' in the PDUs will > never change, > then this needs to be stated. In other words, there are > not treated the same as reserved bits. > > +++ ??? +++ Some bits in the PDUs are explicitly defined to be '1' or '0'. In the wording, some fields are declared as reserved (or '.'), which must have a value of '0'. It is my understanding that the reserved bits could change in the future, but that bits explicitly defined to be '0' or '1' cannot change. Is this true? If true, then why won't the defined bits change?
Home Last updated: Mon May 13 13:18:27 2002 10093 messages in chronological order |