[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: iSCSI Implementer's Guide - WG Last Call status



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 -----
Sent: Friday, January 05, 2007 3:27 PM
Subject: Re: 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" <Quicksall_iSCSI@xxxxxxxxxxxxx>

05/01/07 11:25

To
"Paul Koning" <pkoning@xxxxxxxxxxxxxx>, <cb_mallikarjun@xxxxxxxxx>
cc
ips@xxxxxxxx
Subject
Re: 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.

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

Eddy

----- Original Message -----
From: "Paul Koning" <pkoning@xxxxxxxxxxxxxx>
To: <cb_mallikarjun@xxxxxxxxx>
Cc: <ips@xxxxxxxx>
Sent: Thursday, January 04, 2007 6:00 PM
Subject: Re: iSCSI Implementer's Guide - WG Last Call status


>>>>>> "Mallikarjun" == Mallikarjun C <cb_mallikarjun@xxxxxxxxx> 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
>
>
> _______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
>


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux