Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C7A7@corpmx14.us.dg.com>
From: Black_David@emc.com
To: wrstuden@wasabisystems.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)
Date: Thu, 16 Jan 2003 19:29:38 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> > No, because the interop-by-default issue, and all of the text we're
> > discussing applies *only* to non-standard extension algorithms.  This
> > issue is part of a larger IESG "hot button" on prohibition of mandatory
> > vendor-specific extensions, hence getting a vendor-specific extension
> > standardized, even if it's a MAY, is enough to get it out from under
> > this set of requirements (as there's now a publicly available spec
> > on how to implement it).
> 
> Ok. And I assume the difference between not worrying about a new non-X
> method and worrying about an X# method is that the non-X method would have
> to be a standards-track RFC, while X# methods are informational only? Just
> making sure I understand it, since I thought you had to have 
> an RFC to get an X#.

Yes, modulo the likelihood that any new process like iSCSI public
extensions process will have hiccups and get debugged the
first time it's employed.  Also, for AuthMethod, the extension
keys are Z keys, not X keys ;-).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------