Re: iSCSI: SRP vs DH-CHAP

[Andre Hedrick <andre@linux-ide.org>]

Ted,

If this is fully adopted into T10 then it plays by NCITS rules.
Whom ever now owns or has controlling interest in Phoenix will have to
accept the rules set.  Since it is a SCSI/SAS transport, and iirc both are
under the guidelines of T10, so what if there is a royality fee.

The choice becomes data integity and security v/s whatever ...

Also for the most part iSCSI will be a commerial enterprise storage
feature, thus one expects to pay for what they get.  Additionally until
iSCSI has a means to do storage class independent access, few will move
from the top margin FCAL to another packet storage stack.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 4 Apr 2002, Theodore Tso wrote:

> On Thu, Apr 04, 2002 at 04:12:57PM -0500, David Jablon wrote:
> > 
> > Bill, it is not clear to me whether you will or won't "need to
> > license patents", although you may have a legitimate reason to be
> > concerned about the unknowns.
> 
> David,
> 
> I will note that you could help deal with some of the unknowns if you
> could convince your employers to either assert that they believe your
> patent covers SRP, or is willing to make a statement that the patent
> does not cover SRP.
> 
> The current wording:
> 
> 	This is to advise the IETF that Phoenix Technologies Ltd.
> 	("Phoenix") has U.S. Patent Number 6,226,383 that may
> 	relate to the IETF document RFC 2945 titled "The SRP
> 	Authentication and Key Exchange System".
> 
> ...is certainly cause of considerible uncertainty.  In fact, some on
> the IESG have called it a FUD letter.  (Personally, I believe we
> should never attribute to malice what can be attributed to a weaselly
> lawyer, but regardless, given such a letter, many people would assume
> that it would be necessary to license patents in order to use SRP.)
> 
> If you'd like to do your part to get this technology (which you claim
> is so wonderful) in wider use, perhaps you could do what you can to
> clear up some of the unknowns?
> 
> 						- Ted
>