Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response

<> Tue, 12 June 2012 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAAD821F85AC for <>; Tue, 12 Jun 2012 06:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.599
X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oOSMqOtE9qoo for <>; Tue, 12 Jun 2012 06:57:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 06B3521F859A for <>; Tue, 12 Jun 2012 06:56:58 -0700 (PDT)
X-Loopcount0: from
From: <>
To: <>
Thread-Topic: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
Thread-Index: AQHNOXtOIIaCinNGykWqG66+HjtgdZbbOw+ggAecuICAEwDkAP//sNUggABa4AD//62tIIAAcLpAgAEkiAA=
Date: Tue, 12 Jun 2012 13:56:56 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 13:57:03 -0000

On Jun 11, 2012, at 9:44 PM, <>
 <> wrote:

>> FWIW, I did not believe both sides were compliant in this case.
> There's an additional consideration here - one of the goals of the iSER
> update is to match "running code", and we have already made a number of
> changes that diverge from RFC 5046 for this reason, including in this
> area of iSER start-up (see Appendix A of the iSER draft for details).
> As a result, we are  already well into non-compliance territory, as
> omission of the Hello messages does not comply with RFC 5046, but those
> messages are simply not implemented in practice.
> The implementation under discussion is (I believe) the predominant iSER
> implementation and hence I think the new iSER RFC needs to explain what
> that implementation has done (even if it may not be what should have been
> done), and (more importantly) explain how to interoperate.  The key
> requirement is the following (IMHO, a fine example of "be conservative
> in what you send"):
>>> 2) The target MUST wait at least 200ms (use some other number if 200ms
>>> isn't a good choice) or until it receives a full feature mode PDU from
>>> the initiator before sending a second unsolicited PDU in order to ensure
>>> that initiator has sufficient time to allocate the full feature buffer
>>> resources for the connection.

I don't understand how a protocol standard can have such language.  "200 ms (use some other number if...") is not a testable property.  If you delete the "(use...)" then you have  standard, or if you delete "at least... or" but as written, an implementer has no clue what is expected.