_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips =
mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0013_01C64755.97BF0B70--

--===============0472763966==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0472763966==--

From ips-bounces@ietf.org Tue Mar 14 11:05:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJC1k-0004Q4-Hl; Tue, 14 Mar 2006 11:05:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJC1j-0004Pq-UU
	for ips@ietf.org; Tue, 14 Mar 2006 11:05:39 -0500
Received: from e4.ny.us.ibm.com ([32.97.182.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJC1i-0005lQ-5w
	for ips@ietf.org; Tue, 14 Mar 2006 11:05:39 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2EG5Yw9015679
	for ; Tue, 14 Mar 2006 11:05:34 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2EG5Y7X145320 for ; Tue, 14 Mar 2006 11:05:34 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2EG5Y97022295
	for ; Tue, 14 Mar 2006 11:05:34 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2EG5YXk022292; 
	Tue, 14 Mar 2006 11:05:34 -0500
In-Reply-To: <001601c6477f$8450bbe0$08031eac@ivivity.com>
Importance: Normal
MIME-Version: 1.0
Sensitivity: 
To: "Eddy Quicksall" 
Subject: Re: [Ips] TMF for a write with only unsolicited data
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: 
From: Mike Ko 
Date: Tue, 14 Mar 2006 08:05:33 -0800
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 |
	February 28, 2006) at 03/14/2006 11:05:34,
	Serialize complete at 03/14/2006 11:05:34
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0052364791=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0052364791==
Content-Type: multipart/alternative;
	boundary="=_alternative 0058665D88257131_="

This is a multipart message in MIME format.
--=_alternative 0058665D88257131_=
Content-Type: text/plain; charset="US-ASCII"

Eddy,

There are 8 task management function codes listed in RFC3720.  They are 
Abort Task, Abort Task Set, Clear ACA, Clear Task Set, Logical Unit Reset, 
Target Warm Reset, Target Cold Reset, and Task Reassign.  If your example 
is not Task Reassign, what TMF code do you have in mind where unsolicited 
write data would be sent?

Mike
To:     "Mike Ko" 
cc:      
Subject:        Re: [Ips] TMF for a write with only unsolicited data

No. The case is not a TASK REASSIGN. It is for a write command where all 
of the data is unsolicited.

If the STag is used for the associated R2T's then it would seem WSV would 
be set to 0 when no R2T's were issued.

Further it says "The Write STag 
        Valid flag is set to one when there is solicited data to be 
        transferred"

Doesn't that mean the STag is only used if there was solicited data with 
the command?

Eddy
----- Original Message ----- 
From: Mike Ko 
To: Eddy Quicksall 
Cc: ips@ietf.org 
Sent: Monday, March 13, 2006 7:14 PM
Subject: Re: [Ips] TMF for a write with only unsolicited data

If I understand your question correctly, I assume the TMF is a TASK 
REASSIGN and it is for a write command qualified with DataDescriptorOut. 
DataDescriptorOut is used to describe the I/O buffer starting with the 
immediate unsolicited data (if any), followed by the non-immediate 
unsolicited data (if any) and solicited data.  A Write STag is allocated 
in this case.  The Write STag is used by the iSER layer at the target in 
handling the data transfer associated with the R2T PDUs and in returning 
the SCSI Response PDU using the SendInvSE message.  Since there is 
non-immediate unsolicited data, WSV is set to 1. 

Mike 
To:         
cc: 
Subject:        [Ips] TMF for a write with only unsolicited data 

Suppose: 
1) a TMF is not a TASK REASSIGN 
2) the TMF is for a write command 
3) the write command only has unsolicited data 

I think this is saying the WSV is set to 0 for this case. Is that correct? 

If so then I think the 3rd bullet item in 7.3.3 needs to say "if 
allocated" since a write with unsolicited only will also have a 
DataDescriptorOut. 

Or am I wrong in that the TMF would have the DataDescriptorOut for a write 
with only unsolicited data? 

   WSV - Write STag Valid flag: 1 bit 

        This flag indicates the validity of the Write STag field of the 
        iSER Header.  If set to one, the Write STag field in this iSER 
        Header is valid.  If set to zero, the Write STag field in this 
        iSER Header MUST be ignored at the receiver.  The Write STag 
        Valid flag is set to one when there is solicited data to be 
        transferred for a SCSI Write or bidirectional command, or when 
        there are non-immediate unsolicited and solicited data to be 
        transferred for the referenced task specified in a Task 
        Management Function Request with the TASK REASSIGN function. 

7.3.3  Task Management Function Request/Response 

   *  It MUST use the ITT as specified in the Referenced Task Tag from 
      the Task Management Function Request PDU to locate the existing 
      STag(s), if any, in the Local Mapping(s) that associates the ITT 
      to the local STag(s). 

   *  It MUST invalidate the existing STag(s), if any, and the Local 
      Mapping(s) that associates the ITT to the local STag(s). 

   *  It MUST allocate a Read STag for the I/O Buffer as defined by the 
      qualifier DataDescriptorIn if the Send_Control Operational 
      Primitive invocation is qualified with DataDescriptorIn. 

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0058665D88257131_=
Content-Type: text/html; charset="US-ASCII"

Eddy,

There are 8 task management function
codes listed in RFC3720.  They are Abort Task, Abort Task Set, Clear
ACA, Clear Task Set, Logical Unit Reset, Target Warm Reset, Target Cold
Reset, and Task Reassign.  If your example is not Task Reassign, what
TMF code do you have in mind where unsolicited write data would be sent?

Mike
To:      
 "Mike Ko"
<mako@almaden.ibm.com>

cc:      
 <ips@ietf.org>

Subject:    
   Re: [Ips] TMF
for a write with only unsolicited data

No. The case is not a TASK REASSIGN. It is for a write
command where all of the data is unsolicited.

If the STag is used for the associated R2T's then it would
seem WSV would be set to 0 when no R2T's were issued.

Further it says "The
Write STag 

        Valid flag is set to one when there is solicited
data to be 

        transferred"

Doesn't that mean the STag is only used if there was solicited
data with the command?

Eddy

----- Original Message ----- 

From: Mike
Ko 

To: Eddy
Quicksall 

Cc: ips@ietf.org

Sent: Monday, March 13, 2006 7:14 PM

Subject: Re: [Ips] TMF for a write with only unsolicited
data

If I understand your question correctly, I assume the TMF is a TASK REASSIGN
and it is for a write command qualified with DataDescriptorOut.  DataDescriptorOut
is used to describe the I/O buffer starting with the immediate unsolicited
data (if any), followed by the non-immediate unsolicited data (if any)
and solicited data.  A Write STag is allocated in this case.  The
Write STag is used by the iSER layer at the target in handling the data
transfer associated with the R2T PDUs and in returning the SCSI Response
PDU using the SendInvSE message.  Since there is non-immediate unsolicited
data, WSV is set to 1. 

Mike 
To:      
 <ips@ietf.org>

cc:         

Subject:        [Ips]
TMF for a write with only unsolicited data 

Suppose: 

1) a TMF is not a TASK REASSIGN 

2) the TMF is for a write command 

3) the write command only has unsolicited data 

I think this is saying the WSV is set to 0 for this case. Is that correct?

If so then I think the 3rd bullet item in 7.3.3 needs to say "if allocated"
since a write with unsolicited only will also have a DataDescriptorOut.

Or am I wrong in that the TMF would have the DataDescriptorOut for a write
with only unsolicited data? 

   WSV - Write STag Valid flag: 1 bit 

        This flag indicates the validity of the Write
STag field of the 

        iSER Header.  If set to one, the Write
STag field in this iSER 

        Header is valid.  If set to zero, the
Write STag field in this 

        iSER Header MUST be ignored at the receiver.
 The Write STag 

        Valid flag is set to one when there is solicited
data to be 

        transferred for a SCSI Write or bidirectional
command, or when 

        there are non-immediate unsolicited and solicited
data to be 

        transferred for the referenced task specified
in a Task 

        Management Function Request with the TASK REASSIGN
function. 

7.3.3  Task Management Function Request/Response 

   *  It MUST use the ITT as specified in the Referenced Task
Tag from 

      the Task Management Function Request PDU to locate
the existing 

      STag(s), if any, in the Local Mapping(s) that associates
the ITT 

      to the local STag(s). 

   *  It MUST invalidate the existing STag(s), if any, and the
Local 

      Mapping(s) that associates the ITT to the local STag(s).

   *  It MUST allocate a Read STag for the I/O Buffer as defined
by the 

      qualifier DataDescriptorIn if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorIn.

Eddy_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0058665D88257131_=--

--===============0052364791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0052364791==--

From ips-bounces@ietf.org Tue Mar 14 13:17:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJE4z-0008TY-M7; Tue, 14 Mar 2006 13:17:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJE3a-0007zX-7G
	for ips@ietf.org; Tue, 14 Mar 2006 13:15:42 -0500
Received: from sccrmhc11.comcast.net ([204.127.200.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDzF-0000vb-DE
	for ips@ietf.org; Tue, 14 Mar 2006 13:11:13 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (sccrmhc11) with SMTP
	id <20060314181108011009112se>; Tue, 14 Mar 2006 18:11:12 +0000
Message-ID: <003601c64792$afe3d860$08031eac@ivivity.com>
From: "Eddy Quicksall" 
To: "Mike Ko" 
References: 
Subject: Re: [Ips] TMF for a write with only unsolicited data
Date: Tue, 14 Mar 2006 13:11:12 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e52c6009a9b39871b75233310d7f3490
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1817369203=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1817369203==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0033_01C64768.C4A9EFC0"

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C64768.C4A9EFC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

So the paragraph below is saying the WSA would be 0 if the Abort Task =
were aborting a Write that had only unsolicited data. That is the way I =
read it too. You further said that for this case there would be no =
DataDescriptorOut with the TMF call from the iSCSI layer to the iSER =
layer. I think that is now clear. Thanks.

WSV - Write STag Valid flag: 1 bit=20

     This flag indicates the validity of the Write STag field of the=20
     iSER Header.  If set to one, the Write STag field in this iSER=20
     Header is valid.  If set to zero, the Write STag field in this=20
     iSER Header MUST be ignored at the receiver.  The Write STag=20
     Valid flag is set to one when there is solicited data to be=20
     transferred for a SCSI Write or bidirectional command, or when=20
     there are non-immediate unsolicited and solicited data to be=20
     transferred for the referenced task specified in a Task=20
     Management Function Request with the TASK REASSIGN function.=20

  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Sent: Tuesday, March 14, 2006 12:58 PM
  Subject: Re: [Ips] TMF for a write with only unsolicited data

  Ergo, there is no DataDescriptorOut, and therefore no unsolicited data =
associated with the issuance of the Abort Task TMF.=20

  Mike=20
  To:        "Mike Ko" =20
  cc:        =20
  Subject:        Re: [Ips] TMF for a write with only unsolicited data=20

  The TMF doesn't send any data. The TMF is aborting a task that has =
only unsolicited data.=20
  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Sent: Tuesday, March 14, 2006 12:25 PM=20
  Subject: Re: [Ips] TMF for a write with only unsolicited data=20

  Eddy,=20

  AFAIK, other than Task Reassign, no TMF requires sending any data.  =
The point of Abort Task is to kill that task and stop all work on the =
task, so sending data would be counter-productive.=20

  Mike=20

  To:        "Mike Ko" =20
  cc:        =20
  Subject:        Re: [Ips] TMF for a write with only unsolicited data=20

  How about Abort Task?=20
  =20
  =20
  Eddy=20
  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Cc: ips@ietf.org=20
  Sent: Tuesday, March 14, 2006 11:05 AM=20
  Subject: Re: [Ips] TMF for a write with only unsolicited data=20

  Eddy,=20

  There are 8 task management function codes listed in RFC3720.  They =
are Abort Task, Abort Task Set, Clear ACA, Clear Task Set, Logical Unit =
Reset, Target Warm Reset, Target Cold Reset, and Task Reassign.  If your =
example is not Task Reassign, what TMF code do you have in mind where =
unsolicited write data would be sent?=20

  Mike=20

  To:        "Mike Ko" =20
  cc:        =20
  Subject:        Re: [Ips] TMF for a write with only unsolicited data=20

  No. The case is not a TASK REASSIGN. It is for a write command where =
all of the data is unsolicited.=20

  If the STag is used for the associated R2T's then it would seem WSV =
would be set to 0 when no R2T's were issued.=20

  Further it says "The Write STag=20
       Valid flag is set to one when there is solicited data to be=20
       transferred"=20

  Doesn't that mean the STag is only used if there was solicited data =
with the command?=20

  Eddy=20
  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Cc: ips@ietf.org=20
  Sent: Monday, March 13, 2006 7:14 PM=20
  Subject: Re: [Ips] TMF for a write with only unsolicited data=20

  If I understand your question correctly, I assume the TMF is a TASK =
REASSIGN and it is for a write command qualified with DataDescriptorOut. =
 DataDescriptorOut is used to describe the I/O buffer starting with the =
immediate unsolicited data (if any), followed by the non-immediate =
unsolicited data (if any) and solicited data.  A Write STag is allocated =
in this case.  The Write STag is used by the iSER layer at the target in =
handling the data transfer associated with the R2T PDUs and in returning =
the SCSI Response PDU using the SendInvSE message.  Since there is =
non-immediate unsolicited data, WSV is set to 1.=20

  Mike=20

  To:        =20
  cc:        =20
  Subject:        [Ips] TMF for a write with only unsolicited data=20

  Suppose:=20
  1) a TMF is not a TASK REASSIGN=20
  2) the TMF is for a write command=20
  3) the write command only has unsolicited data=20

  I think this is saying the WSV is set to 0 for this case. Is that =
correct?=20

  If so then I think the 3rd bullet item in 7.3.3 needs to say "if =
allocated" since a write with unsolicited only will also have a =
DataDescriptorOut.=20

  Or am I wrong in that the TMF would have the DataDescriptorOut for a =
write with only unsolicited data?=20

  WSV - Write STag Valid flag: 1 bit=20

       This flag indicates the validity of the Write STag field of the=20
       iSER Header.  If set to one, the Write STag field in this iSER=20
       Header is valid.  If set to zero, the Write STag field in this=20
       iSER Header MUST be ignored at the receiver.  The Write STag=20
       Valid flag is set to one when there is solicited data to be=20
       transferred for a SCSI Write or bidirectional command, or when=20
       there are non-immediate unsolicited and solicited data to be=20
       transferred for the referenced task specified in a Task=20
       Management Function Request with the TASK REASSIGN function.=20

  7.3.3  Task Management Function Request/Response=20

  *  It MUST use the ITT as specified in the Referenced Task Tag from=20
     the Task Management Function Request PDU to locate the existing=20
     STag(s), if any, in the Local Mapping(s) that associates the ITT=20
     to the local STag(s).=20

  *  It MUST invalidate the existing STag(s), if any, and the Local=20
     Mapping(s) that associates the ITT to the local STag(s).=20

  *  It MUST allocate a Read STag for the I/O Buffer as defined by the=20
     qualifier DataDescriptorIn if the Send_Control Operational=20
     Primitive invocation is qualified with DataDescriptorIn.=20

  Eddy_______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips=20

-------------------------------------------------------------------------=
-----

  _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips=20

------=_NextPart_000_0033_01C64768.C4A9EFC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

So the paragraph below is saying the WSA would be 0 =
if the=20
Abort Task were aborting a Write that had only unsolicited data. That is =
the way=20
I read it too. You further said that for this case there would be =
no=20
DataDescriptorOut with the TMF call from the iSCSI layer =
to the iSER=20
layer. I think that is now clear. Thanks.

WSV - Write STag Valid flag: =
1 bit=20

     This flag indicates the validity of the =
Write STag=20
field of the 
     iSER Header.  If set to one, =
the Write=20
STag field in this iSER 
     Header is valid. =
 If set to=20
zero, the Write STag field in this 
     iSER Header =
MUST be=20
ignored at the receiver.  The Write STag 
    =
 Valid flag=20
is set to one when there is solicited data to be 
   =20
 transferred for a SCSI Write or bidirectional command, or when =

 =20
   there are non-immediate unsolicited and solicited data to =
be=20

     transferred for the referenced task specified in =
a Task=20

     Management Function Request with the TASK =
REASSIGN=20
function. 

  ----- Original Message ----- 
  From:=20
  Mike Ko=20

  To: Eddy =
Quicksall=20

  Sent: Tuesday, March 14, 2006 =
12:58=20
  PM
  Subject: Re: [Ips] TMF for a =
write with=20
  only unsolicited data

Ergo, there is no=20
  DataDescriptorOut, and therefore no unsolicited data associated with =
the=20
  issuance of the Abort Task TMF. 

Mike=20
  To:     =
 =20
   "Mike Ko" <mako@almaden.ibm.com> =

cc:     =
   =20

Subject: =
   =20
     Re: [Ips] TMF for =
a write=20
  with only unsolicited data 

The TMF =
doesn't=20
  send any data. The TMF is aborting a task that has only unsolicited=20
  data. 
----- Original Message ----- =

From: Mike Ko =

To: Eddy Quicksall =

Sent: Tuesday, March 14, 2006 12:25 PM =

Subject: Re: [Ips] TMF for a write with only =
unsolicited=20
  data 

Eddy,=20

AFAIK, other than Task =
Reassign,=20
  no TMF requires sending any data.  The point of Abort Task is to =
kill=20
  that task and stop all work on the task, so sending data would be=20
  counter-productive. 

Mike 

To:     =
 =20
   "Mike Ko" <mako@almaden.ibm.com> 
cc:         
Subject:   =
   =20
   Re: [Ips] TMF for a =
write with only=20
  unsolicited data 

How about=20
  Abort Task? 

Eddy 
----- Original Message =
-----=20

From: Mike Ko 
To: =
Eddy Quicksall =

Cc: ips@ietf.org =

Sent: Tuesday,=20
  March 14, 2006 11:05 AM 
Subject: Re: [Ips] TMF for a write =
with=20
  only unsolicited data 

Eddy, 

There are 8 task management function codes listed in =
RFC3720.=20
   They are Abort Task, Abort Task Set, Clear ACA, Clear Task Set, =
Logical=20
  Unit Reset, Target Warm Reset, Target Cold Reset, and Task Reassign. =
 If=20
  your example is not Task Reassign, what TMF code do you have in mind =
where=20
  unsolicited write data would be sent? =

Mike 

To:     =
 =20
   "Mike Ko" <mako@almaden.ibm.com> 
cc:        <ips@ietf.org> =

Subject:=20
         Re: =
[Ips] TMF=20
  for a write with only unsolicited data =

No. The case is not a TASK REASSIGN. It is for a =
write command=20
  where all of the data is unsolicited. =

If the STag is used for the associated R2T's then it =
would seem WSV=20
  would be set to 0 when no R2T's were issued.=20

Further it says "The Write STag 
    =
 Valid=20
  flag is set to one when there is solicited data to be 
  =
 =20
   transferred" 

Doesn't=20
  that mean the STag is only used if there was solicited data with the=20
  command? 

Eddy 
----- Original Message ----- 
From: Mike=20
  Ko 
To: Eddy Quicksall =

Cc: ips@ietf.org =

Sent: Monday,=20
  March 13, 2006 7:14 PM 
Subject: Re: [Ips] TMF for a write =
with only=20
  unsolicited data 

If I=20
  understand your question correctly, I assume the TMF is a TASK =
REASSIGN and it=20
  is for a write command qualified with DataDescriptorOut.=20
   DataDescriptorOut is used to describe the I/O buffer starting =
with the=20
  immediate unsolicited data (if any), followed by the non-immediate =
unsolicited=20
  data (if any) and solicited data.  A Write STag is allocated in =
this=20
  case.  The Write STag is used by the iSER layer at the target in =
handling=20
  the data transfer associated with the R2T PDUs and in returning the =
SCSI=20
  Response PDU using the SendInvSE message.  Since there is =
non-immediate=20
  unsolicited data, WSV is set to 1. 

Mike 

To:     =
 =20
   <ips@ietf.org> 
cc:  =20

Subject:       =
 [Ips] TMF for a write with only unsolicited =

  data 

Suppose: 
1) a TMF is not a TASK REASSIGN =

2) the TMF is for a write =
command=20

3) the write command only has =
unsolicited=20
  data 

I think this=20
  is saying the WSV is set to 0 for this case. Is that =
correct? 

If so then I =
think the 3rd=20
  bullet item in 7.3.3 needs to say "if allocated" since a write with=20
  unsolicited only will also have a DataDescriptorOut.=20

Or am I wrong in that the =
TMF would=20
  have the DataDescriptorOut for a write with only unsolicited =
data? 

WSV =
- Write STag=20
  Valid flag: 1 bit 

     This flag indicates the =
validity=20
  of the Write STag field of the 
     iSER Header. =
 If=20
  set to one, the Write STag field in this iSER 
    =
 Header=20
  is valid.  If set to zero, the Write STag field in this =

   =20
   iSER Header MUST be ignored at the receiver.  The Write =
STag=20

     Valid flag is set to one when there is =
solicited data=20
  to be 
     transferred for a SCSI Write or =
bidirectional=20
  command, or when 
     there are non-immediate =
unsolicited=20
  and solicited data to be 
     transferred for the=20
  referenced task specified in a Task 
     Management =

  Function Request with the TASK REASSIGN function.=20

7.3.3 =
 Task=20
  Management Function Request/Response 

*  It MUST use the =
ITT as=20
  specified in the Referenced Task Tag from 
   the Task =
Management=20
  Function Request PDU to locate the existing 
   STag(s), =
if any,=20
  in the Local Mapping(s) that associates the ITT 
   to =
the local=20
  STag(s). 

*  It MUST invalidate the existing STag(s), if =
any, and=20
  the Local 
   Mapping(s) that associates the ITT to the =
local=20
  STag(s). 

*  It MUST allocate a Read STag for the I/O =
Buffer as=20
  defined by the 
   qualifier DataDescriptorIn if the =
Send_Control=20
  Operational 
   Primitive invocation is qualified with=20
  DataDescriptorIn. 

Eddy_______________________________________________
Ips =
mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=20

  _______________________________________________
Ips mailing=20
  list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=20

------=_NextPart_000_0033_01C64768.C4A9EFC0--

--===============1817369203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1817369203==--

From ips-bounces@ietf.org Wed Mar 15 19:58:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJgos-0001dV-38; Wed, 15 Mar 2006 19:58:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJgoq-0001dQ-B5
	for ips@ietf.org; Wed, 15 Mar 2006 19:58:24 -0500
Received: from web51907.mail.yahoo.com ([206.190.48.70])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJgoo-0006VA-M9
	for ips@ietf.org; Wed, 15 Mar 2006 19:58:24 -0500
Received: (qmail 42683 invoked by uid 60001); 16 Mar 2006 00:58:22 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=oy6/qTTBeaOb0HdKJeO4D9m3jWKZt2KWBKEmY060InTGIx4z53PXxW8Cke5W9qsa6XW5IIO5j1C//dvxRRzHdS75WcX+wDKSv4pMy0wKUoWlZquzACNbEzDu8BsL9CdBx+ho5M+FOsPkeM+6GyTkv65NYj6eKrvxOcxjH9nN2KA=
	; 
Message-ID: <20060316005822.42681.qmail@web51907.mail.yahoo.com>
Received: from [15.235.153.105] by web51907.mail.yahoo.com via HTTP;
	Wed, 15 Mar 2006 16:58:22 PST
Date: Wed, 15 Mar 2006 16:58:22 -0800 (PST)
From: "Mallikarjun C." 
Subject: Re: [Ips] TMF for a write with only unsolicited data
To: ips@ietf.org
In-Reply-To: <003601c64792$afe3d860$08031eac@ivivity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 850245b51c39701e2700a112f3032caa
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

WSV=0 for TMF=Abort Task, always.

Mallikarjun

--- Eddy Quicksall
 wrote:

> So the paragraph below is saying the WSA would be 0
> if the Abort Task were aborting a Write that had
> only unsolicited data. That is the way I read it
> too. You further said that for this case there would
> be no DataDescriptorOut with the TMF call from the
> iSCSI layer to the iSER layer. I think that is now
> clear. Thanks.
> 
> WSV - Write STag Valid flag: 1 bit 
> 
>      This flag indicates the validity of the Write
> STag field of the 
>      iSER Header.  If set to one, the Write STag
> field in this iSER 
>      Header is valid.  If set to zero, the Write
> STag field in this 
>      iSER Header MUST be ignored at the receiver. 
> The Write STag 
>      Valid flag is set to one when there is
> solicited data to be 
>      transferred for a SCSI Write or bidirectional
> command, or when 
>      there are non-immediate unsolicited and
> solicited data to be 
>      transferred for the referenced task specified
> in a Task 
>      Management Function Request with the TASK
> REASSIGN function. 
> 
> 
>   ----- Original Message ----- 
>   From: Mike Ko 
>   To: Eddy Quicksall 
>   Sent: Tuesday, March 14, 2006 12:58 PM
>   Subject: Re: [Ips] TMF for a write with only
> unsolicited data
> 
> 
> 
>   Ergo, there is no DataDescriptorOut, and therefore
> no unsolicited data associated with the issuance of
> the Abort Task TMF. 
> 
>   Mike 
>   To:        "Mike Ko"  
>   cc:         
>   Subject:        Re: [Ips] TMF for a write with
> only unsolicited data 
> 
> 
>   The TMF doesn't send any data. The TMF is aborting
> a task that has only unsolicited data. 
>   ----- Original Message ----- 
>   From: Mike Ko 
>   To: Eddy Quicksall 
>   Sent: Tuesday, March 14, 2006 12:25 PM 
>   Subject: Re: [Ips] TMF for a write with only
> unsolicited data 
> 
> 
>   Eddy, 
> 
>   AFAIK, other than Task Reassign, no TMF requires
> sending any data.  The point of Abort Task is to
> kill that task and stop all work on the task, so
> sending data would be counter-productive. 
> 
>   Mike 
> 
>   To:        "Mike Ko"  
>   cc:         
>   Subject:        Re: [Ips] TMF for a write with
> only unsolicited data 
> 
> 
>   How about Abort Task? 
>    
>    
>   Eddy 
>   ----- Original Message ----- 
>   From: Mike Ko 
>   To: Eddy Quicksall 
>   Cc: ips@ietf.org 
>   Sent: Tuesday, March 14, 2006 11:05 AM 
>   Subject: Re: [Ips] TMF for a write with only
> unsolicited data 
> 
> 
>   Eddy, 
> 
>   There are 8 task management function codes listed
> in RFC3720.  They are Abort Task, Abort Task Set,
> Clear ACA, Clear Task Set, Logical Unit Reset,
> Target Warm Reset, Target Cold Reset, and Task
> Reassign.  If your example is not Task Reassign,
> what TMF code do you have in mind where unsolicited
> write data would be sent? 
> 
>   Mike 
> 
>   To:        "Mike Ko"  
>   cc:         
>   Subject:        Re: [Ips] TMF for a write with
> only unsolicited data 
> 
> 
>   No. The case is not a TASK REASSIGN. It is for a
> write command where all of the data is unsolicited. 
> 
>   If the STag is used for the associated R2T's then
> it would seem WSV would be set to 0 when no R2T's
> were issued. 
> 
>   Further it says "The Write STag 
>        Valid flag is set to one when there is
> solicited data to be 
>        transferred" 
> 
>   Doesn't that mean the STag is only used if there
> was solicited data with the command? 
> 
>   Eddy 
>   ----- Original Message ----- 
>   From: Mike Ko 
>   To: Eddy Quicksall 
>   Cc: ips@ietf.org 
>   Sent: Monday, March 13, 2006 7:14 PM 
>   Subject: Re: [Ips] TMF for a write with only
> unsolicited data 
> 
> 
>   If I understand your question correctly, I assume
> the TMF is a TASK REASSIGN and it is for a write
> command qualified with DataDescriptorOut. 
> DataDescriptorOut is used to describe the I/O buffer
> starting with the immediate unsolicited data (if
> any), followed by the non-immediate unsolicited data
> (if any) and solicited data.  A Write STag is
> allocated in this case.  The Write STag is used by
> the iSER layer at the target in handling the data
> transfer associated with the R2T PDUs and in
> returning the SCSI Response PDU using the SendInvSE
> message.  Since there is non-immediate unsolicited
> data, WSV is set to 1. 
> 
>   Mike 
> 
>   To:         
>   cc:         
>   Subject:        [Ips] TMF for a write with only
> unsolicited data 
> 
> 
>   Suppose: 
>   1) a TMF is not a TASK REASSIGN 
>   2) the TMF is for a write command 
>   3) the write command only has unsolicited data 
> 
>   I think this is saying the WSV is set to 0 for
> this case. Is that correct? 
> 
>   If so then I think the 3rd bullet item in 7.3.3
> needs to say "if allocated" since a write with
> unsolicited only will also have a DataDescriptorOut.
> 
> 
>   Or am I wrong in that the TMF would have the
> DataDescriptorOut for a write with only unsolicited
> data? 
> 
>   WSV - Write STag Valid flag: 1 bit 
> 
>        This flag indicates the validity of the Write
> STag field of the 
>        iSER Header.  If set to one, the Write STag
> field in this iSER 
>        Header is valid.  If set to zero, the Write
> STag field in this 
>        iSER Header MUST be ignored at the receiver. 
> The Write STag 
>        Valid flag is set to one when there is
> solicited data to be 
>        transferred for a SCSI Write or bidirectional
> command, or when 
>        there are non-immediate unsolicited and
> solicited data to be 
>        transferred for the referenced task specified
> in a Task 
>        Management Function Request with the TASK
> REASSIGN function. 
> 
>   7.3.3  Task Management Function Request/Response 
> 
>   *  It MUST use the ITT as specified in the
> Referenced Task Tag from 
>      the Task Management Function Request PDU to
> locate the existing 
>      STag(s), if any, in the Local Mapping(s) that
> associates the ITT 
>      to the local STag(s). 
> 
>   *  It MUST invalidate the existing STag(s), if
> any, and the Local 
>      Mapping(s) that associates the ITT to the local
> STag(s). 
> 
>   *  It MUST allocate a Read STag for the I/O Buffer
> as defined by the 
>      qualifier DataDescriptorIn if the Send_Control
> Operational 
>      Primitive invocation is qualified with
> DataDescriptorIn. 
> 
> 
>  
> Eddy_______________________________________________
>   Ips mailing list
>   Ips@ietf.org
>   https://www1.ietf.org/mailman/listinfo/ips 
> 
> 
> 
>
------------------------------------------------------------------------------
> 
>   _______________________________________________
>   Ips mailing list
>   Ips@ietf.org
>   https://www1.ietf.org/mailman/listinfo/ips 
> 
> > _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Sun Mar 19 10:37:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKzxl-00035e-5W; Sun, 19 Mar 2006 10:37:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzxj-00034e-7s
	for ips@ietf.org; Sun, 19 Mar 2006 10:36:59 -0500
Received: from rwcrmhc13.comcast.net ([216.148.227.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzxg-0006xo-Nc
	for ips@ietf.org; Sun, 19 Mar 2006 10:36:59 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (rwcrmhc13) with SMTP
	id <20060319153655m13005j97ie>; Sun, 19 Mar 2006 15:36:55 +0000
Message-ID: <001401c64b6a$f3cdb880$08031eac@ivivity.com>
From: "Eddy Quicksall" 
To: "Mallikarjun C." ,

References: <20060316005822.42681.qmail@web51907.mail.yahoo.com>
Subject: Re: [Ips] TMF for a write with only unsolicited data
Date: Sun, 19 Mar 2006 10:36:54 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

Mallikarjun,

Then I think you must be saying the TMF for Abort Task does not use the 
qualifier DataDescriptorOut when there is solicited data. If so then when 
would the DataDescriptorOut and DataDescriptorIn be used with a TMF?

7.3.3

the iSER Layer at the initiator MUST do the following

   *  It MUST allocate a Read STag for the I/O Buffer as defined by the

      qualifier DataDescriptorIn if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorIn.

   *  It MUST allocate a Write STag for the I/O Buffer as defined by

      the qualifier DataDescriptorOut if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorOut.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." 
To: 
Sent: Wednesday, March 15, 2006 7:58 PM
Subject: Re: [Ips] TMF for a write with only unsolicited data

> WSV=0 for TMF=Abort Task, always.
>
> Mallikarjun
>
>
> --- Eddy Quicksall
>  wrote:
>
>> So the paragraph below is saying the WSA would be 0
>> if the Abort Task were aborting a Write that had
>> only unsolicited data. That is the way I read it
>> too. You further said that for this case there would
>> be no DataDescriptorOut with the TMF call from the
>> iSCSI layer to the iSER layer. I think that is now
>> clear. Thanks.
>>
>> WSV - Write STag Valid flag: 1 bit
>>
>>      This flag indicates the validity of the Write
>> STag field of the
>>      iSER Header.  If set to one, the Write STag
>> field in this iSER
>>      Header is valid.  If set to zero, the Write
>> STag field in this
>>      iSER Header MUST be ignored at the receiver.
>> The Write STag
>>      Valid flag is set to one when there is
>> solicited data to be
>>      transferred for a SCSI Write or bidirectional
>> command, or when
>>      there are non-immediate unsolicited and
>> solicited data to be
>>      transferred for the referenced task specified
>> in a Task
>>      Management Function Request with the TASK
>> REASSIGN function.
>>
>>
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Sent: Tuesday, March 14, 2006 12:58 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>
>>   Ergo, there is no DataDescriptorOut, and therefore
>> no unsolicited data associated with the issuance of
>> the Abort Task TMF.
>>
>>   Mike
>>   To:        "Mike Ko" 
>>   cc:
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   The TMF doesn't send any data. The TMF is aborting
>> a task that has only unsolicited data.
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Sent: Tuesday, March 14, 2006 12:25 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Eddy,
>>
>>   AFAIK, other than Task Reassign, no TMF requires
>> sending any data.  The point of Abort Task is to
>> kill that task and stop all work on the task, so
>> sending data would be counter-productive.
>>
>>   Mike
>>
>>   To:        "Mike Ko" 
>>   cc:
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   How about Abort Task?
>>
>>
>>   Eddy
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Cc: ips@ietf.org
>>   Sent: Tuesday, March 14, 2006 11:05 AM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Eddy,
>>
>>   There are 8 task management function codes listed
>> in RFC3720.  They are Abort Task, Abort Task Set,
>> Clear ACA, Clear Task Set, Logical Unit Reset,
>> Target Warm Reset, Target Cold Reset, and Task
>> Reassign.  If your example is not Task Reassign,
>> what TMF code do you have in mind where unsolicited
>> write data would be sent?
>>
>>   Mike
>>
>>   To:        "Mike Ko" 
>>   cc:        
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   No. The case is not a TASK REASSIGN. It is for a
>> write command where all of the data is unsolicited.
>>
>>   If the STag is used for the associated R2T's then
>> it would seem WSV would be set to 0 when no R2T's
>> were issued.
>>
>>   Further it says "The Write STag
>>        Valid flag is set to one when there is
>> solicited data to be
>>        transferred"
>>
>>   Doesn't that mean the STag is only used if there
>> was solicited data with the command?
>>
>>   Eddy
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Cc: ips@ietf.org
>>   Sent: Monday, March 13, 2006 7:14 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   If I understand your question correctly, I assume
>> the TMF is a TASK REASSIGN and it is for a write
>> command qualified with DataDescriptorOut.
>> DataDescriptorOut is used to describe the I/O buffer
>> starting with the immediate unsolicited data (if
>> any), followed by the non-immediate unsolicited data
>> (if any) and solicited data.  A Write STag is
>> allocated in this case.  The Write STag is used by
>> the iSER layer at the target in handling the data
>> transfer associated with the R2T PDUs and in
>> returning the SCSI Response PDU using the SendInvSE
>> message.  Since there is non-immediate unsolicited
>> data, WSV is set to 1.
>>
>>   Mike
>>
>>   To:        
>>   cc:
>>   Subject:        [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Suppose:
>>   1) a TMF is not a TASK REASSIGN
>>   2) the TMF is for a write command
>>   3) the write command only has unsolicited data
>>
>>   I think this is saying the WSV is set to 0 for
>> this case. Is that correct?
>>
>>   If so then I think the 3rd bullet item in 7.3.3
>> needs to say "if allocated" since a write with
>> unsolicited only will also have a DataDescriptorOut.
>>
>>
>>   Or am I wrong in that the TMF would have the
>> DataDescriptorOut for a write with only unsolicited
>> data?
>>
>>   WSV - Write STag Valid flag: 1 bit
>>
>>        This flag indicates the validity of the Write
>> STag field of the
>>        iSER Header.  If set to one, the Write STag
>> field in this iSER
>>        Header is valid.  If set to zero, the Write
>> STag field in this
>>        iSER Header MUST be ignored at the receiver.
>> The Write STag
>>        Valid flag is set to one when there is
>> solicited data to be
>>        transferred for a SCSI Write or bidirectional
>> command, or when
>>        there are non-immediate unsolicited and
>> solicited data to be
>>        transferred for the referenced task specified
>> in a Task
>>        Management Function Request with the TASK
>> REASSIGN function.
>>
>>   7.3.3  Task Management Function Request/Response
>>
>>   *  It MUST use the ITT as specified in the
>> Referenced Task Tag from
>>      the Task Management Function Request PDU to
>> locate the existing
>>      STag(s), if any, in the Local Mapping(s) that
>> associates the ITT
>>      to the local STag(s).
>>
>>   *  It MUST invalidate the existing STag(s), if
>> any, and the Local
>>      Mapping(s) that associates the ITT to the local
>> STag(s).
>>
>>   *  It MUST allocate a Read STag for the I/O Buffer
>> as defined by the
>>      qualifier DataDescriptorIn if the Send_Control
>> Operational
>>      Primitive invocation is qualified with
>> DataDescriptorIn.
>>
>>
>>
>> Eddy_______________________________________________
>>   Ips mailing list
>>   Ips@ietf.org
>>   https://www1.ietf.org/mailman/listinfo/ips
>>
>>
>>
>>
> ------------------------------------------------------------------------------
>>
>>   _______________________________________________
>>   Ips mailing list
>>   Ips@ietf.org
>>   https://www1.ietf.org/mailman/listinfo/ips
>>
>> > _______________________________________________
>> Ips mailing list
>> Ips@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ips
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Mon Mar 20 12:07:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLNqo-0006m8-Hn; Mon, 20 Mar 2006 12:07:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNqn-0006m3-Hg
	for ips@ietf.org; Mon, 20 Mar 2006 12:07:25 -0500
Received: from e4.ny.us.ibm.com ([32.97.182.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNqm-00024K-MW
	for ips@ietf.org; Mon, 20 Mar 2006 12:07:25 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2KH7OJQ029892
	for ; Mon, 20 Mar 2006 12:07:24 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2KH7N7U216708 for ; Mon, 20 Mar 2006 12:07:23 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2KH7MLC025836
	for ; Mon, 20 Mar 2006 12:07:22 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90])
	by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2KH7D5R025061; 
	Mon, 20 Mar 2006 12:07:22 -0500
In-Reply-To: <001401c64b6a$f3cdb880$08031eac@ivivity.com>
Importance: Normal
MIME-Version: 1.0
Sensitivity: 
To: "Eddy Quicksall" 
Subject: Re: [Ips] TMF for a write with only unsolicited data
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: 
From: Mike Ko 
Date: Mon, 20 Mar 2006 09:06:19 -0800
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 |
	February 28, 2006) at 03/20/2006 12:07:21,
	Serialize complete at 03/20/2006 12:07:22,
	Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 | February
	28, 2006) at 03/20/2006 12:07:22
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0226114486=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0226114486==
Content-Type: multipart/alternative;
	boundary="=_alternative 005DF66B88257137_="

This is a multipart message in MIME format.
--=_alternative 005DF66B88257137_=
Content-Type: text/plain; charset="US-ASCII"

Eddy,

The two bulleted items that you quoted are prefaced by the following 
statement:

"For the Task Management Function Request with the TASK REASSIGN function, 
the iSER Layer at the initiator MUST do the following".

In other words, DataDescriptorOut and/or DataDescriptorIn are used only 
when the TMF request is Task Reassign and the referenced task is a write 
(DataDescriptorOut) or read (DataDescriptorIn) or bidirectional (both) 
command.  Other than Task Reassign, there is no data transfer associated 
with the other TMF requests, either unsolicited or solicited, and hence 
there is no DataDescriptorOut or DataDescriptorIn. 

Mike 
To:     "Mallikarjun C." , 
cc:      
Subject:        Re: [Ips] TMF for a write with only unsolicited data

Mallikarjun,

Then I think you must be saying the TMF for Abort Task does not use the 
qualifier DataDescriptorOut when there is solicited data. If so then when 
would the DataDescriptorOut and DataDescriptorIn be used with a TMF?

7.3.3

the iSER Layer at the initiator MUST do the following

   *  It MUST allocate a Read STag for the I/O Buffer as defined by the

      qualifier DataDescriptorIn if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorIn.

   *  It MUST allocate a Write STag for the I/O Buffer as defined by

      the qualifier DataDescriptorOut if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorOut.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." 
To: 
Sent: Wednesday, March 15, 2006 7:58 PM
Subject: Re: [Ips] TMF for a write with only unsolicited data

> WSV=0 for TMF=Abort Task, always.
>
> Mallikarjun
>
>
> --- Eddy Quicksall
>  wrote:
>
>> So the paragraph below is saying the WSA would be 0
>> if the Abort Task were aborting a Write that had
>> only unsolicited data. That is the way I read it
>> too. You further said that for this case there would
>> be no DataDescriptorOut with the TMF call from the
>> iSCSI layer to the iSER layer. I think that is now
>> clear. Thanks.
>>
>> WSV - Write STag Valid flag: 1 bit
>>
>>      This flag indicates the validity of the Write
>> STag field of the
>>      iSER Header.  If set to one, the Write STag
>> field in this iSER
>>      Header is valid.  If set to zero, the Write
>> STag field in this
>>      iSER Header MUST be ignored at the receiver.
>> The Write STag
>>      Valid flag is set to one when there is
>> solicited data to be
>>      transferred for a SCSI Write or bidirectional
>> command, or when
>>      there are non-immediate unsolicited and
>> solicited data to be
>>      transferred for the referenced task specified
>> in a Task
>>      Management Function Request with the TASK
>> REASSIGN function.
>>
>>
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Sent: Tuesday, March 14, 2006 12:58 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>
>>   Ergo, there is no DataDescriptorOut, and therefore
>> no unsolicited data associated with the issuance of
>> the Abort Task TMF.
>>
>>   Mike
>>   To:        "Mike Ko" 
>>   cc:
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   The TMF doesn't send any data. The TMF is aborting
>> a task that has only unsolicited data.
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Sent: Tuesday, March 14, 2006 12:25 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Eddy,
>>
>>   AFAIK, other than Task Reassign, no TMF requires
>> sending any data.  The point of Abort Task is to
>> kill that task and stop all work on the task, so
>> sending data would be counter-productive.
>>
>>   Mike
>>
>>   To:        "Mike Ko" 
>>   cc:
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   How about Abort Task?
>>
>>
>>   Eddy
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Cc: ips@ietf.org
>>   Sent: Tuesday, March 14, 2006 11:05 AM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Eddy,
>>
>>   There are 8 task management function codes listed
>> in RFC3720.  They are Abort Task, Abort Task Set,
>> Clear ACA, Clear Task Set, Logical Unit Reset,
>> Target Warm Reset, Target Cold Reset, and Task
>> Reassign.  If your example is not Task Reassign,
>> what TMF code do you have in mind where unsolicited
>> write data would be sent?
>>
>>   Mike
>>
>>   To:        "Mike Ko" 
>>   cc:        
>>   Subject:        Re: [Ips] TMF for a write with
>> only unsolicited data
>>
>>
>>   No. The case is not a TASK REASSIGN. It is for a
>> write command where all of the data is unsolicited.
>>
>>   If the STag is used for the associated R2T's then
>> it would seem WSV would be set to 0 when no R2T's
>> were issued.
>>
>>   Further it says "The Write STag
>>        Valid flag is set to one when there is
>> solicited data to be
>>        transferred"
>>
>>   Doesn't that mean the STag is only used if there
>> was solicited data with the command?
>>
>>   Eddy
>>   ----- Original Message ----- 
>>   From: Mike Ko
>>   To: Eddy Quicksall
>>   Cc: ips@ietf.org
>>   Sent: Monday, March 13, 2006 7:14 PM
>>   Subject: Re: [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   If I understand your question correctly, I assume
>> the TMF is a TASK REASSIGN and it is for a write
>> command qualified with DataDescriptorOut.
>> DataDescriptorOut is used to describe the I/O buffer
>> starting with the immediate unsolicited data (if
>> any), followed by the non-immediate unsolicited data
>> (if any) and solicited data.  A Write STag is
>> allocated in this case.  The Write STag is used by
>> the iSER layer at the target in handling the data
>> transfer associated with the R2T PDUs and in
>> returning the SCSI Response PDU using the SendInvSE
>> message.  Since there is non-immediate unsolicited
>> data, WSV is set to 1.
>>
>>   Mike
>>
>>   To:        
>>   cc:
>>   Subject:        [Ips] TMF for a write with only
>> unsolicited data
>>
>>
>>   Suppose:
>>   1) a TMF is not a TASK REASSIGN
>>   2) the TMF is for a write command
>>   3) the write command only has unsolicited data
>>
>>   I think this is saying the WSV is set to 0 for
>> this case. Is that correct?
>>
>>   If so then I think the 3rd bullet item in 7.3.3
>> needs to say "if allocated" since a write with
>> unsolicited only will also have a DataDescriptorOut.
>>
>>
>>   Or am I wrong in that the TMF would have the
>> DataDescriptorOut for a write with only unsolicited
>> data?
>>
>>   WSV - Write STag Valid flag: 1 bit
>>
>>        This flag indicates the validity of the Write
>> STag field of the
>>        iSER Header.  If set to one, the Write STag
>> field in this iSER
>>        Header is valid.  If set to zero, the Write
>> STag field in this
>>        iSER Header MUST be ignored at the receiver.
>> The Write STag
>>        Valid flag is set to one when there is
>> solicited data to be
>>        transferred for a SCSI Write or bidirectional
>> command, or when
>>        there are non-immediate unsolicited and
>> solicited data to be
>>        transferred for the referenced task specified
>> in a Task
>>        Management Function Request with the TASK
>> REASSIGN function.
>>
>>   7.3.3  Task Management Function Request/Response
>>
>>   *  It MUST use the ITT as specified in the
>> Referenced Task Tag from
>>      the Task Management Function Request PDU to
>> locate the existing
>>      STag(s), if any, in the Local Mapping(s) that
>> associates the ITT
>>      to the local STag(s).
>>
>>   *  It MUST invalidate the existing STag(s), if
>> any, and the Local
>>      Mapping(s) that associates the ITT to the local
>> STag(s).
>>
>>   *  It MUST allocate a Read STag for the I/O Buffer
>> as defined by the
>>      qualifier DataDescriptorIn if the Send_Control
>> Operational
>>      Primitive invocation is qualified with
>> DataDescriptorIn.
>>
>>
>>
>> Eddy_______________________________________________
>>   Ips mailing list
>>   Ips@ietf.org
>>   https://www1.ietf.org/mailman/listinfo/ips
>>
>>
>>
>>
> 
------------------------------------------------------------------------------
>>
>>   _______________________________________________
>>   Ips mailing list
>>   Ips@ietf.org
>>   https://www1.ietf.org/mailman/listinfo/ips
>>
>> > _______________________________________________
>> Ips mailing list
>> Ips@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ips
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 005DF66B88257137_=
Content-Type: text/html; charset="US-ASCII"

Eddy,

The two bulleted items that you quoted
are prefaced by the following statement:

"For the Task Management Function
Request with the TASK REASSIGN function, the iSER Layer at the initiator
MUST do the following".

In other words, DataDescriptorOut and/or
DataDescriptorIn are used only when the TMF request is Task Reassign and
the referenced task is a write (DataDescriptorOut) or read (DataDescriptorIn)
or bidirectional (both) command.  Other than Task Reassign, there
is no data transfer associated with the other TMF requests, either unsolicited
or solicited, and hence there is no DataDescriptorOut or DataDescriptorIn.

Mike 
To:      
 "Mallikarjun C."
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>

cc:      

Subject:    
   Re: [Ips] TMF
for a write with only unsolicited data

Mallikarjun,

Then I think you must be saying the TMF for Abort Task does not use the

qualifier DataDescriptorOut when there is solicited data. If so then when

would the DataDescriptorOut and DataDescriptorIn be used with a TMF?

7.3.3

the iSER Layer at the initiator MUST do the following

   *  It MUST allocate a Read STag for the I/O Buffer as defined
by the

      qualifier DataDescriptorIn if the Send_Control Operational

      Primitive invocation is qualified with DataDescriptorIn.

   *  It MUST allocate a Write STag for the I/O Buffer as defined
by

      the qualifier DataDescriptorOut if the Send_Control
Operational

      Primitive invocation is qualified with DataDescriptorOut.

Eddy

----- Original Message ----- 

From: "Mallikarjun C." <cb_mallikarjun@yahoo.com>

To: <ips@ietf.org>

Sent: Wednesday, March 15, 2006 7:58 PM

Subject: Re: [Ips] TMF for a write with only unsolicited data

> WSV=0 for TMF=Abort Task, always.

>

> Mallikarjun

>

>

> --- Eddy Quicksall

> <eddy_quicksall_iVivity_iSCSI@Comcast.net> wrote:

>

>> So the paragraph below is saying the WSA would be 0

>> if the Abort Task were aborting a Write that had

>> only unsolicited data. That is the way I read it

>> too. You further said that for this case there would

>> be no DataDescriptorOut with the TMF call from the

>> iSCSI layer to the iSER layer. I think that is now

>> clear. Thanks.

>>

>> WSV - Write STag Valid flag: 1 bit

>>

>>      This flag indicates the validity of the Write

>> STag field of the

>>      iSER Header.  If set to one, the Write
STag

>> field in this iSER

>>      Header is valid.  If set to zero, the
Write

>> STag field in this

>>      iSER Header MUST be ignored at the receiver.

>> The Write STag

>>      Valid flag is set to one when there is

>> solicited data to be

>>      transferred for a SCSI Write or bidirectional

>> command, or when

>>      there are non-immediate unsolicited and

>> solicited data to be

>>      transferred for the referenced task specified

>> in a Task

>>      Management Function Request with the TASK

>> REASSIGN function.

>>

>>

>>   ----- Original Message ----- 

>>   From: Mike Ko

>>   To: Eddy Quicksall

>>   Sent: Tuesday, March 14, 2006 12:58 PM

>>   Subject: Re: [Ips] TMF for a write with only

>> unsolicited data

>>

>>

>>

>>   Ergo, there is no DataDescriptorOut, and therefore

>> no unsolicited data associated with the issuance of

>> the Abort Task TMF.

>>

>>   Mike

>>   To:        "Mike Ko" <mako@almaden.ibm.com>

>>   cc:

>>   Subject:        Re: [Ips] TMF for a
write with

>> only unsolicited data

>>

>>

>>   The TMF doesn't send any data. The TMF is aborting

>> a task that has only unsolicited data.

>>   ----- Original Message ----- 

>>   From: Mike Ko

>>   To: Eddy Quicksall

>>   Sent: Tuesday, March 14, 2006 12:25 PM

>>   Subject: Re: [Ips] TMF for a write with only

>> unsolicited data

>>

>>

>>   Eddy,

>>

>>   AFAIK, other than Task Reassign, no TMF requires

>> sending any data.  The point of Abort Task is to

>> kill that task and stop all work on the task, so

>> sending data would be counter-productive.

>>

>>   Mike

>>

>>   To:        "Mike Ko" <mako@almaden.ibm.com>

>>   cc:

>>   Subject:        Re: [Ips] TMF for a
write with

>> only unsolicited data

>>

>>

>>   How about Abort Task?

>>

>>

>>   Eddy

>>   ----- Original Message ----- 

>>   From: Mike Ko

>>   To: Eddy Quicksall

>>   Cc: ips@ietf.org

>>   Sent: Tuesday, March 14, 2006 11:05 AM

>>   Subject: Re: [Ips] TMF for a write with only

>> unsolicited data

>>

>>

>>   Eddy,

>>

>>   There are 8 task management function codes listed

>> in RFC3720.  They are Abort Task, Abort Task Set,

>> Clear ACA, Clear Task Set, Logical Unit Reset,

>> Target Warm Reset, Target Cold Reset, and Task

>> Reassign.  If your example is not Task Reassign,

>> what TMF code do you have in mind where unsolicited

>> write data would be sent?

>>

>>   Mike

>>

>>   To:        "Mike Ko" <mako@almaden.ibm.com>

>>   cc:        <ips@ietf.org>

>>   Subject:        Re: [Ips] TMF for a
write with

>> only unsolicited data

>>

>>

>>   No. The case is not a TASK REASSIGN. It is for a

>> write command where all of the data is unsolicited.

>>

>>   If the STag is used for the associated R2T's then

>> it would seem WSV would be set to 0 when no R2T's

>> were issued.

>>

>>   Further it says "The Write STag

>>        Valid flag is set to one when there
is

>> solicited data to be

>>        transferred"

>>

>>   Doesn't that mean the STag is only used if there

>> was solicited data with the command?

>>

>>   Eddy

>>   ----- Original Message ----- 

>>   From: Mike Ko

>>   To: Eddy Quicksall

>>   Cc: ips@ietf.org

>>   Sent: Monday, March 13, 2006 7:14 PM

>>   Subject: Re: [Ips] TMF for a write with only

>> unsolicited data

>>

>>

>>   If I understand your question correctly, I assume

>> the TMF is a TASK REASSIGN and it is for a write

>> command qualified with DataDescriptorOut.

>> DataDescriptorOut is used to describe the I/O buffer

>> starting with the immediate unsolicited data (if

>> any), followed by the non-immediate unsolicited data

>> (if any) and solicited data.  A Write STag is

>> allocated in this case.  The Write STag is used by

>> the iSER layer at the target in handling the data

>> transfer associated with the R2T PDUs and in

>> returning the SCSI Response PDU using the SendInvSE

>> message.  Since there is non-immediate unsolicited

>> data, WSV is set to 1.

>>

>>   Mike

>>

>>   To:        <ips@ietf.org>

>>   cc:

>>   Subject:        [Ips] TMF for a write
with only

>> unsolicited data

>>

>>

>>   Suppose:

>>   1) a TMF is not a TASK REASSIGN

>>   2) the TMF is for a write command

>>   3) the write command only has unsolicited data

>>

>>   I think this is saying the WSV is set to 0 for

>> this case. Is that correct?

>>

>>   If so then I think the 3rd bullet item in 7.3.3

>> needs to say "if allocated" since a write with

>> unsolicited only will also have a DataDescriptorOut.

>>

>>

>>   Or am I wrong in that the TMF would have the

>> DataDescriptorOut for a write with only unsolicited

>> data?

>>

>>   WSV - Write STag Valid flag: 1 bit

>>

>>        This flag indicates the validity of
the Write

>> STag field of the

>>        iSER Header.  If set to one, the
Write STag

>> field in this iSER

>>        Header is valid.  If set to zero,
the Write

>> STag field in this

>>        iSER Header MUST be ignored at the
receiver.

>> The Write STag

>>        Valid flag is set to one when there
is

>> solicited data to be

>>        transferred for a SCSI Write or bidirectional

>> command, or when

>>        there are non-immediate unsolicited
and

>> solicited data to be

>>        transferred for the referenced task
specified

>> in a Task

>>        Management Function Request with the
TASK

>> REASSIGN function.

>>

>>   7.3.3  Task Management Function Request/Response

>>

>>   *  It MUST use the ITT as specified in the

>> Referenced Task Tag from

>>      the Task Management Function Request PDU to

>> locate the existing

>>      STag(s), if any, in the Local Mapping(s) that

>> associates the ITT

>>      to the local STag(s).

>>

>>   *  It MUST invalidate the existing STag(s), if

>> any, and the Local

>>      Mapping(s) that associates the ITT to the
local

>> STag(s).

>>

>>   *  It MUST allocate a Read STag for the I/O Buffer

>> as defined by the

>>      qualifier DataDescriptorIn if the Send_Control

>> Operational

>>      Primitive invocation is qualified with

>> DataDescriptorIn.

>>

>>

>>

>> Eddy_______________________________________________

>>   Ips mailing list

>>   Ips@ietf.org

>>   https://www1.ietf.org/mailman/listinfo/ips

>>

>>

>>

>>

> ------------------------------------------------------------------------------

>>

>>   _______________________________________________

>>   Ips mailing list

>>   Ips@ietf.org

>>   https://www1.ietf.org/mailman/listinfo/ips

>>

>> > _______________________________________________

>> Ips mailing list

>> Ips@ietf.org

>> https://www1.ietf.org/mailman/listinfo/ips

>>

>

>

> __________________________________________________

> Do You Yahoo!?

> Tired of spam?  Yahoo! Mail has the best spam protection around

> http://mail.yahoo.com

>

> _______________________________________________

> Ips mailing list

> Ips@ietf.org

> https://www1.ietf.org/mailman/listinfo/ips 

_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 005DF66B88257137_=--

--===============0226114486==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0226114486==--

From ips-bounces@ietf.org Mon Mar 20 14:56:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLQUf-0003z6-Dl; Mon, 20 Mar 2006 14:56:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQUe-0003z1-Iq
	for ips@ietf.org; Mon, 20 Mar 2006 14:56:44 -0500
Received: from gate01out.mcdata.com ([208.47.132.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLQUe-00005j-16
	for ips@ietf.org; Mon, 20 Mar 2006 14:56:44 -0500
Received: from mc4gate01.mcdata.com ([172.16.11.205]) by gate01out.mcdata.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 20 Mar 2006 12:56:43 -0700
Received: from MC4EXCH02.mcdata.com ([172.16.11.132]) by 
	mc4gate01.mcdata.com with InterScan Messaging Security Suite;
	Mon, 20 Mar 2006 12:56:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Mar 2006 12:56:41 -0700
Message-ID: <3CCE3490660DD14ABB8BCD7D0B09925C9B4046@MC4EXCH02.mcdata.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Ips Digest, Vol 23, Issue 6
Thread-Index: AcZEZCYrUzNq+g1HRuyYizUSqdwQIQH9CyXA
From: "Scott Kipp" 
To: 
X-imss-version: 2.038
X-imss-result: Passed
X-imss-approveListMatch: *@mcdata.com
X-OriginalArrivalTime: 20 Mar 2006 19:56:43.0449 (UTC)
	FILETIME=[69529290:01C64C58]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd
Subject: [Ips] RE:Question regarding iSNS Mibs 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

Sajjnu,

Thanks for reviewing the iSNS MIB.  You have basically found some text that=
 was not properly updated when we revised the MIB in this 8th revision. =
 The iSNS client is not required to implement this MIB.  Here are some=
 clarifications that should make this clear:

1) The current introduction is:
2.  Introduction

The iSNS protocol can be used by IP based storage devices for dynamic=
 registration and discovery of storage devices in the network [RFC 471]. =
 It has the capability to group devices into storage Discovery Domains. =
 The iSNS MIB is designed to allow SNMP to be used to monitor and manage=
 iSNS servers and Clients to provide iSNS capabilities.

The last sentence needs to change so that the iSNS client is not=
 implemented and iSNS servers are no longer managed by the MIB.  The=
 resulting text should be:

2.  Introduction

The iSNS protocol can be used by IP based storage devices for dynamic=
 registration and discovery of storage devices in the network [RFC 471]. =
 It has the capability to group devices into storage Discovery Domains. =
 The iSNS MIB is designed to allow SNMP to be used to monitor iSNS servers=
 to provide iSNS capabilities.

2) Section 3.4 is currently:

3.4  Multiple Client and Server Instances

This section name should be changed to:

3.4  Multiple Server Instances

3) In IsnsSrvrDscvryMthdId, the description follows:

IsnsSrvrDscvryMthdId ::=3D TEXTUAL-CONVENTION
    STATUS         current
    DESCRIPTION
"This bitamp is used to indicate the iSNS Server discovery
 methods that are supported and enabled on an iSNS Server.=0D
 The options are DHCP, SLP, multicast group iSNS heartbeat,
 broadcast group iSNS heartbeat, configured server list, and
 other.  The iSNS Server may also support additional discovery
 methods not indicated.  The bitmap also is used to indicate
 the type of discovery being used by an iSNS Client instance.=0D
 If being used, the configured server list for a specific iSNS
 client is specified in isnsClntSrvrCfgTable table.  If used,
 the multicast group is specified in isnsClntInstDiscMcGrp."

The last two sentences should be removed since they refer to the iSNS=
 Client.=0D

4)=0D
isnsInstInfo                OBJECT-TYPE
    SYNTAX                  SnmpAdminString (SIZE (0..80))
    MAX-ACCESS              accessible-for-notify
    STATUS                  current
    DESCRIPTION
"Textual information about the iSNS Server or client
 notification.  An example is: iSNS Client Started, or iSNS
 Server Started, information that would be included in the
 appropriate notification."

should be:

snsInstInfo                OBJECT-TYPE
    SYNTAX                  SnmpAdminString (SIZE (0..80))
    MAX-ACCESS              accessible-for-notify
    STATUS                  current
    DESCRIPTION
"Textual information about the iSNS Server notification.  An example is:=
 iSNS
 Server Started, information that would be included in the
 appropriate notification."

I think this should clear up the confusion.  Thanks for finding this.

If anyone disagrees with the following changes, please let me know or I=
 will incorporate them

Sincerely,
Scott Kipp

-----Original Message-----
From: ips-request@ietf.org [mailto:ips-request@ietf.org]
Sent: Friday, March 10, 2006 10:00 AM
To: ips@ietf.org
Subject: Ips Digest, Vol 23, Issue 6

Send Ips mailing list submissions to
	ips@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ips
or, via email, send a message with subject or body 'help' to
	ips-request@ietf.org

You can reach the person managing the list at
	ips-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ips digest..."

Today's Topics:

   1. Question regarding iSNS Mibs (sajjan rao)

----------------------------------------------------------------------

Message: 1
Date: Wed, 8 Mar 2006 16:02:00 -0800 (PST)
From: sajjan rao 
Subject: [Ips] Question regarding iSNS Mibs
To: ips@ietf.org
Message-ID: <20060309000200.56552.qmail@web51707.mail.yahoo.com>
Content-Type: text/plain; charset=3Diso-8859-1

Hi,

I am new to the subject of iSNS and MIBs.My reading of
draft 8 of the iSNS MIB document has me confused. Is
an iSNS client required to implement this MIB?  The
introduction implies that it does. But section 3.2
'iSNS MIB structure' seems to indicate that the iSNS
MIB has no sections which are required to be
implemented by an iSNS client.  Section 3.4 is titled
'Multiple Client and Server Instances'. But the text
under this section refers only to multiple instances
of servers.

Under the description for IsnsSrvrDscvryMthdID, the
following are mentioned - isnsSrvrDscvryMthdId and
isnsClntInstDiscMcgrp. I couldn't find details on both
anywhere in the document. Can somebody clarify?

=0D
Thanks,
Sajjnu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=0D
http://mail.yahoo.com=0D

------------------------------

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

End of Ips Digest, Vol 23, Issue 6
**********************************

SPECIAL NOTICE=0D

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that=
 disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of=
 this
communication contains public information, no such restrictions apply to=
 that
information. (gate01)

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Tue Mar 21 00:45:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLZfr-0006b8-JM; Tue, 21 Mar 2006 00:44:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLZfq-0006WV-JW
	for ips@ietf.org; Tue, 21 Mar 2006 00:44:54 -0500
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLZfq-0006pb-9m
	for ips@ietf.org; Tue, 21 Mar 2006 00:44:54 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13])
	by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k2L5irHH028705
	for ; Tue, 21 Mar 2006 00:44:53 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k2L5ioDP017754
	for ; Tue, 21 Mar 2006 00:44:51 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 21 Mar 2006 00:44:50 -0500
Message-ID: 
From: Black_David@emc.com
To: ips@ietf.org
Date: Tue, 21 Mar 2006 00:44:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1,
	Antispam-Data: 2006.03.20.211106
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
	__HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Subject: [Ips] DRAFT Dallas minutes
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

Send comments and corrections to me.  This is also the
opportunity for any objections to the Sense of the room
decisions recorded below - they will become the rough
consensus of the IPS WG in the absence of objections.

Thanks,
--David

IP Storage (ips) WG Meeting Minutes - DRAFT
Monday, March 20, 1300-1500
Dallas, Texas
-----------------------------------

Administrivia, agenda bashing, draft status review, etc. - 15 min
		David L. Black, EMC (chair)
	Blue sheets
	Note Well
	Draft status:
	  - Most published as RFCs or in RFC Editor's queue
	  - iSNS MIB Last Call is done.  Minor revision needed to deal
			with comments from WG's MIB expert, should submit to
			ADs/IESG in next few months.
	  - Implementers Guide will probably go to WG Last call sometime
			in 2007.  It's ok for this to remain open for a
while.
	Milestones - see charter on web site.

iSCSI Implementer's Guide: Mallikarjun Chadalapaka, HP - 1 hour
	(draft-ietf-ips-iscsi-impl-guide-02.txt)

	Includes proposed revisions/extensions to SCSI task set management

	(1) Response Ordering issue - multiple connections may reorder
		responses from target to initiator.  Often not a problem but
		sometimes SCSI cares (e.g., multi-task abort, ACA).

	-> Proposed solution: Response Fence to tell iSCSI when response
		ordering is necessary.  Assume that it is always needed for
		multi-task management and ACA.  Would be part of SAM
interface
		to SCSI transport (task management attribute).
	Task management already requires this for multi-task operations,
		proposal is to generalize this in the specification so that
		it can be defined once, used in multiple places, and made
		available to T10 (SCSI standards org) to specify it in other
		places where it is needed.

	Discussion: This may be difficult to get into SAM-x via T10.
		There will be reluctance to deal with multiple connections
in
		a single session (I_T Nexus).

	Sense of the room: Response Fence will be added to implementers
guide
		as a general mechanism to deal with SCSI situations that
need
		it.  Say that ACA and multi-task management always need it.
		Can be discussed w/T10, but we're not relying on T10 to pick
		this up.

	(2) Task Management - Want to speed-up multi-task abort (ABORT TASK
		SET, and especially CLEAR TASK SET).  Currently have to wait
		for transfers to complete and status acks to come back.

	-> Proposed solution: Provide faster TMF completion by avoiding
		waits for other initiators and avoiding wait for other tasks
		on same initiator (requires new key to negotiate latter, as
		it involves sending per-LUN async events to cause early
		transfer teardown vs. current approach of waiting for
		transfers to 	complete).  Nop-out used to ack async events
		- can combine acks to these events into a single Nop-out.

	Sense of room: Clarifications are good - they will not introduce
		cross-nexus dependencies on the RESET task management
functions.

	Sense of the room: New key is useful - put it into draft, allow
responder
		to come back with Yes, No, or Not Understood.  SHOULD vs.
		MAY decision deferred until we have draft text reflecting
this.
		This new key may be related to new T10 data transfer abort
		service in SAM for SAS.

iSNS MIB: David Black (WG chair) for Scott Kipp, McData - 10 min
	(draft-ietf-ips-isns-mib-08.txt)

	Scope reduced to read-only monitoring of server only.

iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min
	(draft-wysochanski-xkey-iscsi-support-00.txt)

	Asking for a standard key to allow implementation to say what
version
		of software, etc. it is running.  It's easy to get log from
one's
		own product, but harder to get the log from the other side.

	Declarative key (each side declares it once and may not redeclare
it).

	Security - need to say that if confidentiality is an issue, use
IPsec.

	Long discussion of abuse, and need to use wording in the draft to
		discourage it.

	Decision: Draft accepted as WG draft, security and abuse text to be
		worked out, starting on list.  New milestone will be added
to
		charter.

Discovery Extension Discussion - John Hufferd, Brocade - 5 min
	Preference, dealing with multi- environments containing
	things like InfiniBand and 10 Gigabit Ethernet

	Seems like a good thing, particularly for protocol flavor supported
	(iWarp, InfiniBand, etc.)

iSCSI Security Mechanisms: WG Members - time remaining (if any)

	The IETF Security Area has requested that IETF Working Groups plan
	to transition away from usage of MD5.  iSCSI CHAP currently uses
	MD5 in a fashion not directly threatened by the hash collision
	results known for MD5.  It's not clear what to do next - SHA-1
	has been registered for CHAP, SHA-256 has not, and RADIUS servers
	won't support either.  Perhaps something in EAP is appropriate.
	The question that needs to be answered is: What should the next
	iSCSI authentication mechanism be to supersede the current
	CHAP/MD5?

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Tue Mar 21 09:09:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLhXx-0007aL-H1; Tue, 21 Mar 2006 09:09:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhXv-0007a5-O9
	for ips@ietf.org; Tue, 21 Mar 2006 09:09:15 -0500
Received: from rwcrmhc11.comcast.net ([204.127.192.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhXs-0000fO-Pb
	for ips@ietf.org; Tue, 21 Mar 2006 09:09:15 -0500
Received: from ivvtdkv0981 (unknown[64.238.111.98])
	by comcast.net (rwcrmhc11) with SMTP
	id <20060321140910m1100bcntte>; Tue, 21 Mar 2006 14:09:11 +0000
Message-ID: <001b01c64cf1$06bd33d0$4f01a8c0@ivivity.com>
From: "Eddy Quicksall" 
To: "Mike Ko" 
References: 
Subject: Re: [Ips] TMF for a write with only unsolicited data
Date: Tue, 21 Mar 2006 09:09:09 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4138e425d106d6c5dc264596f67b5232
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1138479999=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1138479999==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0018_01C64CC7.1D0BE700"

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C64CC7.1D0BE700
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mike

Yes, I was talking about a TASK REASSIGN. Thanks ... your answer cleared =
up my misunderstanding.

Eddy
  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Cc: ips@ietf.org=20
  Sent: Monday, March 20, 2006 12:06 PM
  Subject: Re: [Ips] TMF for a write with only unsolicited data

  Eddy,=20

  The two bulleted items that you quoted are prefaced by the following =
statement:=20

  "For the Task Management Function Request with the TASK REASSIGN =
function, the iSER Layer at the initiator MUST do the following".=20

  In other words, DataDescriptorOut and/or DataDescriptorIn are used =
only when the TMF request is Task Reassign and the referenced task is a =
write (DataDescriptorOut) or read (DataDescriptorIn) or bidirectional =
(both) command.  Other than Task Reassign, there is no data transfer =
associated with the other TMF requests, either unsolicited or solicited, =
and hence there is no DataDescriptorOut or DataDescriptorIn.  =20

  Mike=20
  To:        "Mallikarjun C." ,  =

  cc:        =20
  Subject:        Re: [Ips] TMF for a write with only unsolicited data=20

  Mallikarjun,

  Then I think you must be saying the TMF for Abort Task does not use =
the=20
  qualifier DataDescriptorOut when there is solicited data. If so then =
when=20
  would the DataDescriptorOut and DataDescriptorIn be used with a TMF?

  7.3.3

  the iSER Layer at the initiator MUST do the following

    *  It MUST allocate a Read STag for the I/O Buffer as defined by the

       qualifier DataDescriptorIn if the Send_Control Operational

       Primitive invocation is qualified with DataDescriptorIn.

    *  It MUST allocate a Write STag for the I/O Buffer as defined by

       the qualifier DataDescriptorOut if the Send_Control Operational

       Primitive invocation is qualified with DataDescriptorOut.

  Eddy

  ----- Original Message -----=20
  From: "Mallikarjun C." 
  To: 
  Sent: Wednesday, March 15, 2006 7:58 PM
  Subject: Re: [Ips] TMF for a write with only unsolicited data

  > WSV=3D0 for TMF=3DAbort Task, always.
  >
  > Mallikarjun
  >
  >
  > --- Eddy Quicksall
  >  wrote:
  >
  >> So the paragraph below is saying the WSA would be 0
  >> if the Abort Task were aborting a Write that had
  >> only unsolicited data. That is the way I read it
  >> too. You further said that for this case there would
  >> be no DataDescriptorOut with the TMF call from the
  >> iSCSI layer to the iSER layer. I think that is now
  >> clear. Thanks.
  >>
  >> WSV - Write STag Valid flag: 1 bit
  >>
  >>      This flag indicates the validity of the Write
  >> STag field of the
  >>      iSER Header.  If set to one, the Write STag
  >> field in this iSER
  >>      Header is valid.  If set to zero, the Write
  >> STag field in this
  >>      iSER Header MUST be ignored at the receiver.
  >> The Write STag
  >>      Valid flag is set to one when there is
  >> solicited data to be
  >>      transferred for a SCSI Write or bidirectional
  >> command, or when
  >>      there are non-immediate unsolicited and
  >> solicited data to be
  >>      transferred for the referenced task specified
  >> in a Task
  >>      Management Function Request with the TASK
  >> REASSIGN function.
  >>
  >>
  >>   ----- Original Message -----=20
  >>   From: Mike Ko
  >>   To: Eddy Quicksall
  >>   Sent: Tuesday, March 14, 2006 12:58 PM
  >>   Subject: Re: [Ips] TMF for a write with only
  >> unsolicited data
  >>
  >>
  >>
  >>   Ergo, there is no DataDescriptorOut, and therefore
  >> no unsolicited data associated with the issuance of
  >> the Abort Task TMF.
  >>
  >>   Mike
  >>   To:        "Mike Ko" 
  >>   cc:
  >>   Subject:        Re: [Ips] TMF for a write with
  >> only unsolicited data
  >>
  >>
  >>   The TMF doesn't send any data. The TMF is aborting
  >> a task that has only unsolicited data.
  >>   ----- Original Message -----=20
  >>   From: Mike Ko
  >>   To: Eddy Quicksall
  >>   Sent: Tuesday, March 14, 2006 12:25 PM
  >>   Subject: Re: [Ips] TMF for a write with only
  >> unsolicited data
  >>
  >>
  >>   Eddy,
  >>
  >>   AFAIK, other than Task Reassign, no TMF requires
  >> sending any data.  The point of Abort Task is to
  >> kill that task and stop all work on the task, so
  >> sending data would be counter-productive.
  >>
  >>   Mike
  >>
  >>   To:        "Mike Ko" 
  >>   cc:
  >>   Subject:        Re: [Ips] TMF for a write with
  >> only unsolicited data
  >>
  >>
  >>   How about Abort Task?
  >>
  >>
  >>   Eddy
  >>   ----- Original Message -----=20
  >>   From: Mike Ko
  >>   To: Eddy Quicksall
  >>   Cc: ips@ietf.org
  >>   Sent: Tuesday, March 14, 2006 11:05 AM
  >>   Subject: Re: [Ips] TMF for a write with only
  >> unsolicited data
  >>
  >>
  >>   Eddy,
  >>
  >>   There are 8 task management function codes listed
  >> in RFC3720.  They are Abort Task, Abort Task Set,
  >> Clear ACA, Clear Task Set, Logical Unit Reset,
  >> Target Warm Reset, Target Cold Reset, and Task
  >> Reassign.  If your example is not Task Reassign,
  >> what TMF code do you have in mind where unsolicited
  >> write data would be sent?
  >>
  >>   Mike
  >>
  >>   To:        "Mike Ko" 
  >>   cc:        
  >>   Subject:        Re: [Ips] TMF for a write with
  >> only unsolicited data
  >>
  >>
  >>   No. The case is not a TASK REASSIGN. It is for a
  >> write command where all of the data is unsolicited.
  >>
  >>   If the STag is used for the associated R2T's then
  >> it would seem WSV would be set to 0 when no R2T's
  >> were issued.
  >>
  >>   Further it says "The Write STag
  >>        Valid flag is set to one when there is
  >> solicited data to be
  >>        transferred"
  >>
  >>   Doesn't that mean the STag is only used if there
  >> was solicited data with the command?
  >>
  >>   Eddy
  >>   ----- Original Message -----=20
  >>   From: Mike Ko
  >>   To: Eddy Quicksall
  >>   Cc: ips@ietf.org
  >>   Sent: Monday, March 13, 2006 7:14 PM
  >>   Subject: Re: [Ips] TMF for a write with only
  >> unsolicited data
  >>
  >>
  >>   If I understand your question correctly, I assume
  >> the TMF is a TASK REASSIGN and it is for a write
  >> command qualified with DataDescriptorOut.
  >> DataDescriptorOut is used to describe the I/O buffer
  >> starting with the immediate unsolicited data (if
  >> any), followed by the non-immediate unsolicited data
  >> (if any) and solicited data.  A Write STag is
  >> allocated in this case.  The Write STag is used by
  >> the iSER layer at the target in handling the data
  >> transfer associated with the R2T PDUs and in
  >> returning the SCSI Response PDU using the SendInvSE
  >> message.  Since there is non-immediate unsolicited
  >> data, WSV is set to 1.
  >>
  >>   Mike
  >>
  >>   To:        
  >>   cc:
  >>   Subject:        [Ips] TMF for a write with only
  >> unsolicited data
  >>
  >>
  >>   Suppose:
  >>   1) a TMF is not a TASK REASSIGN
  >>   2) the TMF is for a write command
  >>   3) the write command only has unsolicited data
  >>
  >>   I think this is saying the WSV is set to 0 for
  >> this case. Is that correct?
  >>
  >>   If so then I think the 3rd bullet item in 7.3.3
  >> needs to say "if allocated" since a write with
  >> unsolicited only will also have a DataDescriptorOut.
  >>
  >>
  >>   Or am I wrong in that the TMF would have the
  >> DataDescriptorOut for a write with only unsolicited
  >> data?
  >>
  >>   WSV - Write STag Valid flag: 1 bit
  >>
  >>        This flag indicates the validity of the Write
  >> STag field of the
  >>        iSER Header.  If set to one, the Write STag
  >> field in this iSER
  >>        Header is valid.  If set to zero, the Write
  >> STag field in this
  >>        iSER Header MUST be ignored at the receiver.
  >> The Write STag
  >>        Valid flag is set to one when there is
  >> solicited data to be
  >>        transferred for a SCSI Write or bidirectional
  >> command, or when
  >>        there are non-immediate unsolicited and
  >> solicited data to be
  >>        transferred for the referenced task specified
  >> in a Task
  >>        Management Function Request with the TASK
  >> REASSIGN function.
  >>
  >>   7.3.3  Task Management Function Request/Response
  >>
  >>   *  It MUST use the ITT as specified in the
  >> Referenced Task Tag from
  >>      the Task Management Function Request PDU to
  >> locate the existing
  >>      STag(s), if any, in the Local Mapping(s) that
  >> associates the ITT
  >>      to the local STag(s).
  >>
  >>   *  It MUST invalidate the existing STag(s), if
  >> any, and the Local
  >>      Mapping(s) that associates the ITT to the local
  >> STag(s).
  >>
  >>   *  It MUST allocate a Read STag for the I/O Buffer
  >> as defined by the
  >>      qualifier DataDescriptorIn if the Send_Control
  >> Operational
  >>      Primitive invocation is qualified with
  >> DataDescriptorIn.
  >>
  >>
  >>
  >> Eddy_______________________________________________
  >>   Ips mailing list
  >>   Ips@ietf.org
  >>   https://www1.ietf.org/mailman/listinfo/ips
  >>
  >>
  >>
  >>
  > =
-------------------------------------------------------------------------=
-----
  >>
  >>   _______________________________________________
  >>   Ips mailing list
  >>   Ips@ietf.org
  >>   https://www1.ietf.org/mailman/listinfo/ips
  >>
  >> > _______________________________________________
  >> Ips mailing list
  >> Ips@ietf.org
  >> https://www1.ietf.org/mailman/listinfo/ips
  >>
  >
  >
  > __________________________________________________
  > Do You Yahoo!?
  > Tired of spam?  Yahoo! Mail has the best spam protection around
  > http://mail.yahoo.com
  >
  > _______________________________________________
  > Ips mailing list
  > Ips@ietf.org
  > https://www1.ietf.org/mailman/listinfo/ips=20

  _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips

-------------------------------------------------------------------------=
-----

  _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0018_01C64CC7.1D0BE700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mike

Yes, I was talking about a TASK REASSIGN. Thanks ... =
your=20
answer cleared up my misunderstanding.

Eddy

  ----- Original Message ----- 
  From:=20
  Mike Ko=20

  To: Eddy =
Quicksall=20

  Cc: ips@ietf.org 
  Sent: Monday, March 20, 2006 =
12:06=20
  PM
  Subject: Re: [Ips] TMF for a =
write with=20
  only unsolicited data

Eddy, =

The two bulleted items that you quoted are =
prefaced by=20
  the following statement: 

"For the=20
  Task Management Function Request with the TASK REASSIGN function, the =
iSER=20
  Layer at the initiator MUST do the following". 

In other words, DataDescriptorOut and/or=20
  DataDescriptorIn are used only when the TMF request is Task Reassign =
and the=20
  referenced task is a write (DataDescriptorOut) or read =
(DataDescriptorIn) or=20
  bidirectional (both) command.  Other than Task Reassign, there is =
no data=20
  transfer associated with the other TMF requests, either unsolicited or =

  solicited, and hence there is no DataDescriptorOut or =
DataDescriptorIn.=20

Mike 
  To:     =
 =20
   "Mallikarjun C."=20
  <cb_mallikarjun@yahoo.com>, <ips@ietf.org> =

cc:       =
 =20

Subject: =
   =20
     Re: [Ips] TMF for =
a write=20
  with only unsolicited data 

Mallikarjun,

Then I think you must be saying the =
TMF for=20
  Abort Task does not use the 
qualifier DataDescriptorOut when there =
is=20
  solicited data. If so then when 
would the DataDescriptorOut and=20
  DataDescriptorIn be used with a TMF?

7.3.3

the iSER =
Layer at the=20
  initiator MUST do the following

  *  It MUST allocate =
a Read=20
  STag for the I/O Buffer as defined by the

    =
 qualifier=20
  DataDescriptorIn if the Send_Control Operational

   =20
   Primitive invocation is qualified with=20
  DataDescriptorIn.

  *  It MUST allocate a =
Write STag=20
  for the I/O Buffer as defined by

     the =
qualifier=20
  DataDescriptorOut if the Send_Control Operational

    =

   Primitive invocation is qualified with=20
  DataDescriptorOut.

Eddy

----- =
Original=20
  Message ----- 
From: "Mallikarjun C."=20
  <cb_mallikarjun@yahoo.com>
To: <ips@ietf.org>
Sent:=20
  Wednesday, March 15, 2006 7:58 PM
Subject: Re: [Ips] TMF for a =
write with=20
  only unsolicited data

> WSV=3D0 for TMF=3DAbort Task,=20
  always.
>
> Mallikarjun
>
>
> --- Eddy=20
  Quicksall
> <eddy_quicksall_iVivity_iSCSI@Comcast.net>=20
  wrote:
>
>> So the paragraph below is saying the WSA =
would be=20
  0
>> if the Abort Task were aborting a Write that =
had
>>=20
  only unsolicited data. That is the way I read it
>> too. You =
further=20
  said that for this case there would
>> be no =
DataDescriptorOut with=20
  the TMF call from the
>> iSCSI layer to the iSER layer. I =
think that=20
  is now
>> clear. Thanks.
>>
>> WSV - Write =
STag=20
  Valid flag: 1 bit
>>
>>      This =
flag=20
  indicates the validity of the Write
>> STag field of =
the
>>=20
       iSER Header.  If set to one, the Write=20
  STag
>> field in this iSER
>>     =
 Header is=20
  valid.  If set to zero, the Write
>> STag field in=20
  this
>>      iSER Header MUST be ignored at =
the=20
  receiver.
>> The Write STag
>>     =
 Valid=20
  flag is set to one when there is
>> solicited data to =
be
>>=20
       transferred for a SCSI Write or =
bidirectional
>>=20
  command, or when
>>      there are =
non-immediate=20
  unsolicited and
>> solicited data to be
>>   =
 =20
   transferred for the referenced task specified
>> in a=20
  Task
>>      Management Function Request with =
the=20
  TASK
>> REASSIGN =
function.
>>
>>
>>  =20
  ----- Original Message ----- 
>>   From: Mike =
Ko
>>=20
    To: Eddy Quicksall
>>   Sent: Tuesday, March 14, =
2006=20
  12:58 PM
>>   Subject: Re: [Ips] TMF for a write with=20
  only
>> unsolicited=20
  data
>>
>>
>>
>>   Ergo, =
there is no=20
  DataDescriptorOut, and therefore
>> no unsolicited data =
associated=20
  with the issuance of
>> the Abort Task =
TMF.
>>
>>=20
    Mike
>>   To:        "Mike =
Ko"=20
  <mako@almaden.ibm.com>
>>   cc:
>>   =

  Subject:        Re: [Ips] TMF for a write =
with
>>=20
  only unsolicited data
>>
>>
>>   The =
TMF=20
  doesn't send any data. The TMF is aborting
>> a task that has =
only=20
  unsolicited data.
>>   ----- Original Message ----- =

>>=20
    From: Mike Ko
>>   To: Eddy Quicksall
>> =
 =20
  Sent: Tuesday, March 14, 2006 12:25 PM
>>   Subject: Re: =
[Ips]=20
  TMF for a write with only
>> unsolicited=20
  data
>>
>>
>>   =
Eddy,
>>
>>=20
    AFAIK, other than Task Reassign, no TMF requires
>> =
sending=20
  any data.  The point of Abort Task is to
>> kill that =
task and=20
  stop all work on the task, so
>> sending data would be=20
  counter-productive.
>>
>>  =20
  Mike
>>
>>   To:       =
 "Mike Ko"=20
  <mako@almaden.ibm.com>
>>   cc:
>>   =

  Subject:        Re: [Ips] TMF for a write =
with
>>=20
  only unsolicited data
>>
>>
>>   How =
about=20
  Abort Task?
>>
>>
>>   =
Eddy
>>  =20
  ----- Original Message ----- 
>>   From: Mike =
Ko
>>=20
    To: Eddy Quicksall
>>   Cc: =
ips@ietf.org
>>=20
    Sent: Tuesday, March 14, 2006 11:05 AM
>>   =
Subject: Re:=20
  [Ips] TMF for a write with only
>> unsolicited=20
  data
>>
>>
>>   =
Eddy,
>>
>>=20
    There are 8 task management function codes listed
>> =
in=20
  RFC3720.  They are Abort Task, Abort Task Set,
>> Clear =
ACA,=20
  Clear Task Set, Logical Unit Reset,
>> Target Warm Reset, =
Target Cold=20
  Reset, and Task
>> Reassign.  If your example is not =
Task=20
  Reassign,
>> what TMF code do you have in mind where=20
  unsolicited
>> write data would be =
sent?
>>
>>=20
    Mike
>>
>>   To:      =20
   "Mike Ko" <mako@almaden.ibm.com>
>>   cc: =
 =20
       <ips@ietf.org>
>>   Subject: =
 =20
       Re: [Ips] TMF for a write with
>> only=20
  unsolicited data
>>
>>
>>   No. The =
case is=20
  not a TASK REASSIGN. It is for a
>> write command where all =
of the=20
  data is unsolicited.
>>
>>   If the STag is =
used for=20
  the associated R2T's then
>> it would seem WSV would be set =
to 0 when=20
  no R2T's
>> were issued.
>>
>>   =
Further it=20
  says "The Write STag
>>        Valid flag =
is set=20
  to one when there is
>> solicited data to be
>> =
 =20
       transferred"
>>
>>   =
Doesn't that=20
  mean the STag is only used if there
>> was solicited data =
with the=20
  command?
>>
>>   Eddy
>>   ----- =
Original=20
  Message ----- 
>>   From: Mike Ko
>>   To: =
Eddy=20
  Quicksall
>>   Cc: ips@ietf.org
>>   Sent: =
Monday,=20
  March 13, 2006 7:14 PM
>>   Subject: Re: [Ips] TMF for a =
write=20
  with only
>> unsolicited =
data
>>
>>
>>=20
    If I understand your question correctly, I assume
>> =
the TMF=20
  is a TASK REASSIGN and it is for a write
>> command qualified =
with=20
  DataDescriptorOut.
>> DataDescriptorOut is used to describe =
the I/O=20
  buffer
>> starting with the immediate unsolicited data=20
  (if
>> any), followed by the non-immediate unsolicited=20
  data
>> (if any) and solicited data.  A Write STag=20
  is
>> allocated in this case.  The Write STag is used=20
  by
>> the iSER layer at the target in handling the =
data
>>=20
  transfer associated with the R2T PDUs and in
>> returning the =
SCSI=20
  Response PDU using the SendInvSE
>> message.  Since =
there is=20
  non-immediate unsolicited
>> data, WSV is set to=20
  1.
>>
>>   Mike
>>
>>   =
To:=20
         <ips@ietf.org>
>>  =20
  cc:
>>   Subject:        [Ips] TMF =
for a=20
  write with only
>> unsolicited=20
  data
>>
>>
>>   Suppose:
>> =
  1)=20
  a TMF is not a TASK REASSIGN
>>   2) the TMF is for a =
write=20
  command
>>   3) the write command only has unsolicited=20
  data
>>
>>   I think this is saying the WSV is =
set to 0=20
  for
>> this case. Is that correct?
>>
>> =
  If=20
  so then I think the 3rd bullet item in 7.3.3
>> needs to say =
"if=20
  allocated" since a write with
>> unsolicited only will also =
have a=20
  DataDescriptorOut.
>>
>>
>>   Or am I =
wrong in=20
  that the TMF would have the
>> DataDescriptorOut for a write =
with=20
  only unsolicited
>> data?
>>
>>   WSV =
- Write=20
  STag Valid flag: 1 bit
>>
>>       =
 This=20
  flag indicates the validity of the Write
>> STag field of=20
  the
>>        iSER Header.  If set =
to one,=20
  the Write STag
>> field in this iSER
>>   =
   =20
   Header is valid.  If set to zero, the Write
>> =
STag field=20
  in this
>>        iSER Header MUST be =
ignored at=20
  the receiver.
>> The Write STag
>>     =
 =20
   Valid flag is set to one when there is
>> solicited =
data to=20
  be
>>        transferred for a SCSI Write =
or=20
  bidirectional
>> command, or when
>>     =
 =20
   there are non-immediate unsolicited and
>> solicited =
data to=20
  be
>>        transferred for the =
referenced task=20
  specified
>> in a Task
>>      =20
   Management Function Request with the TASK
>> REASSIGN=20
  function.
>>
>>   7.3.3  Task Management =
Function=20
  Request/Response
>>
>>   *  It MUST use =
the ITT as=20
  specified in the
>> Referenced Task Tag from
>> =
 =20
     the Task Management Function Request PDU to
>> =
locate=20
  the existing
>>      STag(s), if any, in the =
Local=20
  Mapping(s) that
>> associates the ITT
>>   =
 =20
   to the local STag(s).
>>
>>   *  It =
MUST=20
  invalidate the existing STag(s), if
>> any, and the =
Local
>>=20
       Mapping(s) that associates the ITT to the=20
  local
>> STag(s).
>>
>>   *  It =
MUST=20
  allocate a Read STag for the I/O Buffer
>> as defined by=20
  the
>>      qualifier DataDescriptorIn if the=20
  Send_Control
>> Operational
>>     =
 Primitive=20
  invocation is qualified with
>>=20
  DataDescriptorIn.
>>
>>
>>
>>=20
  Eddy_______________________________________________
>>   =
Ips=20
  mailing list
>>   Ips@ietf.org
>>  =20
  =
https://www1.ietf.org/mailman/listinfo/ips
>>
>>
>=
;>
>>
>=20
  =
-------------------------------------------------------------------------=
-----
>>
>>=20
    _______________________________________________
>> =
  Ips=20
  mailing list
>>   Ips@ietf.org
>>  =20
  https://www1.ietf.org/mailman/listinfo/ips
>>
>> =
>=20
  _______________________________________________
>> Ips =
mailing=20
  list
>> Ips@ietf.org
>>=20
  =
https://www1.ietf.org/mailman/listinfo/ips
>>
>
>>=20
  __________________________________________________
> Do You=20
  Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam =
protection=20
  around
> http://mail.yahoo.com
>
>=20
  _______________________________________________
> Ips mailing=20
  list
> Ips@ietf.org
> =
https://www1.ietf.org/mailman/listinfo/ips=20

_______________________________________________
Ips =
mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0018_01C64CC7.1D0BE700--

--===============1138479999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1138479999==--

From ips-bounces@ietf.org Wed Mar 22 01:53:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLxDy-0005lU-HA; Wed, 22 Mar 2006 01:53:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxDx-0005lO-PQ
	for ips@ietf.org; Wed, 22 Mar 2006 01:53:41 -0500
Received: from taurus.voltaire.com ([193.47.165.240])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLxDv-0000l3-8K
	for ips@ietf.org; Wed, 22 Mar 2006 01:53:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Mar 2006 08:53:38 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: iSCSI- duplicate initiator name
Thread-Index: AcZNfVhtJ1J3dhhZSmCaobuxS+pQMQ==
From: "Inbal Zilbershmidt" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Subject: [Ips] iSCSI- duplicate initiator name
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0860220170=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0860220170==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64D7D.58BB405F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64D7D.58BB405F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
Maybe someone can help me:
=20
I wanted to know how a target should react in a case when an initiator
trying to connect to it, has the same name as other initiator already
connected.
=20
Thanks,
=20
Inbal ,
Voltaire Ltd.
=20
=20

------_=_NextPart_001_01C64D7D.58BB405F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Maybe =
someone can=20
help me:

I =
wanted to know how=20
a target should react in a case when an initiator trying to connect to =
it, has=20
the same name as other initiator already connected.

Thanks,

Inbal=20
,
Voltaire=20
Ltd.

------_=_NextPart_001_01C64D7D.58BB405F--

--===============0860220170==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0860220170==--

From ips-bounces@ietf.org Wed Mar 22 02:00:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLxKs-0001nY-Ep; Wed, 22 Mar 2006 02:00:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLxKq-0001kY-SW
	for ips@ietf.org; Wed, 22 Mar 2006 02:00:48 -0500
Received: from mail75.messagelabs.com ([216.82.250.3])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLxKq-00016l-9g
	for ips@ietf.org; Wed, 22 Mar 2006 02:00:48 -0500
X-VirusChecked: Checked
X-Env-Sender: jhufferd@Brocade.COM
X-Msg-Ref: server-13.tower-75.messagelabs.com!1143010845!64837891!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [66.243.153.112]
Received: (qmail 23769 invoked from network); 22 Mar 2006 07:00:45 -0000
Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112)
	by server-13.tower-75.messagelabs.com with SMTP;
	22 Mar 2006 07:00:45 -0000
Received: from hq-ex-2.corp.brocade.com (hq-ex-2 [192.168.38.63])
	by blasphemy.brocade.com (Postfix) with ESMTP id 69FAF14256;
	Tue, 21 Mar 2006 23:00:45 -0800 (PST)
Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by
	hq-ex-2.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Tue, 21 Mar 2006 23:00:45 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSCSI- duplicate initiator name
Date: Tue, 21 Mar 2006 23:00:44 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] iSCSI- duplicate initiator name
Thread-Index: AcZNfVhtJ1J3dhhZSmCaobuxS+pQMQAAFaWQ
From: "John Hufferd" 
To: "Inbal Zilbershmidt" , 
X-OriginalArrivalTime: 22 Mar 2006 07:00:45.0406 (UTC)
	FILETIME=[57647FE0:01C64D7E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============2079165184=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2079165184==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64D7E.56F4E3E3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64D7E.56F4E3E3
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

The important question is how do you know it is another initiator.  If
it has the same name it could be from any portal on the Initiator
system.  The initiator name applies to the Whole OS.  In fact it can
also apply to a whole cluster that acts as a system coupled system.  So
if it passes the authentication tests, it is assumed to be from that OS,
and multiple Sessions from the same OS is OK. =20

=20

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=20

  _____ =20

From: Inbal Zilbershmidt [mailto:inbalz@voltaire.com]=20
Sent: Tuesday, March 21, 2006 10:54 PM
To: ips@ietf.org
Subject: [Ips] iSCSI- duplicate initiator name

=20

Hello,

=20

Maybe someone can help me:

=20

I wanted to know how a target should react in a case when an initiator
trying to connect to it, has the same name as other initiator already
connected.

=20

Thanks,

=20

Inbal ,

Voltaire Ltd.

=20

=20

------_=_NextPart_001_01C64D7E.56F4E3E3
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

The important question is how do =
you know
it is another initiator.  If it has the same name it could be from =
any
portal on the Initiator system.  The initiator name applies to the =
Whole
OS.  In fact it can also apply to a whole cluster that acts as a =
system
coupled system.  So if it passes the authentication tests, it is =
assumed
to be from that OS, and multiple Sessions from the same OS is OK.  =

.

.

.

John L Hufferd

Sr. Executive Director of =
Technology

Brocade Communications Systems, =
Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; =
eFAX: (408)
904-4688

Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606

From: Inbal
Zilbershmidt [mailto:inbalz@voltaire.com] 

Sent: Tuesday, March 21, =
2006
10:54 PM

To: ips@ietf.org

Subject: [Ips] iSCSI- =
duplicate
initiator name

Hello,

Maybe someone can help =
me:

I wanted to know how a target should react in a case =
when an
initiator trying to connect to it, has the same name as other initiator =
already
connected.

Thanks,

Inbal ,

Voltaire Ltd.

------_=_NextPart_001_01C64D7E.56F4E3E3--

--===============2079165184==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============2079165184==--

From ips-bounces@ietf.org Wed Mar 22 08:34:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM3Th-0005My-2t; Wed, 22 Mar 2006 08:34:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Tg-0005Mt-EM
	for ips@ietf.org; Wed, 22 Mar 2006 08:34:20 -0500
Received: from taurus.voltaire.com ([193.47.165.240])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Tf-0007R6-Pq
	for ips@ietf.org; Wed, 22 Mar 2006 08:34:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSCSI- duplicate initiator name
Date: Wed, 22 Mar 2006 15:34:18 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] iSCSI- duplicate initiator name
Thread-Index: AcZNfVhtJ1J3dhhZSmCaobuxS+pQMQAAFaWQAASaZIA=
From: "Inbal Zilbershmidt" 
To: "John Hufferd" ,

X-Spam-Score: 0.0 (/)
X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1522817545=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1522817545==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64DB5.519EF901"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64DB5.519EF901
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is it possible to have 2 leading connections from the same initiator?
Isn't a session implies an IT nexus?
As I understood, it is possible to have multiple connections in a single
session.
My question was regarding to a 2nd leading connection from a certain
initiator name. I caused such situation by giving two different
initiators the same name.
I wanted to know how should I deal with such case.
=20

Thanks,

=20

Inbal ,

Voltaire Ltd.

________________________________

From: John Hufferd [mailto:jhufferd@Brocade.COM]=20
Sent: Wednesday, March 22, 2006 9:01 AM
To: Inbal Zilbershmidt; ips@ietf.org
Subject: RE: [Ips] iSCSI- duplicate initiator name

The important question is how do you know it is another initiator.  If
it has the same name it could be from any portal on the Initiator
system.  The initiator name applies to the Whole OS.  In fact it can
also apply to a whole cluster that acts as a system coupled system.  So
if it passes the authentication tests, it is assumed to be from that OS,
and multiple Sessions from the same OS is OK. =20

=20

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=20

________________________________

From: Inbal Zilbershmidt [mailto:inbalz@voltaire.com]=20
Sent: Tuesday, March 21, 2006 10:54 PM
To: ips@ietf.org
Subject: [Ips] iSCSI- duplicate initiator name

=20

Hello,

=20

Maybe someone can help me:

=20

I wanted to know how a target should react in a case when an initiator
trying to connect to it, has the same name as other initiator already
connected.

=20

Thanks,

=20

Inbal ,

Voltaire Ltd.

=20

=20

------_=_NextPart_001_01C64DB5.519EF901
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is it=20
possible to have 2 leading connections from the same initiator? =
Isn't a =
session implies=20
an IT nexus?
As I understood, it is possible to =
have multiple=20
connections in a single session.
My=20
question was regarding to a 2nd leading connection from a certain =
initiator=20
name. I caused such situation by giving two different =
initiators the same=20
name.
I=20
wanted to know how should I deal with such case.

Thanks,

Inbal=20
,

Voltaire=20
Ltd.

From: John Hufferd =
[mailto:jhufferd@Brocade.COM]=20

Sent: Wednesday, March 22, 2006 9:01 AM
To: Inbal=20
Zilbershmidt; ips@ietf.org
Subject: RE: [Ips] iSCSI- duplicate =

initiator name

The important =
question=20
is how do you know it is another initiator.  If it has the same =
name it=20
could be from any portal on the Initiator system.  The initiator =
name=20
applies to the Whole OS.  In fact it can also apply to a whole =
cluster that=20
acts as a system coupled system.  So if it passes the =
authentication tests,=20
it is assumed to be from that OS, and multiple Sessions from the same OS =
is=20
OK.  

.
.
.
John L Hufferd
Sr. Executive Director of=20
Technology
Brocade Communications Systems,=20
Inc
jhufferd@brocade.com
Office Phone: (408) 333-5244; =
eFAX: (408)=20
904-4688
Alt Office Phone: (408) 997-6136; =
Cell:=20
(408) 627-9606

From: Inbal=20
Zilbershmidt [mailto:inbalz@voltaire.com] 
Sent: Tuesday, March 21, 2006 =
10:54=20
PM
To: =
ips@ietf.org
Subject: [Ips] iSCSI- duplicate =
initiator=20
name

Hello,

Maybe someone can help=20
me:

I wanted to know how a =
target should=20
react in a case when an initiator trying to connect to it, has the same =
name as=20
other initiator already connected.

Thanks,

Inbal=20
,

Voltaire=20
Ltd.

------_=_NextPart_001_01C64DB5.519EF901--

--===============1522817545==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1522817545==--

From ips-bounces@ietf.org Wed Mar 22 09:42:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM4Xj-0003tF-4p; Wed, 22 Mar 2006 09:42:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4Xi-0003sp-8l
	for ips@ietf.org; Wed, 22 Mar 2006 09:42:34 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM4Xg-00024g-7O
	for ips@ietf.org; Wed, 22 Mar 2006 09:42:34 -0500
Received: from fe-amer-02.sun.com ([192.18.108.176])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2MEgUQj000008
	for ; Wed, 22 Mar 2006 07:42:31 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	id <0IWJ001019R20U00@mail-amer.sun.com>
	(original mail from Paul.Vonbehren@Sun.COM) for ips@ietf.org; Wed,
	22 Mar 2006 07:42:30 -0700 (MST)
Received: from [129.147.50.142] by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	with ESMTPSA id <0IWJ00A4IA6UA0O3@mail-amer.sun.com>; Wed,
	22 Mar 2006 07:42:30 -0700 (MST)
Date: Wed, 22 Mar 2006 07:42:27 -0700
From: Paul von Behren 
Subject: Re: [Ips] iSCSI- duplicate initiator name
In-reply-to: 
To: Inbal Zilbershmidt 
Message-id: <44216253.6080302@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: ips@ietf.org, John Hufferd 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

There are differences between path management via iSCSI session and path 
management via SCSI standards (SPC ALUA/TPGS) or SCSI-based, 
vendor-specific path management.  Outside of iSCSI, multipathing is 
typically done at the SCSI layer, providing per-LUN configuration 
options from the host drivers (e.g., customer wants path A dedicated to 
LUN 7 and LUNs 0-6 all share path B).  A host/driver implmentation may 
want to contiue providing that capability even in iSCSI.  iSCSI sessions 
hide the per-LUN paths.  You could set up separate target nodes for each 
LUN and get the same effect in iSCSI, but you can also opt for 
consistency with other SCSI transports.  This is one scenario where the 
same initiator may want multiple connections to the same target.

Paul

Inbal Zilbershmidt wrote:

> Is it possible to have 2 leading connections from the same initiator? 
> Isn't a session implies an IT nexus?
> As I understood, it is possible to have multiple connections in a 
> single session.
> My question was regarding to a 2nd leading connection from a certain 
> initiator name. I caused such situation by giving two different 
> initiators the same name.
> I wanted to know how should I deal with such case.
>  
>
> Thanks,
>
>  
>
> Inbal ,
>
> Voltaire Ltd.
>
>
> ------------------------------------------------------------------------
> *From:* John Hufferd [mailto:jhufferd@Brocade.COM]
> *Sent:* Wednesday, March 22, 2006 9:01 AM
> *To:* Inbal Zilbershmidt; ips@ietf.org
> *Subject:* RE: [Ips] iSCSI- duplicate initiator name
>
> The important question is how do you know it is another initiator.  If 
> it has the same name it could be from any portal on the Initiator 
> system.  The initiator name applies to the Whole OS.  In fact it can 
> also apply to a whole cluster that acts as a system coupled system. 
>  So if it passes the authentication tests, it is assumed to be from 
> that OS, and multiple Sessions from the same OS is OK. 
>
>  
>
> .
>
> .
>
> .
>
> John L Hufferd
>
> Sr. Executive Director of Technology
>
> Brocade Communications Systems, Inc
>
> jhufferd@brocade.com 
>
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Inbal Zilbershmidt [mailto:inbalz@voltaire.com]
> *Sent:* Tuesday, March 21, 2006 10:54 PM
> *To:* ips@ietf.org
> *Subject:* [Ips] iSCSI- duplicate initiator name
>
>  
>
> Hello,
>
>  
>
> Maybe someone can help me:
>
>  
>
> I wanted to know how a target should react in a case when an initiator 
> trying to connect to it, has the same name as other initiator already 
> connected.
>
>  
>
> Thanks,
>
>  
>
> Inbal ,
>
> Voltaire Ltd.
>
>  
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ips mailing list
>Ips@ietf.org
>https://www1.ietf.org/mailman/listinfo/ips
>  
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Wed Mar 22 09:44:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM4Zb-0004EJ-3J; Wed, 22 Mar 2006 09:44:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4ZZ-0004EC-D5
	for ips@ietf.org; Wed, 22 Mar 2006 09:44:29 -0500
Received: from mail136.messagelabs.com ([216.82.249.3])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM4ZY-00026W-Ml
	for ips@ietf.org; Wed, 22 Mar 2006 09:44:29 -0500
X-VirusChecked: Checked
X-Env-Sender: jhufferd@Brocade.COM
X-Msg-Ref: server-4.tower-136.messagelabs.com!1143038666!5194820!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [66.243.153.112]
Received: (qmail 8647 invoked from network); 22 Mar 2006 14:44:26 -0000
Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112)
	by server-4.tower-136.messagelabs.com with SMTP;
	22 Mar 2006 14:44:26 -0000
Received: from hq-ex-2.corp.brocade.com (hq-ex-2 [192.168.38.63])
	by blasphemy.brocade.com (Postfix) with ESMTP id 28D0114259;
	Wed, 22 Mar 2006 06:44:26 -0800 (PST)
Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by
	hq-ex-2.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Wed, 22 Mar 2006 06:44:26 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSCSI- duplicate initiator name
Date: Wed, 22 Mar 2006 06:44:25 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] iSCSI- duplicate initiator name
Thread-Index: AcZNfVhtJ1J3dhhZSmCaobuxS+pQMQAAFaWQAASaZIAACxhpIA==
From: "John Hufferd" 
To: "Inbal Zilbershmidt" , 
X-OriginalArrivalTime: 22 Mar 2006 14:44:26.0148 (UTC)
	FILETIME=[1DD8D640:01C64DBF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1771897143=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1771897143==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64DBF.1D961C0D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64DBF.1D961C0D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

All leading connections from the same OS should have the same Initiator
Name.  Each one is a separate I-T Nexus.  Each one will have a different
ISID.

=20

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=20

  _____ =20

From: Inbal Zilbershmidt [mailto:inbalz@voltaire.com]=20
Sent: Wednesday, March 22, 2006 5:34 AM
To: John Hufferd; ips@ietf.org
Subject: RE: [Ips] iSCSI- duplicate initiator name

=20

Is it possible to have 2 leading connections from the same initiator?
Isn't a session implies an IT nexus?

As I understood, it is possible to have multiple connections in a single
session.

My question was regarding to a 2nd leading connection from a certain
initiator name. I caused such situation by giving two different
initiators the same name.

I wanted to know how should I deal with such case.

=20

Thanks,

=20

Inbal ,

Voltaire Ltd.

=20

  _____ =20

From: John Hufferd [mailto:jhufferd@Brocade.COM]=20
Sent: Wednesday, March 22, 2006 9:01 AM
To: Inbal Zilbershmidt; ips@ietf.org
Subject: RE: [Ips] iSCSI- duplicate initiator name

The important question is how do you know it is another initiator.  If
it has the same name it could be from any portal on the Initiator
system.  The initiator name applies to the Whole OS.  In fact it can
also apply to a whole cluster that acts as a system coupled system.  So
if it passes the authentication tests, it is assumed to be from that OS,
and multiple Sessions from the same OS is OK. =20

=20

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=20

  _____ =20

From: Inbal Zilbershmidt [mailto:inbalz@voltaire.com]=20
Sent: Tuesday, March 21, 2006 10:54 PM
To: ips@ietf.org
Subject: [Ips] iSCSI- duplicate initiator name

=20

Hello,

=20

Maybe someone can help me:

=20

I wanted to know how a target should react in a case when an initiator
trying to connect to it, has the same name as other initiator already
connected.

=20

Thanks,

=20

Inbal ,

Voltaire Ltd.

=20

=20

------_=_NextPart_001_01C64DBF.1D961C0D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

All leading connections from the =
same OS
should have the same Initiator Name.  Each one is a separate I-T =
Nexus. 
Each one will have a different ISID.

.

.

.

John L Hufferd

Sr. Executive Director of =
Technology

Brocade Communications Systems, =
Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; =
eFAX: (408)
904-4688

Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606

From: Inbal
Zilbershmidt [mailto:inbalz@voltaire.com] 

Sent: Wednesday, March =
22, 2006
5:34 AM

To: John Hufferd; =
ips@ietf.org

Subject: RE: [Ips] iSCSI-
duplicate initiator name

Is it possible to have 2 leading
connections from the same initiator? Isn't a session implies an IT =
nexus?

As I understood, it is possible to =
have
multiple connections in a single session.

My question was regarding to a 2nd =
leading
connection from a certain initiator name. I caused such situation by =
giving two
different initiators the same name.

I wanted to know how should I deal =
with
such case.

Thanks,

Inbal ,

Voltaire =
Ltd.

From: John
Hufferd [mailto:jhufferd@Brocade.COM] 

Sent: Wednesday, March =
22, 2006
9:01 AM

To: Inbal Zilbershmidt;
ips@ietf.org

Subject: RE: [Ips] iSCSI-
duplicate initiator name

The important question is how do =
you know
it is another initiator.  If it has the same name it could be from =
any
portal on the Initiator system.  The initiator name applies to the =
Whole
OS.  In fact it can also apply to a whole cluster that acts as a =
system
coupled system.  So if it passes the authentication tests, it is =
assumed
to be from that OS, and multiple Sessions from the same OS is OK.  =

.

.

.

John L Hufferd

Sr. Executive Director of =
Technology

Brocade Communications Systems, =
Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; =
eFAX: (408)
904-4688

Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606

From: Inbal
Zilbershmidt [mailto:inbalz@voltaire.com] 

Sent: Tuesday, March 21, =
2006
10:54 PM

To: ips@ietf.org

Subject: [Ips] iSCSI- =
duplicate
initiator name

Hello,

Maybe someone can help =
me:

I wanted to know how a target should react in a case =
when an
initiator trying to connect to it, has the same name as other initiator =
already
connected.

Thanks,

Inbal ,

Voltaire Ltd.

------_=_NextPart_001_01C64DBF.1D961C0D--

--===============1771897143==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1771897143==--

From ips-bounces@ietf.org Wed Mar 22 18:35:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMCrV-0003jl-8H; Wed, 22 Mar 2006 18:35:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCrU-0003ip-Ed
	for ips@ietf.org; Wed, 22 Mar 2006 18:35:32 -0500
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMCrU-0000LP-2t
	for ips@ietf.org; Wed, 22 Mar 2006 18:35:32 -0500
Received: from [130.129.128.196] (DHCP-Wireless-128-196.ietf65.org
	[130.129.128.196]) by mononoke.wasabisystems.com (Postfix) with ESMTP
	id B06368718A; Wed, 22 Mar 2006 18:35:26 -0500 (EST)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v749.3)
Message-Id: <7665A53A-96B1-43A6-9887-0368CC74C597@wasabisystems.com>
From: William Studenmund 
Subject: Re: [Ips] iSCSI- duplicate initiator name
Date: Wed, 22 Mar 2006 17:35:16 -0600
To: Inbal Zilbershmidt 
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.749.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: ips@ietf.org, John Hufferd 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1995812008=="
Errors-To: ips-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1995812008==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-11--592924769"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-11--592924769
Content-Type: multipart/alternative; boundary=Apple-Mail-10--592924811

--Apple-Mail-10--592924811
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Mar 22, 2006, at 7:34 AM, Inbal Zilbershmidt wrote:

> Is it possible to have 2 leading connections from the same  
> initiator? Isn't a session implies an IT nexus?
> As I understood, it is possible to have multiple connections in a  
> single session.
> My question was regarding to a 2nd leading connection from a  
> certain initiator name. I caused such situation by giving two  
> different initiators the same name.
> I wanted to know how should I deal with such case.

If something is logging in with the same initiator name and ISID as  
an existing session, and it further passes the security phase (either  
you are configured for no security or the new initiator successfully  
authenticated), then IT IS THE SAME INITIATOR.

You are supposed to follow the session reinstatement operations  
described in RFC 3720.

Doing anything else would have a number of other, severe, consequences.

We (Wasabi) have had customers end up with end-systems that all had  
the same initiator name and ISID. Since we have to do session  
reinstatement, we ended up having systems keep logging each other out.

Our solution was to add the IP address of a logging-in initiator to  
our log messages. Thus if you see 192.168.1.2 and 192.168.1.3 both  
using the same name over & over, you know what the problem is.

Take care,

Bill
--Apple-Mail-10--592924811
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

On Mar 22, 2006, at =
7:34 AM, Inbal Zilbershmidt wrote:

 =
Is it possible to have 2 =
leading connections from the same =
initiator? Isn't a session implies an IT =
nexus?
 As I understood, it is possible to have multiple connections =
in a single session.
 My question was regarding to a 2nd leading connection from a =
certain initiator name. I caused such situation by giving two different =
initiators=A0the same name.
 I wanted to know how should I deal with such =
case.

If something is =
logging in with the same initiator name and ISID as an existing session, =
and it further passes the security phase (either you are configured for =
no security or the new initiator successfully authenticated), then IT IS =
THE SAME INITIATOR.

You are supposed to follow =
the session reinstatement operations described in RFC =
3720.

Doing =
anything else would have a number of other, severe, =
consequences.

We (Wasabi) have had =
customers end up with end-systems that all had the same initiator name =
and ISID. Since we have to do session reinstatement, we ended up having =
systems keep logging each other out.

Our solution was to add the =
IP address of a logging-in initiator to our log messages. Thus if you =
see 192.168.1.2 and 192.168.1.3 both using the same name over & =
over, you know what the problem is.

Take care,

Bill=

--Apple-Mail-10--592924811--

--Apple-Mail-11--592924769
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEId87DJT2Egh26K0RAtZ8AJ42kd6YVKlMkGcx2BRLqLO/VMi6sgCfdDBt
UQGER1gXvVf/Dsk8pcU39oU=
=+U3T
-----END PGP SIGNATURE-----

--Apple-Mail-11--592924769--

--===============1995812008==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1995812008==--

From ips-bounces@ietf.org Fri Mar 24 12:41:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMqHL-00059y-2X; Fri, 24 Mar 2006 12:40:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqHJ-00058E-56
	for ips@ietf.org; Fri, 24 Mar 2006 12:40:49 -0500
Received: from sccrmhc12.comcast.net ([63.240.77.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqHH-0003kW-SZ
	for ips@ietf.org; Fri, 24 Mar 2006 12:40:49 -0500
Received: from ivvtdkv0981 (unknown[64.238.111.98])
	by comcast.net (sccrmhc12) with SMTP
	id <200603241740470120070bjre>; Fri, 24 Mar 2006 17:40:47 +0000
Message-ID: <000e01c64f6a$16db0d20$4f01a8c0@ivivity.com>
From: "Eddy Quicksall" 
To: 
Date: Fri, 24 Mar 2006 12:40:48 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [Ips] iSER PDU-specific qualifiers
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0839424502=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0839424502==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C64F40.2D926D30"

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C64F40.2D926D30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Would it make sense to add a PDU-specific qualifier called PDUDescriptor =
to each item under "7.3 iSCSI PDUs"?

Eddy

------=_NextPart_000_000B_01C64F40.2D926D30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Would it make sense to add a PDU-specific qualifier =
called=20
PDUDescriptor to each item under "7.3 iSCSI PDUs"?

Eddy

------=_NextPart_000_000B_01C64F40.2D926D30--

--===============0839424502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0839424502==--

From ips-bounces@ietf.org Fri Mar 24 12:45:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMqLQ-0001jI-P7; Fri, 24 Mar 2006 12:45:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqLP-0001in-TE
	for ips@ietf.org; Fri, 24 Mar 2006 12:45:03 -0500
Received: from e3.ny.us.ibm.com ([32.97.182.143])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqLO-0003q7-Kx
	for ips@ietf.org; Fri, 24 Mar 2006 12:45:03 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e3.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	k2OHioYG031580 for ; Fri, 24 Mar 2006 12:44:50 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2OHibJE213076 for ; Fri, 24 Mar 2006 12:44:37 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2OHibEZ030715
	for ; Fri, 24 Mar 2006 12:44:37 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90])
	by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2OHibxE030710
	for ; Fri, 24 Mar 2006 12:44:37 -0500
In-Reply-To: <000e01c64f6a$16db0d20$4f01a8c0@ivivity.com>
Importance: Normal
MIME-Version: 1.0
Sensitivity: 
To: "Eddy Quicksall" 
Subject: Re: [Ips] iSER PDU-specific qualifiers
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: 
From: Mike Ko 
Date: Fri, 24 Mar 2006 09:44:36 -0800
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 |
	February 28, 2006) at 03/24/2006 12:44:36,
	Serialize complete at 03/24/2006 12:44:36
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1499610862=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============1499610862==
Content-Type: multipart/alternative;
	boundary="=_alternative 006176F88825713B_="

This is a multipart message in MIME format.
--=_alternative 006176F88825713B_=
Content-Type: text/plain; charset="US-ASCII"

What is the intent of PDUDescriptor?

Mike
To:     
cc:      
Subject:        [Ips] iSER PDU-specific qualifiers

Would it make sense to add a PDU-specific qualifier called PDUDescriptor 
to each item under "7.3 iSCSI PDUs"?

Eddy

 _______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 006176F88825713B_=
Content-Type: text/html; charset="US-ASCII"

What is the intent of PDUDescriptor?

Mike
To:      
 <ips@ietf.org>

cc:      

Subject:    
   [Ips] iSER PDU-specific
qualifiers

Would it make sense to add a PDU-specific qualifier called
PDUDescriptor to each item under "7.3 iSCSI PDUs"?

Eddy

 _______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 006176F88825713B_=--

--===============1499610862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1499610862==--

From ips-bounces@ietf.org Fri Mar 24 13:55:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMrRq-0005cj-5A; Fri, 24 Mar 2006 13:55:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrRo-0005Xk-II
	for ips@ietf.org; Fri, 24 Mar 2006 13:55:44 -0500
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMrRn-00061i-AH
	for ips@ietf.org; Fri, 24 Mar 2006 13:55:44 -0500
Received: from ivvtdkv0981 (unknown[64.238.111.98])
	by comcast.net (sccrmhc11) with SMTP
	id <200603241855420110026obne>; Fri, 24 Mar 2006 18:55:42 +0000
Message-ID: <003a01c64f74$8caaeb10$4f01a8c0@ivivity.com>
From: "Eddy Quicksall" 
To: "Mike Ko" 
References: 
Subject: Re: [Ips] iSER PDU-specific qualifiers
Date: Fri, 24 Mar 2006 13:55:41 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0611852156=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0611852156==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C64F4A.A36C0F20"

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C64F4A.A36C0F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It would point to the PDU.
  ----- Original Message -----=20
  From: Mike Ko=20
  To: Eddy Quicksall=20
  Cc: ips@ietf.org=20
  Sent: Friday, March 24, 2006 12:44 PM
  Subject: Re: [Ips] iSER PDU-specific qualifiers

  What is the intent of PDUDescriptor?=20

  Mike=20
  To:        =20
  cc:        =20
  Subject:        [Ips] iSER PDU-specific qualifiers=20

  Would it make sense to add a PDU-specific qualifier called =
PDUDescriptor to each item under "7.3 iSCSI PDUs"?=20
   =20
  Eddy=20
   =20
   _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips

-------------------------------------------------------------------------=
-----

  _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0037_01C64F4A.A36C0F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It would point to the PDU.

  ----- Original Message ----- 
  From:=20
  Mike Ko=20

  To: Eddy =
Quicksall=20

  Cc: ips@ietf.org 
  Sent: Friday, March 24, 2006 =
12:44=20
  PM
  Subject: Re: [Ips] iSER =
PDU-specific=20
  qualifiers

What is the intent =
of=20
  PDUDescriptor? 

Mike=20
  To:     =
 =20
   <ips@ietf.org> 
cc:       =
 =20

Subject: =
   =20
     [Ips] iSER =
PDU-specific=20
  qualifiers 

Would it make sense to =
add a=20
  PDU-specific qualifier called PDUDescriptor to each item under "7.3 =
iSCSI=20
  PDUs"? 

Eddy=20

 _______________________________________________
Ips =
mailing=20
  list
Ips@ietf.org
https://www1.ietf.org=
/mailman/listinfo/ips

_______________________________________________
Ips mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0037_01C64F4A.A36C0F20--

--===============0611852156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0611852156==--

From ips-bounces@ietf.org Fri Mar 24 14:10:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMrfk-0008NY-0a; Fri, 24 Mar 2006 14:10:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrfi-0008B7-Po
	for ips@ietf.org; Fri, 24 Mar 2006 14:10:06 -0500
Received: from e2.ny.us.ibm.com ([32.97.182.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMrfi-0006xw-63
	for ips@ietf.org; Fri, 24 Mar 2006 14:10:06 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	k2OJA5ut016673 for ; Fri, 24 Mar 2006 14:10:05 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2OJA0TD216222 for ; Fri, 24 Mar 2006 14:10:00 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2OJ9xDJ019520
	for ; Fri, 24 Mar 2006 14:09:59 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2OJ9wjn019479; 
	Fri, 24 Mar 2006 14:09:59 -0500
In-Reply-To: <003a01c64f74$8caaeb10$4f01a8c0@ivivity.com>
Importance: Normal
MIME-Version: 1.0
Sensitivity: 
To: "Eddy Quicksall" 
Subject: Re: [Ips] iSER PDU-specific qualifiers
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: 
From: Mike Ko 
Date: Fri, 24 Mar 2006 11:08:46 -0800
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 |
	February 28, 2006) at 03/24/2006 14:09:59,
	Serialize complete at 03/24/2006 14:09:59
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0161735793=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0161735793==
Content-Type: multipart/alternative;
	boundary="=_alternative 00692BE58825713B_="

This is a multipart message in MIME format.
--=_alternative 00692BE58825713B_=
Content-Type: text/plain; charset="US-ASCII"

Eddy,

As stated in the iSER draft, when "The iSCSI Layer requests the iSER Layer 
to process the iSCSI PDU by invoking the appropriate Operational 
Primitive", "BHS and the optional AHS of the iSCSI PDU as defined in 
[RFC3720] MUST qualify each of the invocations."  In addition, 
PDU-specific qualifers are used where needed.  The iSER layer has all the 
information it needs to process the PDU.  So no, I don't think it makes 
sense to add a PDUDescriptor qualifier.

Mike
To:     "Mike Ko" 
cc:      
Subject:        Re: [Ips] iSER PDU-specific qualifiers

It would point to the PDU.
----- Original Message ----- 
From: Mike Ko 
To: Eddy Quicksall 
Cc: ips@ietf.org 
Sent: Friday, March 24, 2006 12:44 PM
Subject: Re: [Ips] iSER PDU-specific qualifiers

What is the intent of PDUDescriptor? 

Mike 
To:         
cc: 
Subject:        [Ips] iSER PDU-specific qualifiers 

Would it make sense to add a PDU-specific qualifier called PDUDescriptor 
to each item under "7.3 iSCSI PDUs"? 

Eddy 

 _______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 00692BE58825713B_=
Content-Type: text/html; charset="US-ASCII"

Eddy,

As stated in the iSER draft, when "The
iSCSI Layer requests the iSER Layer to process the iSCSI PDU by invoking
the appropriate Operational Primitive", "BHS and the optional
AHS of the iSCSI PDU as defined in [RFC3720] MUST qualify each of the invocations."
 In addition, PDU-specific qualifers are used where needed.  The
iSER layer has all the information it needs to process the PDU.  So
no, I don't think it makes sense to add a PDUDescriptor qualifier.

Mike
To:      
 "Mike Ko"
<mako@almaden.ibm.com>

cc:      
 <ips@ietf.org>

Subject:    
   Re: [Ips] iSER
PDU-specific qualifiers

It would point to the PDU.

----- Original Message ----- 

From: Mike
Ko 

To: Eddy
Quicksall 

Cc: ips@ietf.org

Sent: Friday, March 24, 2006 12:44 PM

Subject: Re: [Ips] iSER PDU-specific qualifiers

What is the intent of PDUDescriptor? 

Mike 
To:      
 <ips@ietf.org>

cc:         

Subject:        [Ips]
iSER PDU-specific qualifiers 

Would it make sense to add a PDU-specific qualifier called PDUDescriptor
to each item under "7.3 iSCSI PDUs"? 

Eddy 

 _______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 00692BE58825713B_=--

--===============0161735793==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0161735793==--

From ips-bounces@ietf.org Fri Mar 24 21:38:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMyfQ-00012K-7S; Fri, 24 Mar 2006 21:38:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyfO-00012F-SN
	for ips@ietf.org; Fri, 24 Mar 2006 21:38:14 -0500
Received: from web51907.mail.yahoo.com ([206.190.48.70])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMyfO-0007Vc-Hy
	for ips@ietf.org; Fri, 24 Mar 2006 21:38:14 -0500
Received: (qmail 35817 invoked by uid 60001); 25 Mar 2006 02:38:14 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=BR6pg9kTyiWBlynwxUHUMbDJSqyjph0MQqJCkpyverx5ADTQ0bTj9S8K2sSTcPyfmplY+z/QWZu/2SKVUKYcIQn6yiSXo2UFZ2MKqbpwiR4ppEFGXMHmLN7KwiCCGSuoFyfm4Bmt6pUDgBpiPFCs1JYnhiVS2lQg6RzltSxGN40=
	; 
Message-ID: <20060325023814.35815.qmail@web51907.mail.yahoo.com>
Received: from [161.114.64.75] by web51907.mail.yahoo.com via HTTP;
	Fri, 24 Mar 2006 18:38:14 PST
Date: Fri, 24 Mar 2006 18:38:14 -0800 (PST)
From: "Mallikarjun C." 
Subject: RE: [Ips] iSCSI- duplicate initiator name
To: ips@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

Between John and Bill, the questions were already
answered.  Just to be very clear, a couple of
comments.

Two leading connections from the same initiator to a
target node (and even to the same TPG) are legal.

If they both quote the same ISID, the target must
perform session reinstatement - i.e. drop the first
session.  It's legal.

If they quote different ISIDs, they must be considered
as two different I_T nexii from the same initiator
node.  Again legal.

Log messages with IP addresses as Bill pointed out
could prove useful.  But note that the diagnosis
really depends on system configuration - e.g. one
initiator node might use the same initiator node name
across multiple IP addresses.

Mallikarjun

--- Inbal Zilbershmidt  wrote:

> Is it possible to have 2 leading connections from
> the same initiator?
> Isn't a session implies an IT nexus?
> As I understood, it is possible to have multiple
> connections in a single
> session.
> My question was regarding to a 2nd leading
> connection from a certain
> initiator name. I caused such situation by giving
> two different
> initiators the same name.
> I wanted to know how should I deal with such case.
>  
> 
> Thanks,
> 
>  
> 
> Inbal ,
> 
> Voltaire Ltd.
> 
> 
> ________________________________
> 
> From: John Hufferd [mailto:jhufferd@Brocade.COM] 
> Sent: Wednesday, March 22, 2006 9:01 AM
> To: Inbal Zilbershmidt; ips@ietf.org
> Subject: RE: [Ips] iSCSI- duplicate initiator name
> 
> 
> 
> The important question is how do you know it is
> another initiator.  If
> it has the same name it could be from any portal on
> the Initiator
> system.  The initiator name applies to the Whole OS.
>  In fact it can
> also apply to a whole cluster that acts as a system
> coupled system.  So
> if it passes the authentication tests, it is assumed
> to be from that OS,
> and multiple Sessions from the same OS is OK.  
> 
>  
> 
> .
> 
> .
> 
> .
> 
> John L Hufferd
> 
> Sr. Executive Director of Technology
> 
> Brocade Communications Systems, Inc
> 
> jhufferd@brocade.com
> 
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
> 
> Alt Office Phone: (408) 997-6136; Cell: (408)
> 627-9606
> 
>  
> 
> ________________________________
> 
> From: Inbal Zilbershmidt
> [mailto:inbalz@voltaire.com] 
> Sent: Tuesday, March 21, 2006 10:54 PM
> To: ips@ietf.org
> Subject: [Ips] iSCSI- duplicate initiator name
> 
>  
> 
> Hello,
> 
>  
> 
> Maybe someone can help me:
> 
>  
> 
> I wanted to know how a target should react in a case
> when an initiator
> trying to connect to it, has the same name as other
> initiator already
> connected.
> 
>  
> 
> Thanks,
> 
>  
> 
> Inbal ,
> 
> Voltaire Ltd.
> 
>  
> 
>  
> 
> > _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Mon Mar 27 10:55:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNu3s-0007iX-DD; Mon, 27 Mar 2006 10:55:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu3q-0007fx-Br
	for ips@ietf.org; Mon, 27 Mar 2006 10:55:18 -0500
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNu3q-0004IK-1J
	for ips@ietf.org; Mon, 27 Mar 2006 10:55:18 -0500
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k2RFtFJS020920
	for ; Mon, 27 Mar 2006 10:55:15 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k2RFssqI006480
	for ; Mon, 27 Mar 2006 10:55:11 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 27 Mar 2006 10:54:53 -0500
Message-ID: 
From: Black_David@emc.com
To: ips@ietf.org
Date: Mon, 27 Mar 2006 10:54:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1,
	Antispam-Data: 2006.03.27.071106
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
	__HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Subject: [Ips] Dallas minutes
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

These are the final minutes - the differences from the 
DRAFT version are primarily better explanations.

Having seen no comment on the mailing list, the items
labeled as "sense of the room" below are now the rough
consensus of the IPS Working Group.

Thanks
--David (IPS WG chair).

IP Storage (ips) WG Meeting Minutes
Monday, March 20, 1300-1500
Dallas, Texas
-----------------------------------

Administrivia, agenda bashing, draft status review, etc. - 15 min
		David L. Black, EMC (chair)
	Blue sheets
	Note Well
	Draft status:
	  - Most drafts are published as RFCs or are in the RFC Editor's
queue
	  - iSNS MIB Last Call is done.  Minor revision needed to deal
			with comments from WG's MIB expert, should submit to
			ADs/IESG in next few months.
	  - Implementers Guide will probably go to WG Last call sometime
			in 2007.  It's ok for this to remain open for a
while.
	Milestones - see charter on web site.

iSCSI Implementer's Guide: Mallikarjun Chadalapaka, HP - 1 hour
	(draft-ietf-ips-iscsi-impl-guide-02.txt)

	Includes proposed revisions/extensions to SCSI task set management

	(1) Response Ordering issue - multiple connections may reorder
		responses from target to initiator.  Often not a problem but
		sometimes SCSI cares (e.g., multi-task abort, ACA).

	-> Proposed solution: Response Fence to tell iSCSI when response
		ordering is necessary.  Assume that it is always needed for
		multi-task management and ACA.  Would be part of SAM
protocol
		service invocation interface to SCSI transport.

	Task management already requires this for multi-task operations,
		proposal is to generalize this in the specification so that
		it can be defined once, used in multiple places, and made
		available to T10 (SCSI standards org) to specify it in other
		places where it is needed.

	Discussion: This may be difficult to get into SAM-x via T10.
		There may be a reluctance to deal with multiple connections
		in a single SCSI session (I_T Nexus).

	Sense of the room: Response Fence will be added to implementers
guide
		as a general mechanism to deal with SCSI situations that
need
		it.  Say that ACA and multi-task management always need it.
		Can be discussed w/T10, but we're not relying on T10 to pick
		this up.

	(2) Task Management - Want to speed-up multi-task abort (ABORT TASK
		SET, and especially CLEAR TASK SET).  Currently have to wait
		for transfers to complete and status acks to come back.

	-> Proposed solution: Provide faster TMF completion by avoiding
		waits for other initiators (can be done without change to
		initiators) and avoiding wait for other tasks on same
initiator
		(requires new key to negotiate latter, as it involves
sending
		per-LUN async events to cause early transfer teardown vs.
		current approach of waiting for transfers to complete).
		Nop-out used to ack async events - will look at combining
acks
		to these events on multiple LUNs for a single target into a
		single Nop-out.

	Sense of the room: Clarifications are good - they will not introduce
		cross-nexus dependencies on the RESET task management
functions.

	Sense of room: New key is useful - put it into draft, allow
responder
		to come back with Yes, No, or Not Understood.  SHOULD vs.
		MAY decision deferred until we have draft text reflecting
this.
		This new key may be related to new T10 data transfer abort
		service in SAM for SAS - Mallikarjun will follow up with Rob
		Elliott (SAS expert).

iSNS MIB: David Black (WG chair) for Scott Kipp, McData - 10 min
	(draft-ietf-ips-isns-mib-08.txt)

	Scope reduced to read-only monitoring of server only.

iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min
	(draft-wysochanski-xkey-iscsi-support-00.txt)

	Asking for a standard key to allow implementation to say what
version
		of software, etc. it is running.  It's easy to get log from
one's
		own product, but harder to get the log from the other side.

	Declarative key (each side declares it once and may not redeclare
it).

	Security - need to say that *if* confidentiality is an issue, *then*
		IPsec SHOULD be used.

	Long discussion of abuse (key used to trigger logic specific to
		implementation at other end - Javascript had serious
problems
		with this for browsers) and need to use wording in the draft
		to discourage such abuse.

	Decision: Draft accepted as WG draft, security and abuse text to be
		worked out, starting on list.  New milestone will be added
to
		charter.

Discovery Extension Discussion - John Hufferd, Brocade - 5 min
	Preference, dealing with multi- environments containing
	things like InfiniBand and 10 Gigabit Ethernet

	Seems like a good thing, particularly for protocol flavor supported
	(iWarp, InfiniBand, etc.).  No decisions made - drafts will be
considered
	if/when they appear.

iSCSI Security Mechanisms: WG Members - time remaining (if any)

	The IETF Security Area has requested that IETF Working Groups plan
	to transition away from usage of MD5.  iSCSI CHAP currently uses
	MD5 in a fashion not directly threatened by the hash collision
	results known for MD5.  It's not clear what to do next - SHA-1
	has been registered for CHAP, SHA-256 has not, and RADIUS servers
	won't support either.  Perhaps something in EAP is appropriate.
	The question that needs to be answered is: What should the next
	iSCSI authentication mechanism be to supersede the current
	CHAP/MD5?

	Note: Post-meeting followup - I took this topic up with the IETF
	Security Area Directors.  Their initial guidance is that the IETF
	Security Area would not look favorably on use of SHA-256 with CHAP,
	and they suggest use of SASL in preference to EAP.  SASL would also
	provide a means of cleaning up some issues around how the Kerberos
	and SPKM mechanisms are currently specified for iSCSI (RFC 3720).

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Mon Mar 27 11:04:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNuCT-0004a3-CG; Mon, 27 Mar 2006 11:04:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuCS-0004Zr-1Z
	for ips@ietf.org; Mon, 27 Mar 2006 11:04:12 -0500
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuCR-0004Yb-7N
	for ips@ietf.org; Mon, 27 Mar 2006 11:04:12 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11])
	by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k2RG47t4007964
	for ; Mon, 27 Mar 2006 11:04:07 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k2RG3xbf000851
	for ; Mon, 27 Mar 2006 11:04:05 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 27 Mar 2006 11:03:56 -0500
Message-ID: 
From: Black_David@emc.com
To: Black_David@emc.com, ips@ietf.org
Date: Mon, 27 Mar 2006 11:03:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1,
	Antispam-Data: 2006.03.27.073104
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0,
	__HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0,
	__STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: 
Subject: [Ips] IPS WG Last Call *completed*: iSNS MIB
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

This is slightly tardy on my part, but the iSNS MIB Last Call
(see below) has been completed successfully.  The authors are
hereby requested to prepare a new version of the MIB to deal
with:

- Keith McCloghrie's comments of March 3rd (minor cleanups)
- The March 20th response to Sajjan Rao's comments (remove
	all mention of clients).

The authors should prepare a new version of the draft - Keith
needs to review it *before* submission, and make sure it passes
the online idnits checker at:

http://tools.ietf.org/tools/idnits/

Once this is done, I will submit the publication request to
put it in the hands of our new area directors.

Thanks,
--David (ips WG chair)

> And you thought this would never happen ... :-)
> 
> This message announces an IP Storage (ips) Working Group
> Last Call on the iSNS MIB draft:
> 
>                Definitions of Managed Objects for iSNS 
>                    (Internet Storage Name Service)
> 
> 			draft-ietf-ips-isns-mib-08.txt
> 
> This WG Last Call will end at 12:00 midnight (end of day) Eastern
> Time on Friday, March 17, 2006.  All technical comments and
> requests for changes need to be posted to this list.  Editorial
> comments and corrections may be sent directly to the draft
> editor, Scott Kipp  and cc:'d to me
> (David Black ) as WG chair. 
> 
> If serious technical issues arise, they will be discussed during
> the IPS WG's meeting in Dallas.
> 
> Thanks,
> --David (IPS WG Chair)
> ----------------------------------------------------
> 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
> ----------------------------------------------------

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Mon Mar 27 11:46:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNurc-0001O2-2q; Mon, 27 Mar 2006 11:46:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FNurb-0001Nx-04
	for ips@ietf.org; Mon, 27 Mar 2006 11:46:43 -0500
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNura-0006SE-Of
	for ips@ietf.org; Mon, 27 Mar 2006 11:46:42 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k2RGkgJS021262
	for ; Mon, 27 Mar 2006 11:46:42 -0500 (EST)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k2RGkdEs000547
	for ; Mon, 27 Mar 2006 11:46:40 -0500 (EST)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 27 Mar 2006 11:46:36 -0500
Message-ID: 
From: Black_David@emc.com
To: ips@ietf.org
Date: Mon, 27 Mar 2006 11:46:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1,
	Antispam-Data: 2006.03.27.081106
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Subject: [Ips] X#NodeArchitecture draft - next steps
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

This draft is better known as: draft-wysochanski-xkey-iscsi-support-00.txt

This draft will be an official WG draft, but three things
need to happen first:

(1) New security text.  The existing "SHOULD" in the security
	considerations text needs to be a "MUST".  In addition,
	there needs to be a sentence pointing out that it may
	be important to shield the contents of this key from
	observers of network traffic, and that IPsec as specified
	for iSCSI in RFC 3720 and 3723 (cite both of them) is an
	appropriate tool for this purpose.

(2) New "prevention of abuse" text.  The current "The key MUST NOT
	be used by iSCSI nodes for things such as ..." is well-
	intentioned but does not get the job done.  My recollection
	of discussion in Dallas is that saying that "functional behavior
	of the iSCSI node MUST NOT depend on this key (presence/absence
	or value)"  may be closer to the mark.  The only permitted
	(and intended) use of this key is to report it/log it in order
	to avoid the browser detection JavaScript disasters caused by
	the corresponding HTTP header fields.

(3) The draft needs a new title and file name ("supportability" just
	reeks of marketing ;-) ).  Let's try:

	   The iSCSI X#NodeArchitecture Key
	draft-ietf-ips-iscsi-nodearch-key-00.txt

Text for (1) and (2), or at least initial versions of it should be
worked out on the list before the -00 version of the draft-ietf-ips-...
draft is submitted.  I've just sent the request to the secretariat for
an end-of-2006 completion milestone for this, but in practice, it
could be done shortly after Montreal, if not before.

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
----------------------------------------------------

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

From ips-bounces@ietf.org Mon Mar 27 21:14:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO3ih-0000ni-VT; Mon, 27 Mar 2006 21:14:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3ih-0000nd-Fe
	for ips@ietf.org; Mon, 27 Mar 2006 21:14:07 -0500
Received: from sccrmhc13.comcast.net ([204.127.200.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO3ig-0000li-9D
	for ips@ietf.org; Mon, 27 Mar 2006 21:14:07 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (sccrmhc13) with SMTP
	id <2006032802140501300e95tne>; Tue, 28 Mar 2006 02:14:05 +0000
Message-ID: <000f01c6520d$49da3ed0$08031eac@ivivity.com>
From: "Eddy Quicksall" 
To: 
Date: Mon, 27 Mar 2006 21:14:04 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Subject: [Ips] One DataAckSNACK for two "A"s
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0406094809=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0406094809==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C651E3.6085DF10"

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C651E3.6085DF10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Suppose the target sends two sequences with the A bit set (both for the =
same task and both are within the length constraints that apply to the =
use of the A bit). Also assume DataSequenceInOrder is Yes.

Can the initiator send just one DataAckSNACK after the 2nd sequence with =
the appropriate BegRun for the 2nd sequence?

Eddy
------=_NextPart_000_000C_01C651E3.6085DF10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Suppose the target sends two sequences with the =

A bit set (both for the same task and both are within the length=20
constraints that apply to the use of the A bit). Also assume =
DataSequenceInOrder=20
is Yes.

Can the initiator send just one =
DataAckSNACK after the=20
2nd sequence with the appropriate BegRun for the 2nd=20
sequence?

Eddy

------=_NextPart_000_000C_01C651E3.6085DF10--

--===============0406094809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0406094809==--

From ips-bounces@ietf.org Mon Mar 27 23:02:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO5P8-00057J-4u; Mon, 27 Mar 2006 23:02:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5P7-00057E-0c
	for ips@ietf.org; Mon, 27 Mar 2006 23:02:01 -0500
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5P5-0004EQ-Mb
	for ips@ietf.org; Mon, 27 Mar 2006 23:02:00 -0500
Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91])
	by mononoke.wasabisystems.com (Postfix) with ESMTP
	id 5ECF487150; Mon, 27 Mar 2006 23:01:58 -0500 (EST)
In-Reply-To: <000f01c6520d$49da3ed0$08031eac@ivivity.com>
References: <000f01c6520d$49da3ed0$08031eac@ivivity.com>
Mime-Version: 1.0 (Apple Message framework v749.3)
X-Priority: 3
Message-Id: <8F1DCC31-5981-4988-AB93-C05C87F5286F@wasabisystems.com>
From: William Studenmund 
Subject: Re: [Ips] One DataAckSNACK for two "A"s
Date: Mon, 27 Mar 2006 20:01:51 -0800
To: Eddy Quicksall 
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.749.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1581082297=="
Errors-To: ips-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1581082297==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-4--144929187"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-4--144929187
Content-Type: multipart/alternative; boundary=Apple-Mail-3--144929259

--Apple-Mail-3--144929259
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:

> Suppose the target sends two sequences with the A bit set (both for  
> the same task and both are within the length constraints that apply  
> to the use of the A bit). Also assume DataSequenceInOrder is Yes.
>
> Can the initiator send just one DataAckSNACK after the 2nd sequence  
> with the appropriate BegRun for the 2nd sequence?

What is the initiator trying to do? From reading the RFC, the  
initiator can in fact do this. However this would imply that there  
was an issue with the first sequence and that it is being re-requested.

I think it would also be reasonable to have one DataAckSNACK that  
covered both runs, but in that case you'd start with the BegRun from  
the 1st sequence.

Take care,

Bill
--Apple-Mail-3--144929259
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

On Mar 27, 2006, at =
6:14 PM, Eddy Quicksall wrote:

 =
Suppose the target sends two=A0sequences with the =
A=A0bit set (both for the same task and both are within the length =
constraints that apply to the use of the A bit). Also assume =
DataSequenceInOrder is Yes.
 =A0
 Can the initiator send =
just one DataAckSNACK=A0after the 2nd sequence=A0with=A0the appropriate =
BegRun for the 2nd =
sequence?

What is the initiator =
trying to do? =46rom reading the RFC, the initiator can in fact do this. =
However this would imply that there was an issue with the first sequence =
and that it is being re-requested.

I think it would also be =
reasonable to have one DataAckSNACK that covered both runs, but in that =
case you'd start with the BegRun from the 1st sequence.

Take care,

Bill=

--Apple-Mail-3--144929259--

--Apple-Mail-4--144929187
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEKLU1DJT2Egh26K0RAiWgAJ4qrUTCu5+p9KT2zXOT5T8dr9SpygCfRCyu
1BImM8HmiSbm85lITTSOqW8=
=njHn
-----END PGP SIGNATURE-----

--Apple-Mail-4--144929187--

--===============1581082297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1581082297==--

From ips-bounces@ietf.org Tue Mar 28 09:32:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOFFa-00064M-U7; Tue, 28 Mar 2006 09:32:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFFZ-00062V-Ge
	for ips@ietf.org; Tue, 28 Mar 2006 09:32:49 -0500
Received: from sccrmhc14.comcast.net ([204.127.200.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFFZ-0005hD-60
	for ips@ietf.org; Tue, 28 Mar 2006 09:32:49 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (sccrmhc14) with SMTP
	id <2006032814324801400c37c0e>; Tue, 28 Mar 2006 14:32:48 +0000
Message-ID: <002601c65274$7c89afc0$08031eac@ivivity.com>
From: "Eddy Quicksall" 
To: "William Studenmund" 
References: <000f01c6520d$49da3ed0$08031eac@ivivity.com>
	<8F1DCC31-5981-4988-AB93-C05C87F5286F@wasabisystems.com>
Subject: Re: [Ips] One DataAckSNACK for two "A"s
Date: Tue, 28 Mar 2006 09:32:47 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0484478385=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0484478385==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C6524A.932E2410"

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C6524A.932E2410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In my example there is no problem with the first sequence. The example =
is created by the initiator being "smart" if it is a little slow and =
receives both sequences very close together hence deciding that it only =
needs to send the DataAckSNACK for the 2nd in order to cover both. The =
target should be able to figure out that both sequences have been =
received by the initiator by checking BegRun.

The BegRun for a DataAckSNACK is the next expected DataSN so it would be =
set for the 2nd sequence which covers both sequences.

Eddy
  ----- Original Message -----=20
  From: William Studenmund=20
  To: Eddy Quicksall=20
  Cc: ips@ietf.org=20
  Sent: Monday, March 27, 2006 11:01 PM
  Subject: Re: [Ips] One DataAckSNACK for two "A"s

  On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:

    Suppose the target sends two sequences with the A bit set (both for =
the same task and both are within the length constraints that apply to =
the use of the A bit). Also assume DataSequenceInOrder is Yes.

    Can the initiator send just one DataAckSNACK after the 2nd sequence =
with the appropriate BegRun for the 2nd sequence?

  What is the initiator trying to do? From reading the RFC, the =
initiator can in fact do this. However this would imply that there was =
an issue with the first sequence and that it is being re-requested.

  I think it would also be reasonable to have one DataAckSNACK that =
covered both runs, but in that case you'd start with the BegRun from the =
1st sequence.

  Take care,

  Bill

-------------------------------------------------------------------------=
-----

  _______________________________________________
  Ips mailing list
  Ips@ietf.org
  https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0023_01C6524A.932E2410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In my example there is no problem with the first =
sequence. The=20
example is created by the initiator being "smart" if it is a little slow =
and=20
receives both sequences very close together hence deciding that it only =
needs to=20
send the DataAckSNACK for the 2nd in order to cover both. The target =
should be=20
able to figure out that both sequences have been received by the =
initiator=20
by checking BegRun.

The BegRun for a DataAckSNACK is the next expected =
DataSN so=20
it would be set for the 2nd sequence which covers both =
sequences.

Eddy

  ----- Original Message ----- 
  From:=20
  William Studenmund =

  To: Eddy =
Quicksall=20

  Cc: ips@ietf.org 
  Sent: Monday, March 27, 2006 =
11:01=20
  PM
  Subject: Re: [Ips] One =
DataAckSNACK for=20
  two "A"s

  On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:

    Suppose the target sends two sequences with =
the=20
    A bit set (both for the same task and both are within the =
length=20
    constraints that apply to the use of the A bit). Also assume=20
    DataSequenceInOrder is Yes.

    Can the initiator send just one =
DataAckSNACK after=20
    the 2nd sequence with the appropriate BegRun for the 2nd=20
    sequence?

  What is the initiator trying to do? From reading the RFC, the =
initiator=20
  can in fact do this. However this would imply that there was an issue =
with the=20
  first sequence and that it is being re-requested.

  I think it would also be reasonable to have one DataAckSNACK that =
covered=20
  both runs, but in that case you'd start with the BegRun from the 1st=20
  sequence.

  Take care,

  Bill

_______________________________________________
Ips mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0023_01C6524A.932E2410--

--===============0484478385==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0484478385==--

From ips-bounces@ietf.org Tue Mar 28 12:49:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOIJj-0000jq-BL; Tue, 28 Mar 2006 12:49:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIJi-0000jl-Kk
	for ips@ietf.org; Tue, 28 Mar 2006 12:49:18 -0500
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIJh-0005eM-Ug
	for ips@ietf.org; Tue, 28 Mar 2006 12:49:18 -0500
Received: from d12nrmr1507.megacenter.de.ibm.com
	(d12nrmr1507.megacenter.de.ibm.com [9.149.167.1])
	by mtagate3.de.ibm.com (8.13.6/8.13.6) with ESMTP id k2SHnH3E173482
	for ; Tue, 28 Mar 2006 17:49:17 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2SHntYC117370 for ; Tue, 28 Mar 2006 19:49:55 +0200
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k2SHnGZ7013969 for ; Tue, 28 Mar 2006 19:49:16 +0200
Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com
	[9.149.167.114])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k2SHnGZq013966; Tue, 28 Mar 2006 19:49:16 +0200
In-Reply-To: <002601c65274$7c89afc0$08031eac@ivivity.com>
To: "Eddy Quicksall" 
Subject: Re: [Ips] One DataAckSNACK for two "A"s
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
From: Julian Satran 
Message-ID: 
Date: Tue, 28 Mar 2006 19:49:48 +0200
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 |
	November 16, 2005) at 28/03/2006 19:49:55,
	Serialize complete at 28/03/2006 19:49:55
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Cc: ips@ietf.org, William Studenmund 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0705150974=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0705150974==
Content-Type: multipart/alternative;
	boundary="=_alternative 0061D37D4225713F_="

This is a multipart message in MIME format.
--=_alternative 0061D37D4225713F_=
Content-Type: text/plain; charset="US-ASCII"

Eddy,

You are correct. The DataAck for the second implicitly covers first. If 
this is not clear we amy want yo have it covered in the implementation 
guide.

Regards,
Julo

"Eddy Quicksall"  
28/03/06 16:32

To
"William Studenmund" 
cc
ips@ietf.org
Subject
Re: [Ips] One DataAckSNACK for two "A"s

In my example there is no problem with the first sequence. The example is 
created by the initiator being "smart" if it is a little slow and receives 
both sequences very close together hence deciding that it only needs to 
send the DataAckSNACK for the 2nd in order to cover both. The target 
should be able to figure out that both sequences have been received by the 
initiator by checking BegRun.

The BegRun for a DataAckSNACK is the next expected DataSN so it would be 
set for the 2nd sequence which covers both sequences.

Eddy
----- Original Message ----- 
From: William Studenmund 
To: Eddy Quicksall 
Cc: ips@ietf.org 
Sent: Monday, March 27, 2006 11:01 PM
Subject: Re: [Ips] One DataAckSNACK for two "A"s

On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:

Suppose the target sends two sequences with the A bit set (both for the 
same task and both are within the length constraints that apply to the use 
of the A bit). Also assume DataSequenceInOrder is Yes.

Can the initiator send just one DataAckSNACK after the 2nd sequence with 
the appropriate BegRun for the 2nd sequence?

What is the initiator trying to do? From reading the RFC, the initiator 
can in fact do this. However this would imply that there was an issue with 
the first sequence and that it is being re-requested.

I think it would also be reasonable to have one DataAckSNACK that covered 
both runs, but in that case you'd start with the BegRun from the 1st 
sequence.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0061D37D4225713F_=
Content-Type: text/html; charset="US-ASCII"

Eddy,

You are correct. The DataAck for the
second implicitly covers first. If this is not clear we amy want yo have
it covered in the implementation guide.

Regards,

Julo

"Eddy Quicksall"
<eddy_quicksall_iVivity_iSCSI@Comcast.net> 
28/03/06 16:32

To
"William Studenmund" <wrstuden@wasabisystems.com>

cc
ips@ietf.org

Subject
Re: [Ips] One DataAckSNACK for two "A"s

In my example there is no problem with the first sequence.
The example is created by the initiator being "smart" if it is
a little slow and receives both sequences very close together hence deciding
that it only needs to send the DataAckSNACK for the 2nd in order to cover
both. The target should be able to figure out that both sequences have
been received by the initiator by checking BegRun.

The BegRun for a DataAckSNACK is the next expected DataSN
so it would be set for the 2nd sequence which covers both sequences.

Eddy

----- Original Message ----- 

From: William
Studenmund 

To: Eddy
Quicksall 

Cc: ips@ietf.org

Sent: Monday, March 27, 2006 11:01 PM

Subject: Re: [Ips] One DataAckSNACK for two "A"s

On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:

Suppose the target sends two sequences with the A bit
set (both for the same task and both are within the length constraints
that apply to the use of the A bit). Also assume DataSequenceInOrder is
Yes.

Can the initiator send just one DataAckSNACK after the
2nd sequence with the appropriate BegRun for the 2nd sequence?

What is the initiator trying to do? From reading the RFC,
the initiator can in fact do this. However this would imply that there
was an issue with the first sequence and that it is being re-requested.

I think it would also be reasonable to have one DataAckSNACK
that covered both runs, but in that case you'd start with the BegRun from
the 1st sequence.

Take care,

Bill

_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0061D37D4225713F_=--

--===============0705150974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0705150974==--

From ips-bounces@ietf.org Tue Mar 28 16:52:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOM6e-0004vg-1C; Tue, 28 Mar 2006 16:52:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOM6c-0004uN-OX
	for ips@ietf.org; Tue, 28 Mar 2006 16:52:02 -0500
Received: from rwcrmhc14.comcast.net ([216.148.227.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOM6b-0000NF-GC
	for ips@ietf.org; Tue, 28 Mar 2006 16:52:02 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (rwcrmhc14) with SMTP
	id <20060328215200m1400slvkne>; Tue, 28 Mar 2006 21:52:00 +0000
Message-ID: <001f01c652b1$d70cff00$08031eac@ivivity.com>
From: "Eddy Quicksall" 
To: 
Date: Tue, 28 Mar 2006 16:51:58 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [Ips] typo in iSER
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1742614947=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1742614947==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001C_01C65287.ED7A84D0"

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C65287.ED7A84D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In the discussion of 7.3.5 the spec uses the term "Read Message" but =
shouldn't that be "Read Request Message" since RDMA does not have a =
"Read Message"?

Eddy
------=_NextPart_000_001C_01C65287.ED7A84D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In the discussion of 7.3.5 the spec uses the term =
"Read=20
Message" but shouldn't that be "Read Request Message" since RDMA does =
not have a=20
"Read Message"?

Eddy

------=_NextPart_000_001C_01C65287.ED7A84D0--

--===============1742614947==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1742614947==--

From ips-bounces@ietf.org Wed Mar 29 12:12:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOeD9-0003UC-1o; Wed, 29 Mar 2006 12:11:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOeD6-0003Tp-Ql
	for ips@ietf.org; Wed, 29 Mar 2006 12:11:56 -0500
Received: from e5.ny.us.ibm.com ([32.97.182.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOeD5-0006z4-Hr
	for ips@ietf.org; Wed, 29 Mar 2006 12:11:56 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e5.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	k2THBkXc029621 for ; Wed, 29 Mar 2006 12:11:46 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k2THBaYX247588 for ; Wed, 29 Mar 2006 12:11:36 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2THBatS019765
	for ; Wed, 29 Mar 2006 12:11:36 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2THBa6I019759; 
	Wed, 29 Mar 2006 12:11:36 -0500
In-Reply-To: <001f01c652b1$d70cff00$08031eac@ivivity.com>
Importance: Normal
MIME-Version: 1.0
Sensitivity: 
To: "Eddy Quicksall" 
Subject: Re: [Ips] typo in iSER
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: 
From: Mike Ko 
Date: Wed, 29 Mar 2006 09:11:35 -0800
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 |
	February 28, 2006) at 03/29/2006 12:11:35,
	Serialize complete at 03/29/2006 12:11:35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0501940235=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0501940235==
Content-Type: multipart/alternative;
	boundary="=_alternative 005E727388257140_="

This is a multipart message in MIME format.
--=_alternative 005E727388257140_=
Content-Type: text/plain; charset="US-ASCII"

Sure looks that way.

Mike
To:     
cc:      
Subject:        [Ips] typo in iSER

In the discussion of 7.3.5 the spec uses the term "Read Message" but 
shouldn't that be "Read Request Message" since RDMA does not have a "Read 
Message"?

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 005E727388257140_=
Content-Type: text/html; charset="US-ASCII"

Sure looks that way.

Mike
To:      
 <ips@ietf.org>

cc:      

Subject:    
   [Ips] typo in
iSER

In the discussion of 7.3.5 the spec uses the term "Read
Message" but shouldn't that be "Read Request Message" since
RDMA does not have a "Read Message"?

Eddy_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 005E727388257140_=--

--===============0501940235==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0501940235==--

From ips-bounces@ietf.org Fri Mar 31 21:35:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPVxF-0006yQ-Q6; Fri, 31 Mar 2006 21:35:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVxD-0006yK-Pu
	for ips@ietf.org; Fri, 31 Mar 2006 21:35:07 -0500
Received: from mx2.netapp.com ([216.240.18.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPVxD-0005Vs-Bo
	for ips@ietf.org; Fri, 31 Mar 2006 21:35:07 -0500
Received: from smtp2.corp.netapp.com ([10.57.159.114])
	by mx2.netapp.com with ESMTP; 31 Mar 2006 18:35:07 -0800
X-IronPort-AV: i="4.03,152,1141632000"; 
	d="scan'208"; a="371387195:sNHT29834540"
Received: from [10.30.24.82] ([10.30.24.82])
	by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id
	k312Z4Bt004056; Fri, 31 Mar 2006 18:35:05 -0800 (PST)
Message-ID: <442DE6D1.7060801@netapp.com>
Date: Fri, 31 Mar 2006 21:34:57 -0500
From: Dave Wysochanski 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Black_David@emc.com
Subject: Re: [Ips] X#NodeArchitecture draft - next steps
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: ips-bounces@ietf.org

Black_David@emc.com wrote:

> This draft is better known as: 
> draft-wysochanski-xkey-iscsi-support-00.txt
>
> This draft will be an official WG draft, but three things
> need to happen first:
>
> (1) New security text.  The existing "SHOULD" in the security
>         considerations text needs to be a "MUST".  In addition,
>         there needs to be a sentence pointing out that it may
>         be important to shield the contents of this key from
>         observers of network traffic, and that IPsec as specified
>         for iSCSI in RFC 3720 and 3723 (cite both of them) is an
>         appropriate tool for this purpose.
>
New proposed text:

3.  Security Considerations 

   In certain environments where security is a primary concern,
   the use of this extension key may not be appropriate as it
   reveals specific details about an iSCSI node.  For these
   environments, nodes implementing this public extension key
   MUST provide a method to disable sending the key.  In
   addition to providing a disable mechanism, security sensitive
   environments SHOULD consider use of IPsec, as specified in 
   RFC 3720 and 3723, as a means to shield the contents of this
   key from observers of network traffic.

Original text:      

3.  Security Considerations 

   In certain environments where security is a primary concern,
   the use of this extension key may not be appropriate as it
   reveals specific details about an iSCSI node. For these
   environments, nodes implementing this public extension key
   SHOULD provide a method to disable sending the key.

> (2) New "prevention of abuse" text.  The current "The key MUST NOT
>         be used by iSCSI nodes for things such as ..." is well-
>         intentioned but does not get the job done.  My recollection
>         of discussion in Dallas is that saying that "functional behavior
>         of the iSCSI node MUST NOT depend on this key (presence/absence
>         or value)"  may be closer to the mark.  The only permitted
>         (and intended) use of this key is to report it/log it in order
>         to avoid the browser detection JavaScript disasters caused by
>         the corresponding HTTP header fields.
>

I wasn't sure about deleting the original "MUST NOT" sentence so I left 
it in.  Anyone
have a preference?  Also wasn't sure whether it's worth putting in a 
sentence or two at
least acknowledging what has happened in the past with User-Agent -- 
intent would be
the working group acknowledges this historical misuse and wishes to 
avoid it.

New proposed text:

   The following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the proper use of this key is to provide enhanced
   logging and support capabilities, and for better understanding
   of customer environments.  Functional behavior of the iSCSI
   node MUST NOT depend on the presence, absence, or content of
   the key.  The key MUST NOT be used by iSCSI nodes for things
   such as interoperability, performance, exclusion or deception
   of other nodes, or other uses not defined here.  To enforce
   proper use, iSCSI nodes MUST NOT allow user modification of
   the key value(s), and SHOULD set the value automatically based
   on standard internal interfaces.

Original text:

   The following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the proper use of this key is to provide enhanced
   logging and support capabilities, and for better understanding
   of customer environments.  The key MUST NOT be used by iSCSI
   nodes for things such as interoperability, performance,
   exclusion or deception of other nodes, or other uses not
   defined here.  To enforce proper use, iSCSI nodes MUST NOT
   allow user modification of the key value(s), and SHOULD set
   the value automatically based on standard internal interfaces.

> (3) The draft needs a new title and file name ("supportability" just
>         reeks of marketing ;-) ).  Let's try:
>
>            The iSCSI X#NodeArchitecture Key
>         draft-ietf-ips-iscsi-nodearch-key-00.txt
>
Sounds fine to me.

> Text for (1) and (2), or at least initial versions of it should be
> worked out on the list before the -00 version of the draft-ietf-ips-...
> draft is submitted.  I've just sent the request to the secretariat for
> an end-of-2006 completion milestone for this, but in practice, it
> could be done shortly after Montreal, if not before.
>
Great, thanks.

> 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
> ----------------------------------------------------
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips