RE: Async Message PDU

[Black_David@emc.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" ;-).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------