Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 4 Jan 2007 14:44:34 -0800 (PST)

Paul,

Agree with everything you wrote.

RFC 3720 does not require sane reactions to non-sane inputs.  This draft should not say anything that suggests target/initiator may draw sane interpretations to non-sane inputs either.

Sounds like an agreement to not add any new text to me.

Mallikarjun

----- Original Message ----
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Thursday, January 4, 2007 1:11:51 PM
Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

Mallikarjun> Ken, I think the concern here is that whatever text we
Mallikarjun> put in could easily be misinterpreted as granting the
Mallikarjun> target implementation the freedom to "properly
Mallikarjun> understand" the initiator's intent, when the problem is
Mallikarjun> that the initiator's intent is either fuzzy or plain
Mallikarjun> confusing from the PDU contents and the target does not
Mallikarjun> really know what the "proper intent" is.

I think we've been here before.

To me the answer is very simple.  If an initiator obeys the protocol
rules, it is entitled to see behavior specified by the RFC.  If it
violates the rules, it is not entitled to anything.

A target MAY check for protocol violations, but (unless the RFC
specifically requires it, which it should only do for strong reasons)
it is under no obligation to check.  If it checks, then the initiator
will probably see a fairly clean reaction to a protocol error (for
example a disconnect, or a reject of some sort).  If the target
doesn't check, a faulty initiator may see undefined behavior.

Ditto in the other direction (swap "initiator" and "target" in the
above). 

Requiring "sane" reactions (however one might define those) to
non-sane inputs is not a good thing to ask for.  It imposes
substantial overhead on good implementations, and it only benefits bad
implementations.

    paul

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: Paul Koning <[email-masked]>
Date: Thu, 4 Jan 2007 18:00:44 -0500

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 Mallikarjun> Paul, Agree with everything you wrote.

 Mallikarjun> RFC 3720 does not require sane reactions to non-sane
 Mallikarjun> inputs.  This draft should not say anything that
 Mallikarjun> suggests target/initiator may draw sane interpretations
 Mallikarjun> to non-sane inputs either.

Great summary.

 Mallikarjun> Sounds like an agreement to not add any new text to me.

Well, Eddy raised the issue a while back that some people writing
conformance tests were interpreting "initiator must do X" as "target
must check that initiator does X".  That's clearly an incorrect
conclusion.  But given that people make this mistake, I wonder if a
note in the guide saying "unless RFC 3720 specifically requires it, an
implementation is not required to do protocol conformance checking on
incoming message", or something like that, would be helpful.

      paul

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 5 Jan 2007 11:25:10 -0500

I remember long ago talking about this when we were developing the RFC. I 
remember some people clearly saying that if the RFC said "must do X" then it 
meant that the peer "must check X". I didn't pursue the issue because it 
seemed to be of little importance.

But as time went on and the draft got finalized, I ran into cases where that 
view was still taken to hart. Of course "the customer is always right" so I 
added checks.

More recently I thought that since this guide was being written that maybe a 
simple statement could be made to clarify the issue.

I'm not debating the issue of the importance of making a check or even the 
criteria for making the check.

Eddy

---

From: Julian Satran <[email-masked]>
Date: Fri, 5 Jan 2007 15:27:47 -0500

Eddy,

It was stated here several times already that the general rule in RFCs is 
that sender has to be strict and the receiver lenient.
It is however really difficult to say what exactly lenient means (as it is 
very much dependent on implementations). The rules are stated in terms of 
what a sender must do.
It is also obvious that draft authors would be reluctant to make a blanket 
statement of the receiver not being manadated to check (as in some case 
that might be blatantly incorrect). Just to give you an example - would it 
be acceptable to say that a sender has to put a correct CRC in the frame 
but the receiver is free not to check it ?
A blanket statement like the one you requested would cover such a 
behaviour too (that would be obviously incorect). Perhaps a statement 
along the lines of what Paul suggest ed with  the caveat -"as long as it 
does not violate an explicit rule" should be enough.

Regards,
Julo

"Eddy Quicksall" <[email-masked]> 
05/01/07 11:25

To
"Paul Koning" <[email-masked]>, <[email-masked]>
cc
[email-masked]
Subject
Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

I remember long ago talking about this when we were developing the RFC. I 
remember some people clearly saying that if the RFC said "must do X" then 
it 
meant that the peer "must check X". I didn't pursue the issue because it 
seemed to be of little importance.

But as time went on and the draft got finalized, I ran into cases where 
that 
view was still taken to hart. Of course "the customer is always right" so 
I 
added checks.

More recently I thought that since this guide was being written that maybe 
a 
simple statement could be made to clarify the issue.

Eddy

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 5 Jan 2007 18:47:25 -0500

Yea, what Paul suggested is also what I suggested in the beginning. If that is ok then do you still think it would help clear things up?

I also go along with what Mallikarjun said and David seemed to back up ... that we should probably go over the MUST's and see which are actually needed (I think that is what he meant).

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] ; [email-masked] ; Paul Koning 
  Sent: Friday, January 05, 2007 3:27 PM
  Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

  Eddy, 

  It was stated here several times already that the general rule in RFCs is that sender has to be strict and the receiver lenient. 
  It is however really difficult to say what exactly lenient means (as it is very much dependent on implementations). The rules are stated in terms of what a sender must do. 
  It is also obvious that draft authors would be reluctant to make a blanket statement of the receiver not being manadated to check (as in some case that might be blatantly incorrect). Just to give you an example - would it be acceptable to say that a sender has to put a correct CRC in the frame but the receiver is free not to check it ? 
  A blanket statement like the one you requested would cover such a behaviour too (that would be obviously incorect). Perhaps a statement along the lines of what Paul suggest ed with  the caveat -"as long as it does not violate an explicit rule" should be enough. 

  Regards, 
  Julo 

        "Eddy Quicksall" <[email-masked]> 
        05/01/07 11:25 
       To "Paul Koning" <[email-masked]>, <[email-masked]>  
              cc [email-masked]  
              Subject Re: [Ips] iSCSI Implementer's Guide - WG Last Call status 

  Eddy

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 5 Jan 2007 18:49:05 -0500

Just another note on what you said below "it was stated here several times...". I know it has been in emails for a long time but I found that testers' don't use what is said in emails as a criteria. That is why I thought it would be good to add a statement.

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] ; [email-masked] ; Paul Koning 
  Sent: Friday, January 05, 2007 3:27 PM
  Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status

  Eddy, 

  Regards, 
  Julo 

       

  Eddy