Subject: IPS: iSCSI MIB last call

From: Mark Bakke <[email-masked]>
Date: Tue, 22 Oct 2002 16:10:19 -0500

Since I haven't seen any other last call comments on the
iSCSI MIB yet, I have one (technical) comment:

The iscsiTgtAuthAttributesTable is used to match up iSCSI
targets with lists of identities in the Auth MIB to which
the target will allow access.  Currently, any identity in
the list for a target will be authorized to have presumable
full access to the iSCSI target, other than anything that
may be enforced at higher layers (SCSI).  One thing we might
want to consider is to allow these entries to specify
whether the identity will be given read-only or read-write
access to the target, perhaps something like:

iscsiTgtAuthReadWrite OBJECT-TYPE
    SYNTAX        TruthValue
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
        "A truth value that specifies whether the referenced
        AuthIdentity will be allowed write access to the target.
        False (=No) indicates that only read operations may be
        performed.  True (=Yes) indicates that all access is
        allowed."
    DEFVAL        { true }
::= { iscsiNodeAttributesEntry 13 }

Thoughts?

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Paul Koning <[email-masked]>
Date: Wed, 23 Oct 2002 09:39:51 -0400

>>>>> "Mark" == Mark Bakke <[email-masked]> writes:

 Mark> Since I haven't seen any other last call comments on the iSCSI
 Mark> MIB yet, I have one (technical) comment:

 Mark> The iscsiTgtAuthAttributesTable is used to match up iSCSI
 Mark> targets with lists of identities in the Auth MIB to which the
 Mark> target will allow access.  Currently, any identity in the list
 Mark> for a target will be authorized to have presumable full access
 Mark> to the iSCSI target, other than anything that may be enforced
 Mark> at higher layers (SCSI).  One thing we might want to consider
 Mark> is to allow these entries to specify whether the identity will
 Mark> be given read-only or read-write access to the target, perhaps
 Mark> something like:

 Mark> iscsiTgtAuthReadWrite OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS
 Mark> read-write STATUS current DESCRIPTION "A truth value that
 Mark> specifies whether the referenced AuthIdentity will be allowed
 Mark> write access to the target.  False (=No) indicates that only
 Mark> read operations may be performed.  True (=Yes) indicates that
 Mark> all access is allowed."  DEFVAL { true } ::= {
 Mark> iscsiNodeAttributesEntry 13 }

 Mark> Thoughts?

I brought this up around here a while ago, and the reaction was that
this isn't all that useful.  The argument is that per-initiator access
control is for controlling shared access to a target.  As a rule,
operating systems support multiple readers, or (in things like
clusters) multiple initiators with full access, but not a mix of
readers and writers.

	paul

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 23 Oct 2002 09:17:42 -0700 (PDT)

> ::= { iscsiNodeAttributesEntry 13 }

Sounds interesting.

Another thought I had was to add a session-type field. It would be
Normal-Only, Discovery-Only, or Both.

This feature is designed to permit having "closed" targets (where the
target isn't seen in discovery, like closed 802.11 networks), and also to
permit anyone to do discovery (ipsAuthMethodNone is in the auth entry)  &
find the target, but not let everyone access the target.

Take care,

Bill