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

["Mallikarjun C." <cb_mallikarjun at yahoo.com>]

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 <pkoning at equallogic.com>
To: cb_mallikarjun at yahoo.com
Cc: ips at ietf.org
Sent: Thursday, January 4, 2007 1:11:51 PM
Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status


>>>>> "Mallikarjun" == Mallikarjun C <cb_mallikarjun at yahoo.com> 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
Ips at ietf.org
https://www1.ietf.org/mailman/listinfo/ips