RE: iSCSI - working draft and IANA

[pat_thaler@agilent.com]

RE: "We may also want to reserve/restrict the use of underscore
	('_') to continue the convention that for AuthMethod <foo>,
	the keys that negotiate its parameters are named <foo>_* ."

We don't need to restrict '_' as long as use values of <foo> that 
don't begin with X, Y or Z.

Pat

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, July 30, 2002 2:45 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - working draft and IANA


Several comments on this topic:

- The IANA text in the working draft is going to need some
	expansion.  IANA will want explicit instructions on how
	to manage the registries, as IANA does *not* have
	a single or default set of procedures for this purpose
	and hence needs instructions on what is to be done.
	See RFC 2434.

- The rationale for the X/Y/Z prefixes is to avoid losing key
	and value names to vendor registration that we might like
	to use in the future - future RFCs would be able to define
	new key and value names without problems, because we wouldn't
	us those prefixes.  The # prefix ensures that registered
	and unregistered vendor-specified names can't conflict.
	Both of these are important (e.g., the X- format for
	vendor-specific keys is not going away at this stage).
	If the # character is objectionable, a possible alternative
	is that registered values MUST NOT contain a period ('.')
	and unregistered values MUST contain a period ('.') between
	the first and second components of the reversed domain name.
	We may also want to reserve/restrict the use of underscore
	('_') to continue the convention that for AuthMethod <foo>,
	the keys that negotiate its parameters are named <foo>_* .

- The reason for creating a registry for existing keys is that
	it would provide a single point of reference in the future as
	new keys get added to iSCSI.  Right now this doesn't matter, but
	down the road, after a few RFCs add several new keys, having one
	place to look could be quite convenient.  A number of things
	have been put into IANA registries after the fact as it was
	subsequently discovered that such a registry would be useful
	(e.g., the IP protocol number [IPv4/IPv6] is in such a registry).

I may need to volunteer to help with the IANA text - it doesn't
have to be perfect to Last Call the draft as long as for each
registry, two things are clear:

- The criteria for registration - the things that someone who
	wants to register something has to present to IANA.
- How IANA handles registration requests, including reasons for
	rejection and requirements for review.

I'm not sure about Mark Bakke's suggestion to number newly registered
authentication/digest algorithms for MIB usage vs. having the MIB use
the strings.  In practice, the string is what names these algorithms,
so using numbers seems to create an additional opportunity to get the
algorithm (string) to number mapping wrong.

Thanks,
--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
---------------------------------------------------