Re: iSCSI MIB - comments on iscsiAccessList

[Keith McCloghrie <kzm@cisco.com>]

> > > 6.9.  iscsiAccessList
> > >
> > >    The iscsiAccessListAttributesTable contains an entry for each
> > >    initiator that is allowed to access the target under which it
> > >    appears.  If a target allows access to any initiator, an
> > >    AccessListAttributesEntry with the initiator's iSCSI name should be
> > >    used.
> > 
> > I think the last sentence is
> > 
> > a) confusing (do you mean "any initiator" ?) and
> 
> No.  I meant "any particular initiator"; this was badly worded.

How about also changing "with the initiator's iSCSI name" to
"with that initiator's iSCSI name".

> > >    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.

OK.

> > > iscsiALInitiatorName OBJECT-TYPE
> > >     SYNTAX        SnmpAdminString
> > >     MAX-ACCESS    read-only
> > >     STATUS        current
> > >     DESCRIPTION
> > >         "An octet string that defines an initiator identified
> > >      by the <InitiatorName> key of the Login Command which will
> > >      be granted access. If this string has the value of 'iscsi',
> > >      then any initiator may access this target."
> > > ::= { iscsiAccessListAttributesEntry 2 }
> > 
> > If you intend that an entry of "iscsi" means that "any initiator
> > name is allowed", then I think it's a little strange that a special
> > meaning applies to a name that an administrator might just happen to
> > use without realising it.
> 
> "iscsi" is a reserved initiator name value, and must not be assigned
> to an initiator or target by an adminstrator or manufacturer.  There
> should be no problems with using it here.
> 
> > 
> > Here are three alternatives which I think are better:
> > 
> > 1. have a column in the iscsiTargetAttributesTable which enables/disables
> >    the use of the access-list.  (Then, disabling has the same function as
> >    "icsci" entry.)
> 
> This is probably the cleanest; an implementation that does not do
> access lists would not have to implement the access list part of
> the MIB at all.
 
OK.

Thanks,
Keith.