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

["Eddy Quicksall" <[e-mail]>]

There are two problems I have with your response to the examples:

1) for hardware to check the ITT ... it would take a lot of logic. For 
software to check it, it can take an external memory reference which could 
be a performance hit. If an initiator is going to use a bad ITT it will 
probably have even worse bugs that the target can't detect. For example, 
what if it uses the wrong ITT in the original command ... the target can't 
detect that.
2) for the immediate data case, if the target can handle it then why should 
it take the time on every single I/O to make the check?

Also, note that I'm not saying the targets/initiators are discouraged from 
making checks ... in fact I already stated that during login, where 
performance is not an issue, that the target/initiator is encouraged to make 
checks.

All I'm asking for is some simple text that clarifies that it is up to the 
target or initiator as to if a check should be made when the spec has not 
spelled it out. If the spec says MUST then clearly the check must be made.

Eddy

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Thursday, December 28, 2006 3:08 PM
Subject: RE: [Ips] Re: iSCSI "compliance" text


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 


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