| Newsgroups |
gmane.ietf.ips |
| Message-ID |
<F222151D3323874393F83102D614E055068B8AAB@CORPUSMX20A.corp.emc.com> |
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
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Mallikarjun C. [mailto:[email protected]]
> Sent: Thursday, December 28, 2006 12:03 AM
> To: [email protected]
> 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 <[email protected]>
> To: [email protected]
> 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." <[email protected]>
> To: "Eddy Quicksall" <[email protected]>
> Cc: <[email protected]>; "Julian Satran" <[email protected]>
> 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 <[email protected]>
> To: Mallikarjun C. <[email protected]>
> 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." <[email protected]>
> To: <[email protected]>
> 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 <[email protected]>
> To: [email protected]
> 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
> [email protected]
> 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
> [email protected]
> 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
> [email protected]
> 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
>
>
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips