Access Control points of debate

George Ericson gericson at mindspring.com
Mon Dec 6 20:10:02 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "George Ericson" <gericson at mindspring.com>
*
Bob,

Any LU granular scheme must also consider the affects of Target Reset and
related queue mgmt functions.

George

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Bob
Snively
Sent: Tuesday, November 30, 1999 11:27 PM
To: t10 at t10.org; hafner at almaden.ibm.com
Subject: Re: Access Control points of debate


* From the T10 Reflector (t10 at t10.org), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
*
Folks,

I firmly believe that rev 2's approach, where access controls exist
symmetrically on a LUN by LUN basis are the key to a functional access
control structure.  Enforcement of access controls by the individual LUN
is really the only sensible structure in a complex FC fabric, and is
probably
the only cost-effective efficient mechanism for providing "LUN masking".

It is true that devices with lots of LUNs and supporting lots of
initiators will have more resource demands placed upon them.  However, this
is hardly frightening when you consider that such devices usually have
100s of Megabytes, if not Gigabytes, of cache buffering, as well as
powerful RAID SACL engines.  I think that the proper alternative has
already been selected.

Bob

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

 (stuff deleted)

>2) One major change from rev1 to rev2 involved moving "access
>controls management/enforcement server" functions from LUN0
>to each logical unit independently (as that seemed to fit the SAM-2
>model much better).  This implies that there will be a Manage ACL Key
>per logical unit.  It also means that ENROLLMENT is on a per logical
>unit basis (and this implies that an initiator can use a different AccessID
>per logical unit -- it's not how I'd implement it, but the standard can't
>require it).  This change forces more resource requirements on the
>target (and I'm getting requests to go back to the original model).
>I personally perfer this "shared" model but I don't see how the SAM-2
>model can easily adapt to this (I like to be wrong on this point).
>Alternatives to rev2:
>   a) allow shared behavior if the device reports the presence of an
>embedded controller in inquiry.
>   b) allow (somehow) implicit enrollment at other logical units if
>there is an explicit enrollment at another (shared enrollment).  This
>has some interesting consequences, however.
>   c) find some language which requires that an initiator use the same
>AccessID on all logical units of a given target (is there such language?)
>   d) change the SAM-2 model to allow for an "access control server"
>which spans logical units (IMHO, this is too much to bite off,...)

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

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




More information about the T10 mailing list