Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0H0N8T11660 for ips-outgoing; Thu, 16 Jan 2003 19:23:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0H0N6W11655 for ; Thu, 16 Jan 2003 19:23:06 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7F4CC3070E; Thu, 16 Jan 2003 19:23:05 -0500 (EST) Date: Thu, 16 Jan 2003 16:18:35 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Cc: Subject: RE: iSCSI extension algorithms (was no subject) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C7A6@corpmx14.us.dg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 16 Jan 2003 Black_David@emc.com wrote: > 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#. Take care, Bill