Re: iSCSI: AHS drop bit

["Mallikarjun C." <cbm@rose.hp.com>]

Update on this...


After an offline conversation with Julian, he agreed that the
AHS drop bit can be removed.  It will be removed in rev10.

The room for current "Non-iSCSI extensions" would however be 
retained as "Vendor specific extensions".

Thanks.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


"Mallikarjun C." wrote:
> 
> Julian,
> 
> > We don't have any use for it but some "vendor specific" extensions may.
> 
> That then begs the question - should/can we anticipate vendor-specific needs
> and provide for them in the spec?
> 
> My preference is to do away with AHS drop bit - since it doesn't seem
> useful to either iSCSI or SCSI.
> 
> Regards.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> 
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Saturday, January 05, 2002 6:10 AM
> Subject: Re: iSCSI: AHS drop bit
> 
> > Mallikarjun,
> >
> > The bit was really meant to enable dropping the additional header and not
> > the whole request if ignored but rejecting the whole request.
> > We don't have any use for it but some "vendor specific" extensions may.
> >
> > I suggest we change the wording of non-ISCSI non-iSCSI/vendor specific
> >
> > Julo
> >
> >
> >
> >                     "Mallikarjun
> >                     C."                  To:     ips <ips@ece.cmu.edu>
> >                     <cbm@rose.hp.c       cc:
> >                     om>                  Subject:     iSCSI: AHS drop bit
> >                     Sent by:
> >                     owner-ips@ece.
> >                     cmu.edu
> >
> >
> >                     14-12-01 22:48
> >                     Please respond
> >                     to cbm
> >
> >
> >
> >
> >
> > Julian,
> >
> > Section 3.2.2.1 says the following on the AHS drop bit -
> >            bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not
> >            understood; if set to 0 this AHS must be rejected if not
> >            understood.
> >
> > - I suspect it is the entire command that was meant to be failed, not
> >   just the AHS...
> >
> > - If it is a SCSI operation that is being failed, I suggest that
> >   the target should end the command with an appropriate SCSI CHECK
> >   CONDITION - so the command sequence window can advance at the
> >   transport level (and the inability of the target to support say
> >   extended CDB is known end-to-end, to prevent fruitless SCSI retries).
> >
> > - This bit may be useful for AHS code "Non-iSCSI extensions", but
> >   I could not see how it can be used for the defined iSCSI operations.
> >   If it is indeed so, I would actually suggest dropping this feature.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668         Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> >
> >
> >