Re: iSCSI Implementer's Guide - WG Last Call status
Paul Koning <[email protected]>
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "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 _______________________________________________ Ips mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ips