Re: [storm] iSCSI: Protocol extension items

[<[e-mail]>]

<Draft co-author hat on>

Thinking more about this ...

> 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

RFC 6648 recommends against both X- and V-, so there's little value to that change.

Applying the "ain't broke, don't fix it" principle, it becomes hard to justify
a cosmetic change from X- to V-.  Hence I strongly suggest that we not do item
1, and instead, just leave the X- private keys as-is, and explain that namespace
separation has been working fine for iSCSI.

Assuming that we get rid of the X#, Y# and Z# formats, the larger issue is
that we would then have a very high hurdle for "registration" of experimental
and testing parameters, namely Standards Action plus a namespace structure that
requires names that will be even uglier to standardize if a private text key
(or other extension item) needs to go into widespread use without a name change.

One possibility would be to change the criteria for IANA registration of
authentication methods, digests and Login/Text keys from the current "Standards
Action" (standards track RFC required) to either "IETF Review" (IESG must 
approve, including an IETF Last Call, Informational or Experimental RFC is
ok) or "RFC Required" (adds ability to use an independent submission to the
RFC Editor).  See RFC 5226 for details.

It looks like "IETF Review" may be a good choice that reflects the limited need
(so far) for these values, but provides more flexibility than requiring a standards
track RFC.  FWIW, I believe that this is roughly what's done to add crypto
algorithms to IPsec (the resulting documents are often published as Informational
RFCs).

Thoughts?

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Friday, June 29, 2012 2:57 PM
> To: [e-mail]
> Cc: Black, David
> Subject: iSCSI: Protocol extension items
> Importance: High
> 
> <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]
> ----------------------------------------------------
>