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

<Paul_Koning@Dell.com> Tue, 12 June 2012 13:57 UTC

Return-Path: <Paul_Koning@Dell.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD821F85AC for <storm@ietfa.amsl.com>; Tue, 12 Jun 2012 06:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOSMqOtE9qoo for <storm@ietfa.amsl.com>; Tue, 12 Jun 2012 06:57:02 -0700 (PDT)
Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3521F859A for <storm@ietf.org>; Tue, 12 Jun 2012 06:56:58 -0700 (PDT)
X-Loopcount0: from 10.175.216.250
From: Paul_Koning@Dell.com
To: david.black@emc.com
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: <F87E413E-7F49-49F8-A439-4A593D3D0B18@Dell.com>
References: <CAEkHY=egdu9RNYojRq2jNSe1205VZxTa8fizM-sZaA8aGh_FNg@mail.gmail.com> <CAP_=6dL9DuqAWFJ-3dWOymO4kbdW_sRtyTUuZ4XEAwnvP3POOw@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71205813C92@MX15A.corp.emc.com> <E160851FCED17643AE5F53B5D4D0783A092D0294@BL2PRD0610MB361.namprd06.prod.outlook.com> <8D3D17ACE214DC429325B2B98F3AE7120707E7F1@MX15A.corp.emc.com> <BD5AC0B4-F616-46DE-B853-09F4320F5CD6@dell.com> <E160851FCED17643AE5F53B5D4D0783A18271843@BL2PRD0610MB361.namprd06.prod.outlook.com> <CDA1FE04-A12B-40D8-925B-16DFBE93BD07@Dell.com> <E160851FCED17643AE5F53B5D4D0783A18271863@BL2PRD0610MB361.namprd06.prod.outlook.com> <8D3D17ACE214DC429325B2B98F3AE7120707E8D5@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120707E8D5@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.175.217.62]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5F7D721A8DEB4C40818C3CA52E1323A4@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: storm@ietf.org
Subject: Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2012 13:57:03 -0000

On Jun 11, 2012, at 9:44 PM, <david.black@emc.com>
 <david.black@emc.com> 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.

	paul