Re: [storm] iSCSI and Unicode (newprep BOF)

"Paul Koning" <> Tue, 23 March 2010 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 289433A69BE for <>; Tue, 23 Mar 2010 12:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.869
X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fFpsaiHL51Zq for <>; Tue, 23 Mar 2010 12:33:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1BA8E3A69B3 for <>; Tue, 23 Mar 2010 12:33:48 -0700 (PDT)
X-Loopcount0: from
X-IronPort-AV: E=Sophos;i="4.51,296,1267423200"; d="scan'208";a="438692335"
Received: from unknown (HELO ([]) by with SMTP; 23 Mar 2010 14:34:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Mar 2010 15:34:05 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrKL8paRodDqgKHQVq2eNKhUajyAQASD8BAAAuYuMAABglLsA==
References: <> <> <>
From: "Paul Koning" <>
To: <>, <>
Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Mar 2010 19:33:50 -0000

> > Re "Any update SHOULD be backward compatible with RFC 3722" -- I
> don't understand the "SHOULD".  The
> > obvious word is "MUST".  More precisely -- and maybe this is where
> the "SHOULD" came in? -- an IQN
> > that was legal under RFC 3722 must still be legal, and two names
> under the old rules were
> > considered different must still be different.
> The "SHOULD" is there to a significant extent so that I can plead "I'm
> not a Unicode expert" ;-).  At the iSCSI protocol level, I expect
> everything to be backwards-compatible because iSCSI names aren't
> checked for stringprep compliance on login (the iSCSI name string
> comparison for equality is basically opaque wrt Unicode issues).
> Moving up to the iSCSI name input level (human involvement), it is
> possible that things have changed in Unicode so that the same Unicode
> input string will need to map to a different newprep output string vs.
> stringprep output string for reasons involving Unicode.  If that's the
> case (and especially if some previously valid inputs have to be
> prohibited), then everything will need to be carefully explained and
> documented with advice on how to cope ... but I hesitate to lead with
> "MUST", as the IDN folks have much deeper knowledge of what's going on
> here, what needed to be done with Unicode domain names, and why (a
> "MUST" risks freezing iSCSI @ an old version of Unicode).

If so, then so be it.  I really do want MUST here.

Consider a simple example.  To avoid getting deep into Unicode, let's
use an ASCII analogy.  Let's say the old rule is that names are prepped
by tolower() and the new rule says they are prepped by toupper().  And
let's assume that this operation is done only when the target name is
mentioned in some management UI as you suggested.  (I think we might do
it also at login, but it doesn't actually affect the outcome of the
example in a way that matters.)

Ok, so in the old version, the admin asked me to create target Foo,
which I prepped to "foo", so we now have that target.  Next the user
tells the initiator to log in to Foo and the initiator preps that to
"foo" which comes across the login protocol exchange and all is well.  

Now we go to the new rule.  The admin sets up a new initiator, and tell
it to connect to Foo.  That initiator UI preps the string, which results
in "FOO".  That comes across in the login.  We do binary compare at
login time, so the result of the login operation is "no such target". 

You might think you can cure this problem by re-prepping all previously
stored names with the new rules.  That works ONLY if (a) all previously
valid names are still valid, (b) all previously distinct names are still

We clearly can't have a case where an existing iSCSI target becomes
inaccessible because of new name rules; this is my reason for saying
that any newprep changes MUST not have such an effect.