iSCSI: IANA issues (DLB T.38 and T.39)

[Black_David@emc.com]

In looking at Julian's proposals to deal with my
comments on the IANA text, I ran into some issues
that need attention on the list.  

 [T.38] 12. IANA Considerations

   The temporary (user) well-known port number for iSCSI connections 
   assigned by IANA is 3260.

 Delete "temporary (user)" insert "TCP" before "port number" or add
 instructions for IANA to allocate a system port when this draft is
 approved to become an RFC - I think just sticking with 3260 is better.

Julian's working draft instructs IANA to allocate a system port.
My opinion is that 3260 isn't broken, doesn't need to be fixed,
and asking IANA to allocate a system port at the unpredictable
point in the future when the IESG has approved iSCSI and it's
gotten far enough down the RFC Editor Queue for IANA to do its
thing seems unnecessary and a possible invitation to confusion.
What do other people think?

 [T.39] 12. IANA Considerations

 If vendor additions of values to existing keys is to be allowed
 (e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed
 for each set of values - see [T.32] and [T.34], or the reversed DNS
 convention needs to be extended from keys to values - the latter doesn't
 sound like a good idea.

Julian's response was to wonder whether an IANA registry is necessary.

First of all, there is a problem here - for example, if two different
vendors assign the key value CRC64K to two different CRC algorithms,
the resulting nasty interoperability failure is unacceptable.
I think the options are either to require a reversed domain name in
every vendor-specific key value, or use an IANA registry.  Short vendor-
specific key values without the X-<reversed domain name> prefix are
probably going to require an IANA registry, and that creates a few
complications.

The one issue that *must* be resolved now is that new key values for
AuthMethod will need related new keys (e.g., the new vendor-specific
GRUMPY authentication method may need new GRUMPY_AX, GRUMPY_FOO, and
GRUMPY_RES keys).  We could disallow this and force all new vendor
specific keys to use the X- format.  Alternatively, it's probably
sufficient to require that such keys MUST start with the IANA-registered
AuthMethod value followed by an underscore; this ensures that
they don't conflict with each other or with keys we might want to
define in the future.  It does allow for value conflicts - e.g.,
once a vendor has registered the GRUMPY AuthMethod value, we can't
use GRUMPY for some other algorithm.

If we don't use an IANA registry, the X- format of vendor specific
keys corresponds well with using reversed domain names in vendor-
specific key values (e.g., AuthMethod=X-com.foo.GRUMPY, and later
X-com.foo.GRUMPY_AX= ...).

An issue that we could settle now or defer is whether to ensure
that vendor-specific key values don't consume strings that we
might want to use later.  This is only a problem with an IANA
registry, as any key value containing a reversed domain name
will contain a period and the key values we're likely to define
won't use a period.  A similar rule that could be used with
an IANA registry could be to require that every vendor-specific
key value contain an embedded underscore (or be prefixed and
suffixed by an underscore? or some other distinguishing prefix?).
The result might be that the new AuthMethod value is GRUMPY_1.

I think the high-level issue is whether to use the X- format for
vendor-specific key values (and keys) or whether to use an IANA
registry to allow more compact values (and related keys).

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------