Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C713@corpmx14.us.dg.com>
From: Black_David@emc.com
To: Nick.Martin@hp.com, Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)
Date: Wed, 8 Jan 2003 17:25:04 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Nick,

> I agree that an implementation which implements or includes only
> proprietary extension algorithm Z should be unacceptable.
> I am only questioning whether this paragraph acomplishes that goal.
> I am reading "offer" in the negotiation sense, not in the implemented
> feature set sense.

You're correct.  The "MUST implement" requirement for CHAP is elsewhere,
and applies no matter what; this paragraph is about negotiation when a
proprietary algorithm is involved.

> Although it makes little sense to me for the target which is configured
> with no CHAP secrets to "offer" CHAP during negotiation, I can accept it
> in this situation.  I would prefer to see implementation of CHAP listed
> as the requirement, rather than offering CHAP when it is not configured
> to work.

We'll keep that in mind in working out the final text.
 
> It seems now that it is not intended that to "offer" CHAP in negotiation 
> should be interpreted as an indication that CHAP is configured work.
> 
> I hope an implementation which can "offer" CHAP but does not implement
> CHAP, or one which can "offer" CHAP but does not allow CHAP to be
> configured by an administrator will also be unacceptable.

The former is definitely unacceptable, the latter should be - as far
as I'm concerned if the code is present but can't be used, it doesn't
count as implemented because I can't see evidence of the implementation
on the wire.

Thanks,
--David