Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide

[Lars Eggert <[e-mail]>]

   Summary: Minor revision needed to address editorial issues. Note: I'm
   no iSCSI expert, so I cannot fully review the technical
   recommendations made in this document. I'd like to see at least one
   other review from someone who has the necessary background before  
this
   document moves forward - volunteers?

   Contains non-ASCII characters, boilerplate issues and other idnits.
   Please fix. Header should indicate that this document updates 3720
   and potentially other IDs (abstract already partially does - good!)

   It would be good if this document would state for each item it
   discusses, whether this is a clarification to the original RFCs or a
   correction, i.e., whether it is merely the original text that can be
   misunderstood or if there is a technical error in the original text.
   (It already does in some cases.)


INTRODUCTION, paragraph 1:
 >                         iSCSI Implementer's Guide

   Suggest to find a better title, because implementer's guides don't
   typically update the base specification in a normative way. (Maybe
   "iSCSI Corrections and Implementer's Guide" or something like that?)


Section 2, paragraph 2:
 >    iSCSI implementers are required to reference [RFC3722] and
 >    [RFC3723] in addition to [RFC3720] for mandatory requirements.
 >    In addition, [RFC3721] also contains useful information for
 >    iSCSI implementers.  The text in this document, however, updates
 >    and supersedes the text in all the noted RFCs whenever there is
 >    such a question.

   OK, so this document not only updates 3720, but also 3721, 3722 and
   3723? That needs to be stated in the document header and abstract.
   (Also, 3721 needs to be normatively cited in this case.)


Section 3.3, paragraph 0:
 > 3.3  SCSI Protocol Interface Model for Response Ordering

   The specification of the fence mechanisms should use RFC2119 terms,
   especially in Section 3.3.2.


Section 3.3.3, paragraph 4:
 >      2. The TMF Response carrying the mult-task TMF Response on the
 >        issuing session.

   Nit: s/mult/multi-/


Section 4.1.2, paragraph 4:
 >      b. Should receive any responses that the target may provide
 >            for some tasks among the affected tasks (may process them
 >            as usual because they are guaranteed to have
 >            chronologically originated prior to the TMF response).

   I'm not sure if "should receive" describes something that should be
   started in RFC2119 language or not. If that is the intent, a better
   phrasing should be found. (Also elsewhere in this document where the
   same phrasing is used.)


Section 4.1.2, paragraph 8:
 >      b. MUST wait (concurrent with the wait in Step.a) for all
 >            commands of the affected tasks to be received based on the
 >            CmdSN ordering.   SHOULD NOT wait for new commands on
 >            third-party affected sessions - only the instantiated  
tasks
 >            have to be considered for the purpose of determining the
 >            affected tasks.  In the case of target-scoped requests
 >            (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
 >            commands that are not yet received on the issuing session
 >            in the command stream however can be considered to have
 >            been received with no command waiting period - i.e. the
 >            entire CmdSN space up to the CmdSN of the task management
 >            function can be "plugged".

   Should the sentence starting with "SHOULD NOT" start a new item in
   this list?


Section 4.1.3, paragraph 8:
 >      a. MUST wait for all commands of the affected tasks to be
 >           received based on the CmdSN ordering on the issuing
 >           session.  SHOULD NOT wait for new commands on third-party
 >           affected sessions - only the instantiated tasks have to be
 >           considered for the purpose of determining the affected
 >           tasks.  In the case of target-scoped requests (i.e. TARGET
 >           WARM RESET and TARGET COLD RESET), all the commands that
 >           are not yet received on the issuing session in the command
 >           stream however can be considered to have been received with
 >           no command waiting period - i.e. the entire CmdSN space up
 >           to the CmdSN of the task management function can be
 >           "plugged".

   Should the sentence starting with "SHOULD NOT" start a new item in
   this list?


Section 11, paragraph 1:
 >   This draft does not have any specific IANA considerations other  
than
 >   those already noted in [RFC3720].

   Remove text after "considerations" to not confuse IANA. May want
   to add a note to the RFC Editor to remove this section upon  
publication.


Section 12.1, paragraph 1:
 >      [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka,
 >           M., and E. Zeidner, "Internet Small Computer Systems
 >           Interface (iSCSI)", RFC 3720, April 2004.

   Nit: Cited also as [RFC 3720], which confuses idnits. Remove the  
space
   in the other citations.


Section 12.2, paragraph 1:
 >      [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K.,
 >           and M. Krueger, "Internet Small Computer Systems Interface
 >           (iSCSI) Naming and Discovery", RFC 3721, April 2004.

   See above, if this ID updates 3721, it needs to normatively cite it.


Section 12.2, paragraph 2:
 >      [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,
 >           P., J. Hufferd, "iSCSI Extensions for RDMA", IETF
 >           Internet Draft draft-ietf-ips-iser-04.txt (work in
 >           progress),  June 2005.

   Not cited.


Section 12.2, paragraph 3:
 >      [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate
 >           Requirement Levels", BCP 14, RFC 2119, March 1997.

   ID does not include the required 2119 boilerplate. Also, 2119 should
   be cited normatively.

_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips