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

["Mallikarjun C." <[e-mail]>]

Lars,

Thanks for the comments and sorry for the delay in getting back.

As far as volunteers for reviewing, we could request the contributors at the end of the document to review.  David may have already reviewed, based on his comments.  Julian Satran had some offline feedback for me on TMF topics.  As the editor of the document, I was sure that each of the topics were discussed in detail (or at least clearly noted) on the list before I included them in the doc.  Hope that gives you some reassurance.

>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.)

Yes, I'd appreciate if you could point out where you think additional clarifications could help.

> 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.)

We could.  My intent was to make it clear that this document prevails whenever a subtle interpretation in future of one of these RFCs differs from what's in this document.  Now that we are nearing the end of the work on this document, we could delete some although I personally am tempted to leave it this way....from what I can think of today though, this doc updates 3720 and 3721, but does not update 3722 and 3723.

3721 is not a standards-track RFC and I wasn't sure if it needs to be normatively cited as such.   But I could if that's the right thing to do.

>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?)

FIne by me.  How about "iSCSI Corrections, Clarifications, Additions and Implementation Guidance", or is it too long?  If it is, we could try "iSCSI Changes Based on Implementers' Experience" or something like it.

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

It actually does, with a MUST preceding the bulleted list....  As far as 3.3.1, I intentionally left the model description very generic with the hope that it can be incorporated into a future T10 spec verbatim.

> Nit: s/mult/multi-/

Done.

> 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.)

I left the "should"s intentionally in, because they really are the prerogatives of the initiator's run-time behavior, i.e. initiator may at his discretion choose to discard a message for some other reason (e.g. bad digest) beyond the 2119 protocol requirements. 

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

No, I don't think so. This bullet is all about waiting for missing CmdSN's.  It happens to have a different prescription for third-party affected sessions.

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

Done.

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

Done.

>iSER    Not cited.

It does now.

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

Fixed now.


Mallikarjun









----- Original Message ----
From: Lars Eggert <[e-mail]>
To: [e-mail]
Sent: Friday, December 1, 2006 4:57:59 PM
Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide


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


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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