Subject: Re: iSCSI - working draft and IANA

From: "Julian Satran" <[email-masked]>
Date: Tue, 30 Jul 2002 03:40:19 +0300

Mallikarjun,

You don't have to register keys that start with X-, Y- and Z- (I think the 
text is clear).
As for the current key I am not sure I understand the point. We are 
registering only the aprt following the # 

Julo

"Mallikarjun C." <[email-masked]>
07/29/2002 11:33 PM

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

Julian,

I like the general idea, a couple of comments.

- I assume that it's still the case that new RFCs can define new keys
  without any of the (X#, Y# and Z#) prefixes, if the proposed keys
   are expected to be broadly useful (i.e. beyond a "group of vendors").
   If that's true, then should they be registered into the IANA registry
   as well?

- It appears that the text only appears to require a registry for all
  new keys, but not for what's defined in the iSCSI draft today.  It
  may be useful to include currently defined keys as well, so there's 
  one repository for all keys.  I hope it doesn't lead to any technical 
  delays for the current draft....

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

----- Original Message ----- 
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 28, 2002 6:05 AM
Subject: iSCSI - working draft and IANA

> Dear colleagues,
> 
> The current (today's) version of the draft has a revised IANA 
consideration
> section
> and specific  indication on how to build keys, authentication methods 
and
> digests.
> 
> David Black suggested that we might want to go for 3 different 
registries
> maintained by IANA for iSCSI
> and I liked the idea.
> 
> Please comment,
> Julo
> 
>

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 30 Jul 2002 11:48:02 -0700

Mark,
Please explain about the need to register the current ones, what will that
buy us?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Mark Bakke <[email-masked]>@ece.cmu.edu on 07/30/2002 10:52:20 AM

Sent by:    [email-masked]

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

Julian-

I'm not sure I see the need for registering keys, but that
aside, if we register digest and auth methods I would suggest
that we also register an integer method number with each; this
will make it easier to add them to the MIBs.  I would also
suggest that we register the current ones as well as any
extensions.

--
Mark

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!).
>
> As for the prefixes - they are aimed at clearly delineating what is
mandatory (key defined in the
> basic iSCSI doc) from vendor or group=of-vendors additions.
>
> The registration is meant to allow groups of vendors to agree on a key
and provide a semantic doc
> (an RFC that can be informational).
>
> Julo
>
>   Steve Senum <[email-masked]>
>                                            To:        Julian
Satran/Haifa/IBM@IBMIL
>   07/30/2002 01:48 AM                      cc:        [email-masked]
>                                            Subject:        Re: iSCSI -
working draft and IANA
>
>
>
> Julian,
>
> 1. I would suggest registering all the current iSCSI keys, auth methods,
> and digests with the IANA, with references to the iSCSI RFC (when
published),
> and dropping the X#, Y#, and Z# prefixes.  This would be more consistent
> with how I have seen this done in the past.
>
> 2. I am not sure I really see the need.  In other cases, this is done
> to allow vendor specific registrations, but we already have a mechanism
> for that (the X- prefix).  Note that there is no reason why a vendor
> can't defined a vendor specific key in an informational RFC.
>
> Regards,
> Steve Senum
>
> Julian Satran wrote:
> >
> > Dear colleagues,
> >
consideration
and
registries

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Tue, 30 Jul 2002 17:45:03 -0400

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: [email-masked]
Date: Wed, 31 Jul 2002 15:06:14 -0600

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: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 30, 2002 2:45 PM
To: [email-masked]
Subject: RE: iSCSI - working draft and IANA

Thanks,
--David

---

From: [email-masked]
Date: Wed, 31 Jul 2002 18:46:41 -0400

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2002 5:06 PM
> To: [email-masked]; [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Aug 2002 02:21:10 +0300

I agree - Julo

Mark Bakke <[email-masked]>
Sent by: [email-masked]
07/30/2002 08:52 PM

Julian-

--
Mark

The only think I can
cleraly see the  pain!).
Satran/Haifa/IBM@IBMIL
published),
consideration
and
registries

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054