Subject: Re: iSCSI - working draft and IANA

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 1 Aug 2002 06:45:49 -0700

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
[email-masked]

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
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
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 2 Aug 2002 09:28:10 +0300

Reading the proposed text would help the discussion.
The extended keys are supposed to have an X# in front to avoid any 
colision with current or future versions of iSCSI.

Julo

Bill Studenmund <[email-masked]>
07/31/2002 12:18 AM

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     Steve Senum <[email-masked]>, <[email-masked]>
        Subject:        Re: iSCSI - working draft and IANA

On Tue, 30 Jul 2002, Julian Satran wrote:

> Registering the current keys is an issue already raised by Mallikarjun.
> The only think I can comment about is that I don't see what we stand to
> gain (and I can cleraly see the  pain!).

I think what we stand to gain is that then the IANA folks know what has
already registered, so that someone can't register a name in the spec.
Or so that the spec can't later start using names already registered.

This discussion is assuming that the space open for IANA registration is
not contrained to exclude keys already in the spec.

Take care,

Bill