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

["Paul Koning" <[e-mail]>]

> > 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 "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
a
> "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
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