Subject: RE: iSCSI: DLB [T.31]

From: "Julian Satran" <[email-masked]>
Date: Thu, 11 Jul 2002 03:24:09 +0300

The wording was changed to reflect operationallevel (not implemented 
level) 3 days ago!

Julo

[email-masked]
Sent by: [email-masked]
07/10/2002 10:56 AM
Please respond to Black_David

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        RE: iSCSI: DLB [T.31]

Steve,

>  From DLB's comments:
> 
>  >[T.31] 9.16.1  Type
>  >
>  >   An iSCSI target that does not support recovery within connection 
MAY
>  >   reject the status SNACK with a Reject PDU. If the target supports
>  >   recovery within connection, it MAY reject the SNACK after which it
>  >   MUST issue an Asynchronous Message PDU with an iSCSI event that 
indi-
>  >   cates "Request Logout".
>  >
>  > This should be conditioned on the operational ErrorRecoveryLevel of 
the
>  > session, not whether the target supports recovery within connection.
> 
> I would prefer that this not be conditioned on the ErrorRecoveryLevel. 
If
I 
> am writing code, I may choose to support recovery-within-connection, but 

> not all the features that would be required to move me up to 
> ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work 
properly 
> for my code, even though it is technically only "ErrorRecoveryLevel 
0.5".
>                As I read it, changing the wording would allow the target 
to ignore
my 
> improved error recovery efforts unless I have a full ErrorRecoveryLevel 
1 
> implementation. David, I doubt that is what you intended, so maybe you
want 
> to word it a little differently.

Actually, it was what I intended when I made that comment, BUT, I had not
considered the scenario you describe above ... and so, I now agree with
you.  Therefore I'll withdraw my [T.31] comment provided that the
possibility of multiple "ErrorRecoveryLevel 0.5" levels of support is
described in the overview section to be added on error recovery.

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: "Ambrish Verma" <[email-masked]>
Date: Thu, 11 Jul 2002 12:11:00 -0700

I have a doubt about CHAP sequence explained in draft. Under section
10.5 there is a description like :

"

   The target MUST answer with a Login reject with the "Authentication 

   Failure" status or reply with:

      CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>

   Where A is one of A1,A2... that were proposed by the initiator.

   The initiator MUST continue with:

      CHAP_N=<N> CHAP_R=<R>

 "

shouldn't it be like:

"

   The target MUST answer with a Login reject with the "Authentication 

   Failure" status or reply with:

      CHAP_A=<A> CHAP_C=<C>

   Where A is one of A1,A2... that were proposed by the initiator.

   The initiator MUST continue with:

      CHAP_R=<R>

"

because I think the identifier (CHAP_I) and name CHAP_N) are already an
integrated part of CHAP_C and CHAP_R (the way it is explained in
RFC1994).

Thanks

Ambrish

---

From: Steve Senum <[email-masked]>
Date: Thu, 11 Jul 2002 14:52:21 -0500

Hi Ambrish,

The CHAP sequence in the iSCSI draft is correct.
In RFC 1994, the CHAP_I and CHAP_C are seperate
fields sent in the same PPP PDU, but they are
still seperate fields, so in iSCSI Ofer and I
decided to send them as seperate iSCSI keys.

Regards,
Steve Senum

I have a doubt about CHAP sequence explained in draft. Under section 10.5 there
is a description like :

“

      CHAP_N=<N> CHAP_R=<R>

 “

shouldn’t it be like:

“

      CHAP_A=<A> CHAP_C=<C>

      CHAP_R=<R>

“

because I think the identifier (CHAP_I) and name CHAP_N) are already an
integrated part of CHAP_C and CHAP_R (the way it is
explained in RFC1994).

Thanks

Ambrish

---

From: "Ambrish Verma" <[email-masked]>
Date: Thu, 11 Jul 2002 12:59:12 -0700

Hi Steve,
     I understand what you are saying, In that case 

1) CHAP_N also happens to be the separate field, is it not required to
be sent by the authenticator to initiator?

2) If you go to the next statement in which it says like:
"
   The initiator MUST continue with:
      CHAP_N=<N> CHAP_R=<R>
"

  I think initiator is also required to return "CHAP_I" so shouldn't it
be like :

"
   The initiator MUST continue with:
      CHAP_N=<N> CHAP_R=<R> CHAP_I=<I>
"

Thanks
Ambrish

-----Original Message-----
From: Steve Senum [mailto:[email-masked]] 
Sent: Thursday, July 11, 2002 12:52 PM
To: Ambrish Verma; ietf-ips
Subject: Re: iSCSI: CHAP sequence

Hi Ambrish,

Regards,
Steve Senum

10.5 there
is a description like :

"

      CHAP_N=<N> CHAP_R=<R>

 "

shouldn't it be like:

"

      CHAP_A=<A> CHAP_C=<C>

      CHAP_R=<R>

"

 

Thanks

Ambrish

---

From: Steve Senum <[email-masked]>
Date: Thu, 11 Jul 2002 15:32:46 -0500

Hi Ambrish,

1) In iSCSI (and probably PPP) the CHAP_N field is only useful
   for the authenticator (as far as CHAP is concerned),
   so Ofer and I decided to only send it that way.

2) In PPP the CHAP_I field is used to match responses
   with requests, since a PPP PDU can be lost over the
   link and have to be resent.  In iSCSI that
   can't happen, since we use TCP, so Ofer and I decided
   to only send it with the CHAP_C, since it is needed
   to calculate the CHAP_R.

Keep in mind we are only using the protocol part of PPP CHAP,
and not the PPP specific encoding scheme.

Regards,
Steve Senum

---

From: "Ambrish Verma" <[email-masked]>
Date: Thu, 11 Jul 2002 14:30:34 -0700

yes now it makes perfect sense...

Thanks a lot
Ambrish

-----Original Message-----
From: Steve Senum [mailto:[email-masked]] 
Sent: Thursday, July 11, 2002 1:33 PM
To: Ambrish Verma; ietf-ips
Subject: Re: iSCSI: CHAP sequence

Hi Ambrish,

Regards,
Steve Senum