[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 <Quicksall_iSCSI@Bellsouth.net>
To: ips@ietf.org
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." <cb_mallikarjun@yahoo.com>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
Cc: <black_david@emc.com>; "Julian Satran" <julian_satran@il.ibm.com>
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 <Quicksall_iSCSI@Bellsouth.net>
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>
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." <cb_mallikarjun@yahoo.com>
To: <ips@ietf.org>
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 <lars.eggert@netlab.nec.de>
To: ips@ietf.org
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
Ips@ietf.org
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
Ips@ietf.org
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
Ips@ietf.org
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
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips