Re: [storm] iSCSI: Protocol extension items

[Mallikarjun Chadalapaka <[e-mail]>]

David,

Thanks for the follow-up.

I'd be OK leaving X-keys intact, assuming that's an acceptable answer to IESG. 

Regarding "IETF Review" requirement, I think we are already on that path. Section 5 in RFC 4850 already effectively makes these changes. Excerpt:

   4) In Section 13.3, the description of allowed RFC types for
      extension items is changed from "The RFC may be informational
      rather than Standards-Track," to "The RFC MUST be standards track,
      experimental, or informational,"

   5) In Section 13.5.2, the phrase "standards track" is changed to
      "standards track or experimental" in the last sentence of the
      first paragraph, so that the sentence reads: "If the specification
      is a standards track or experimental document, the usual IETF
      procedures for such documents are followed."


I was planning to bring these changes over into current text in consolidated draft, in my promised updates for this thread.

Mallikarjun
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, July 02, 2012 2:23 PM
To: [e-mail]; [e-mail]
Subject: Re: [storm] iSCSI: Protocol extension items
Importance: High

<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]
> ----------------------------------------------------
> 

_______________________________________________
storm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/storm