RE: iSCSI - working draft and IANA

[Black_David@emc.com]

Pat,

Sorry if I wasn't clear.  The rationale for reserving/restricting
the underscore would be to allow whomever defines/registers the
vendor-specific Gorilla (Z#Gorilla) AuthMethod to define/register
keys like Gorilla_Banana (X#Gorilla_Banana) and Gorilla_Bar
(X#Gorilla_Bar) if those are what naturally fit the Gorilla
algorithm without having to worry about those keys having been
previously defined/registered.  You're correct that there would
not be an issue if Gorilla were to be standardized and added to
iSCSI, as the unadorned Gorilla_* keys would be available to
the WG to do this, but my concern was for vendor-specific keys
needed by vendor-specific AuthMethod's.

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

> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Wednesday, July 31, 2002 5:06 PM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI - working draft and IANA
> 
> 
> 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
> ---------------------------------------------------
>