Re: iSCSI - working draft and IANA

["Mallikarjun C." <cbm@rose.hp.com>]

As I already said, I think we should register both 
    - all the current text keys (for the reasons David states below)
    - any future non-X# keys (same argument)

I agree with David that additionally assigning a numeric 
identifier to a string identifier (key name) we already have doesn't
seem like an appealing prospect. 
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: <Black_David@emc.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, July 30, 2002 2:45 PM
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
> ---------------------------------------------------
>