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

<> Tue, 23 March 2010 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CECD3A692D for <>; Tue, 23 Mar 2010 15:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.844
X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NW942yoLkbCt for <>; Tue, 23 Mar 2010 15:28:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9160C3A68C0 for <>; Tue, 23 Mar 2010 15:28:48 -0700 (PDT)
Received: from ( []) by (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2NMT6KE011853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 18:29:06 -0400
Received: from ( []) by (RSA Interceptor); Tue, 23 Mar 2010 18:28:54 -0400
Received: from ( []) by (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2NMSsOU007723; Tue, 23 Mar 2010 18:28:54 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 18:28:54 -0400
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 18:28:52 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrKL8paRodDqgKHQVq2eNKhUajyAQASD8BAAAuYuMAABglLsAAGSzNg
References: <> <> <> <>
From: <>
To: <>, <>
X-OriginalArrivalTime: 23 Mar 2010 22:28:54.0322 (UTC) FILETIME=[38813920:01CACAD8]
X-EMM-EM: Active
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 22:28:49 -0000


I concur with your reasoning, example and strong desire for "MUST".

The newprep BOF is starting now - I'll report on results.


> -----Original Message-----
> From: Paul Koning []
> Sent: Tuesday, March 23, 2010 3:34 PM
> To: Black, David;
> Subject: RE: [storm] iSCSI and Unicode (newprep BOF)
> > > 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
that under the old rules were
> > > considered different must still be different.
> >
> > The "SHOULD" is there to a significant extent so that I can plead
> > 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
> > input string will need to map to a different newprep output string
> > stringprep output string for reasons involving Unicode.  If that's
> > 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  a
> > "MUST", as the IDN folks have much deeper knowledge of what's going
> > 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
> 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
> 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
> it to connect to Foo.  That initiator UI preps the string, which
> 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
> stored names with the new rules.  That works ONLY if (a) all
> valid names are still valid, (b) all previously distinct names are
> distinct.
> 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.
> 	paul