RE: iSCSI:Async Message PDU

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

>Julian will doubtless pick up the rest of these,
>but I thought I'd take this issue, since it was
>part of what we did in Orlando.
>
>> 4. Somehow, "Asynchronous Message" seems at odds with the rest of the
>> usage in the draft in regards to PDUs (since a message is introduced as
>> PDU in section 1.2).  Should we may be just call it an AEN PDU?  Section
>> 2.14.3 calls this so.  (I realize that it may not always result in a 
>> SCSI-level AER.)
>
>One of the things we did in Orlando was to change
>some of the terminology with the goal of each term and
>acronym being unambiguously owned by a single layer
>in the protocol stack, in particular making a sharp
>distinction between SCSI concepts and iSCSI mechanisms.
>
>All the *RN entities changed to *SN for this reason
>(SCSI has a CmdRN, so all *RN entities are SCSI, and
>all *SN entities are iSCSI).  Similarly, all AE*
>entities are SCSI, and we went with "Asynchronous
>Message <*>" to name the iSCSI entities.  This matters
>here because there are circumstances in which iSCSI
>will send Asynchronous Message PDUs for its own use
>even when SCSI has disabled AER.  The usage of "AEN
>PDU" in 2.14.3 is probably an editing oversight.
>Suggestions for words to use instead of "Message"
>are welcome, but they must not start with the letter
>"E" ;-).

I see what you're saying.  My point was that "Asynchronous
Message PDU" is redundant.  Should we just call it 
"Async PDU"/ "Async Indication PDU"?

BTW, doesn't a similar rule apply for SACK?  

Thanks.

>
>Thanks,
>--David
>


--
Mallikarjun 


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