Re: iSCSI MIB - comments on iscsiAccessList

["Mark A. Carlson" <mark.carlson@sun.com>]

Mark Bakke wrote:
> 
> Keith McCloghrie wrote:
> >
...
> > >    This table does not cover all possible access control schemes that a
> > >    vendor could implement.  If access to an initiator cannot be
> > >    determined just by its iSCSI name, an implementation may either
> > >    include a single entry per target with the initiator name "iscsi", or
> > >    may choose to place no entries in this table.
> >
> > Does no entries in the table allow any initiator access, or does it
> > deny access to all initiators ?
> 
> I think that we need to decide that here.  It was originally intended
> to mean that all initiators are allowed, but since we have a way to
> say that by putting in "iscsi", I think that it should mean either that
> all initiators are denied, or that the access list mechanism in the
> MIB is not enough to determine whether or not an initiator will
> be granted access.  I would tend toward the latter; if there are no
> access list entries for a target, it means that there is not enough
> information to tell who gets to access it from this MIB.  Implementations
> that provide value-add access control can augment this MIB with their
> own enterprise MIBs for access control.
> 
> I would like to re-word this to:
> 
>    ... The value "iscsi" in an access list entry means that any
>    initiator may access this target.  If a target has no entries
>    in the access list attributes table, it means that there is
>    not enough information here to determine whether or not an
>    initiator will be granted access.

But isn't the fact that the iSCSI name is used, as part of what access
control is based on, useful to applications? For example, if I use a
combination of iSCSI name and host userid to determine access, I would
still like to know that *some* access is available from this initiator
so that I can relate this logical relationship (maybe draw a graph).

How about a field that indicates "additional information required" rather
than leaving the whole entry blank? (empty really should mean no access,
rather than no standard access, and we need to differentiate these two).

Even if a vendor extends iscsiAccessList for their own access control, at 
least the standard properties could be supported so that applications
can see that access is allowed from somewhere.

Having iscsiALInitiatorName = iscsi, and "additional information" = true,
would indicate that the proprietary access control mechanism needs to be 
consulted to understand who has access, but at least there is some access
allowed.

-- mark