[storm] iSCSI: Protocol extension items

[<[e-mail]>]

<WG chair hat on>

The recent publication of RFC 6648 requires that we make some changes
to negotiation of iSCSI protocol extensions.  This email explains why
changes are needed, describes what appears to be necessary and summarizes
the proposed detailed changes to requirements.

These proposed changes are to be made in the consolidated iSCSI draft,
and hence will apply to existing implementations. These proposed changes
should be backwards compatible with existing implementations, although
implementers should comment, especially on whether the migration from
X- to V- as the prefix for newly defined private extension text keys is
likely to cause problems.  An example of such a problem is - receipt
of a key using the V- format is likely to generate a protocol error
instead of a NotUnderstood response to the V- new key.

Existing X- private use text keys are *not affected* by these proposed
changes, and can continue to be used.

<WG chair hat off>
<Draft co-author hat on>

iSCSI currently allows extension text keys (for negotiation), digest
(checksum) algorithms and authentication methods to be defined using
X, Y and Z (respectively) as the first character of the identifier.
In each case, there are two defined formats, e.g., for text keys:

  X-reversed.vendor.dns_name.do_something  [dash-based]
  X<#><IANA-registered-string>             [hash-based]

The dash-based form (X-) is for private parameters, the hash-based
form (X#) is for public parameters registered with IANA.

RFC 6648 has recently been published.  To borrow a line from Sesame Street,
this RFC was brought to you by the letter X ;-). That RFC strongly recommends
against use of the letter X in this fashion for non-private parameters,
and similarly discourages analogous prefixes that do not contain the letter
X.  For iSCSI, RFC 6648 applies to the X#, Y# and Z# formats.

The history to date of use of the X#, Y# and Z# formats is that there has
been exactly one use, X#NodeArchitecture, which wound up being standardized
as a fully standard key.  That full standardization is an example of why
RFC 6648 recommends not using an X-based prefix for public parameters - if
the parameter is successful, it will become part of the standard. Hence the
proposed approach is to retire the hash-based formats (MUST NOT use) for
public extensions with the exception that the X#NodeArchitecture key needs
to be preserved.

It is still highly desirable to keep the dash-based formats (e.g., Y-) in
order to cleanly separate the private and public namespaces for each of these
extension items.  Among the reasons for doing so is that IANA is in the process
of authorizing a number of new top-level domains that will make it somewhat
harder to recognize a reversed domain name.

Nonetheless, in keeping with the spirit of RFC 6648, it seems prudent to
encourage use of a prefix other than X- for new text keys, without doing
anything to break current X- text keys.  V- is suggested as the new prefix
(V can be thought of a short for "vendor").  OTOH, if this will break existing
implementations, it's a bad idea (and we'll need to stick with X-) - see
the first part of this email.  

The following approach is therefore currently proposed:

1. Existing private X-keys may continue to remain private as before.
    However, new private keys SHOULD NOT use the X- prefix in keeping
    with [RFC6648]. Instead, new keys SHOULD start with a "V-" prefix,
    followed by a reversed domain name, e.g. V-com.example.do_something

    Note: If IANA registers something starting with V- as a new top
    level domain, this approach still works because the V- prefix is
    always added.  For example, if V-org is a new top level domain,
    an iSCSI text key for example.v-org would have the form
    V-V-org.example.do_something, which is clearly identifiable as
    a private extension key, even under case-insensitive character
    string processing.

2. Each new public key in the course of standardization MUST define the
    acceptable responses to the key, including NotUnderstood as
    appropriate. There is no need for a standard name prefix for keys
    that allow NotUnderstood response.  Note that NotUnderstood will
    generally have to be allowed for new public keys for backwards
    compatibility.

3. Thus the name prefix "X#" in new public key names does not carry any
    significance. New public key names MUST NOT begin with "X#" prefix
    to avoid confusion.

4. The existing public X# key - X#NodeArchitecture - will remain unchanged.

5. Based on our decade-long iSCSI usage experience, we know that Y# and
    Z# name prefixes, for digest and authentication method extensions
    respectively, were never used in practice. Similar to X# name prefix
    for keys, there is no need for this namespace separation either. So
    for the same reasons cited as for X# prefix, new digest and
    authentication method extensions MUST NOT respectively use Y# and Z#
    name prefixes.

6. Private digest and authentication method extensions can continue to
    respectively use Y- and Z- prefixes as in the current specification.

7. IANA will be requested to do the following:
	- Move X#NodeArchitecture to the iSCSI Login/Text Keys registry
	- Remove the iSCSI extended key registry
	- Not accept registrations of Y# extended digest algorithms or
		Z# extended authentication methods (and hence not create
		registries for these extension items).

Please comment, particularly on whether moving from X- to V- for new
text keys is likely to cause problems.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------