Access Controls: PAM inventory requirements

[hafner at almaden.ibm.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* hafner at almaden.ibm.com
*


Greetings,

I'd appreciate comments from this group on the following issue; in
particular, does anybody think I got this wrong.

One of the functions we briefly discussed at the last SCSI CAP meeting
in the context of access controls is the issue of PAM (the managing
application for access controls) getting enough information about
logical units to make decisions about setting access rights.

For example, PAM needs READ CAPACITY data for disks (or disk-like
devices) in order to know how to allocate storage to initiators.   But
she (PAM) can't necessarily issue the READ CAPACITY command
to each logical unit unless she has granted herself access to that
logical unit (and this is not really required).

The current proposal (rev 6 and rev 7 under construction) has a
REPORT LU DESCRIPTORS service action which PAM can use to collect
this sort of information.   Rev 7's current page structure for the
parameter
data contains:
    Peripheral Device Type
    Additional Length
    Default LUN (what the LUN would be in the absense of access controls)
    One Identifier Descriptor from INQUIRY EVPD page 83 (if supported)
    Device Identifier (from SET/READ DEVICE IDENTIFIER) (if supported)
    Device Type Specific Additional Data

The question is, what goes in the Device-Type Specific Data.  I've scanned
most of the draft standards for each of the peripheral device types and
this is
my current recommendation. The "Command" header is the existing command
whose parameter data needs to be returned in this additional data field.

Standard PDT   Type           Command
SBC      00    Disk           READ CAPACITY
SBC      04    WriteOnce      None (see note 1)
SBC      07    Optical        None (see note 1)
SSC      01    Tape           None (see note 1)
SSC      02    Printer        None
SPC-2    03    Processor      None
MMC-2/3  05    C/DVD          None (see note 2)
SMC      08    MediumChanger  None (see note 3)
SCC-2    0C    Controller     None (see note 4)
SES      0D    Encl. Services None
RBC      0E    ReducedDisk    READ CAPACITY
SCSI-2   06    Scanner        None
SCSI-2   09    Communications None
OCRW     0F    (didn't find this draft)

Note 1: I might be convinced that PAM needs to know the
REPORT DENSITY SUPPORT (MEDIA=0)data, but one
can argue that PAM will grant some (set of) initiators access
to this device and only they really need to know this information.

Note 2: Since this is typically removable media, stuff
like READ CAPACITY and READ FORMAT CAPACITIES
would only be informative for the initiators using the device
and not for PAM for allocation of the device as a resource.

Note 3: One might argue that a list of elements is useful
here, so that PAM can determine basic capabilities of
each of the Medium Changers she's dealing with.  I'm open
to this alternative, but don't think it is required as yet.  For example,
she might get a good strong hint on this data just from the
vendor and model number (and out-of-band data) from
INQUIRY.

Note 4: One might argue that the REPORT UNCONFIGURED
CAPACITY might be useful, or other MAINTENANCE IN stuff,
but in my view, PAM only needs to know that this is a controller,
She hands the access rights to an initiator who should be
reponsible and has the code to configure that controller, and
only then does she get in the act by setting access rights to the
configured logical disks (so PDT=00) kicks in.    In other words,
she's not the one allocating the unconfigured capacity, it's the
owner of the controller.  AFTER its configured, then she can step in
to allocate the configured resources to initiators who should
USE the space.


Jim Hafner


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org