Re: iSCSI Implementer's Guide - WG Last Call status
"Mallikarjun C." <[email protected]>
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
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 protected]> To: [email protected] Cc: [email protected] Sent: Thursday, January 4, 2007 1:11:51 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status >>>>> "Mallikarjun" == Mallikarjun C <[email protected]> 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 protected] https://www1.ietf.org/mailman/listinfo/ips