RE: [Ips] Re: iSCSI "compliance" text

[[e-mail]]

Eddy,

I think I agree with Mallikarjun on this.  If there is specific text
in RFC 3720 that says the recipient "MUST" check thus-and-such, we
could look at whether that check is really needed, and weaken the
text if it is not.  There's certainly nothing wrong with making the
checks - if the initiator "MUST" do <X>, then the target is entitled
to rely on <X> and complain if it isn't being done.  I hesitate to
discourage targets from making checks.  The two examples you cite:
	- Initiator uses wrong ITT value on data
	- Initiator sends immediate data when negotiation forbids it
are things that I think I'd prefer to have blow up in the initiator's
face sooner rather than later, as they could result in bad/wrong
data being stored if the target guesses wrong about how to compensate
for that initiator mistake.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Mallikarjun C. [mailto:[e-mail]] 
> Sent: Thursday, December 28, 2006 12:03 AM
> To: [e-mail]
> Subject: [Ips] Re: iSCSI "compliance" text
> 
> Eddy,
> 
> Even if we say it in the draft, it would be pretty generic 
> and will have no mandatory force.  So I do not see a lot of 
> value in attempting to state it in the draft.  Unless I get 
> other inputs and/or advise from David and Lars, I prefer not 
> to attempt to craft such a text.  I also suspect this is not 
> a case peculiar to iSCSI protocol, so I would welcome inputs 
> from other WG members.
> 
> Mallikarjun
> 
> 
> ----- Original Message ----
> From: Eddy Quicksall <[e-mail]>
> To: [e-mail]
> Sent: Thursday, December 21, 2006 9:20:14 AM
> Subject: Fw: [Ips] ips WG Last Call: iSCSI Implementer's Guide
> 
> 
> Sorry, I forgot to send this original request to the list.
> 
> What I'm thinking is to say this in the iSCSI Implementer's 
> Guide, if it is 
> not too late.
> 
> One of the problems I'm faced with is that our customers will 
> run 3rd party
> tests on a final product. If 3rd party test says "failed" 
> then the customer
> takes that to its word. I have found that many people think 
> that if the RFC
> says the initiator MUST then they think that means the target 
> MUST check to
> see that the initiator obeyed the rule (and visa versa) ... 
> some of the 3rd
> party tests are in that category.
> 
> Eddy
> 
> ----- Original Message ----- 
> From: "Mallikarjun C." <[e-mail]>
> To: "Eddy Quicksall" <[e-mail]>
> Cc: <[e-mail]>; "Julian Satran" <[e-mail]>
> Sent: Thursday, December 14, 2006 6:55 PM
> Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide
> 
> 
> I think I understand your question.  Generally, the IETF 
> philosophy is to 
> "be liberal in what you accept, be conservative in what you send" (my 
> paraphrasing of it, anyway) - so if your target wants to be 
> more forgiving, 
> I think that should be alright.
> 
> The UNH tests may be testing all MUST requirements - so in 
> your immediate 
> data example, the initiator must be held to this rule since 
> it initiates the 
> immediate data send.  On the target side, I see no harm in 
> turning off those 
> checks in your production code when you think you can 
> gracefully deal even 
> with a badly-behaving initiator.  On such occasions though, 
> you should be 
> sure to not flag SCSI protocol errors for those same iSCSI 
> protocol errors 
> that you had earlier forgiven.
> 
> Hope that helps.
> 
> Mallikarjun
> 
> 
> ----- Original Message ----
> From: Eddy Quicksall <[e-mail]>
> To: Mallikarjun C. <[e-mail]>
> Sent: Wednesday, December 13, 2006 4:17:37 AM
> Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide
> 
> 
> I know it is really late to ask this but I was wondering if 
> something could
> be done to relax some of the requirements for the target or 
> initiator to
> check for correctness of the protocol? For example, it could 
> be said that if
> the protocol error will not affect the operation of the 
> device then it is
> not necessary to check for the error.
> 
> I ask this because all of these checks during Full Feature 
> Phase can cause
> unnecessary performance degradation due to a check on every 
> command PDU even
> when the initiator or target have been previously qualified. 
> This is off the
> top of my head but one such check that comes to mind is the 
> check to be sure
> the ITT of data matches the ITT of the original command... we 
> have hardware
> acceleration and different types of memory with different 
> speeds. To cross
> check against the command requires saving additional information and
> accessing the slow memory (the fast memory is at a premium 
> and can't store
> enough information). Another is the requirement for the 
> target to check for
> immediate data received when immediate data was negotiated to 
> no (if the
> target can deal with it and the initiator can't but the 
> initiator negotiated
> it to no then the initiator should not send it anyway and 
> there should be no
> need to make the checks on every command).
> 
> Maybe some of these that I call "required checks" are 
> actually the result of
> a test program (such as the UNH test program) putting on the 
> "requirement".
> If so then a note in the guide may help to clear up that it 
> is not an error
> for the initiator or target to double check the peer.
> 
> I typed this kind of fast and I'm not a good linguist so if you don't
> understand then please let me know.
> 
> Eddy
> 
> ----- Original Message ----- 
> From: "Mallikarjun C." <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, December 11, 2006 12:34 PM
> Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide
> 
> 
> 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
> 
> 
> 
> ______________________________________________________________
> ______________________
> Want to start your own business?
> Learn how on Yahoo! Small Business.
> http://smallbusiness.yahoo.com/r-index
> 
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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