Subject: Re: [storm] iSCSI: Protocol extension items

From: <[email-masked]>
Date: Mon, 2 Jul 2012 17:22:37 -0400

<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: [email-masked]
> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Thu, 5 Jul 2012 18:08:23 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 02, 2012 2:23 PM
To: [email-masked]; [email-masked]
Subject: Re: [storm] iSCSI: Protocol extension items
Importance: High

<Draft co-author hat on>

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

> changes are needed, describes what appears to be necessary and 
> summarizes the proposed detailed changes to requirements.
> 
> 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.
> 
> 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.
> 
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748

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

---

From: <[email-masked]>
Date: Thu, 5 Jul 2012 15:10:16 -0400

Mallikarjun,

Good - I think we can make it acceptable to the IESG ;-).  Specifically:

> 1, and instead, just leave the X- private keys as-is, and explain that
> namespace separation has been working fine for iSCSI.

I'm signing up to have this discussion with the IESG if we attract a DISCUSS on
this topic.  I think that discussion will boil down to three key points:

	1) "IETF Review" is good enough for the base namespaces wrt RFC 6648 and
		the strength of "IETF Review" is important to iSCSI's stability.
	2) At least for text keys, we clearly need an ability for individual
		implementers to define keys with a much lower bar than "IETF Review".
		That's what the X- prefix is for (and likewise for Y- and Z-).
	3) RFC 6648 suggests that we SHOULD allow X- prefixed text keys to be
		registered in the base key registry (requires "IETF Review") in
		order to avoid a name change for a key that becomes popular.
		We should do this (heck, we already have an X# key there, the
		X- keys with reversed domain names are not that much worse and
		are encouraged by RFC 6648), plus likewise for Y- and Z- items.

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

Those changes would also need to be reflected in the IANA Considerations
section, along with item 3) above, as I don't think IANA's picked them
up, and two of the registries are currently "RFC Required" (which is 
weaker/broader) courtesy of not having separate Y# and Z# registries.

I'll volunteer to help with the IANA Considerations text is my "copious
spare time" ;-), as IANA will need to be told exactly what is supposed to
change and how on this page:

	http://www.iana.org/assignments/iscsi-parameters/iscsi-parameters.xml

I may not be able to spend time on this until the first part of next week.

Thanks,
--David

> From: Mallikarjun Chadalapaka [mailto:[email-masked]]
> Sent: Thursday, July 05, 2012 2:08 PM
> To: Black, David; [email-masked]
> Cc: Martin Stiemerling ([email-masked])
> Subject: RE: iSCSI: Protocol extension items
> 
> David,
> 
> Regarding "IETF Review" requirement, I think we are already on that path.
> Section 5 in RFC 4850 already effectively makes these changes. Excerpt:
> 
> I was planning to bring these changes over into current text in consolidated
> draft, in my promised updates for this thread.
> 
> Mallikarjun
> 
> 
> 1, and instead, just leave the X- private keys as-is, and explain that
> namespace separation has been working fine for iSCSI.
> 
> 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.
> 
> 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
> 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
> 
>