Subject: iSCSI: MIB Draft-01

From: Mark Bakke <[email-masked]>
Date: Mon, 25 Jun 2001 08:24:58 -0500

The new MIB has seen some significant changes.  Most notably,
it is much smaller.  You need not be afraid to read it any
longer.

Here are the modifications:

1. The object model has remained mostly the same, with the exception
   that we have changed the target listen port to a target portal,
   and have added an initiator portal.

2. Counters have been significantly pruned, from 254 down to 23.

3. Descriptions have been updated.

4. All of the IpAddress-type attributes have been changed to support
   either IPv4 or v6 addresses.

5. TCP port attributes have been renamed to support any upper-level
   transport protocol that iSCSI may later define.

6. iscsiCxnState enums have been defined.

7. Attributes on the "last failure" to occur have been added to the
   initiator and target objects, for use with notifications (traps).

8. Two notifications have been added - one for initiator-detected
   problems; the other for target-detected problems.

Julian has made the draft available on his web site at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-mib-01.txt

Please send any comments on the MIB by 7/xx; we plan to publish the
next version (with comments and draft-07 updates) by 7/18, for the
August IETF meeting.

Here are a few things in particular we'd like feedback on:

1. The IscsiSessionCxnErrorStatsTable is currently within the session,
   but in many implementations, the session will be destroyed as soon
   as one of these errors are counted.  Should this be moved to the
   target and initiator tables instead?

2. As soon as we clean up the SendTargets aggregation tag discussion,
   we will add a similar attribute to TargetPortal.

3. We used to have two authmethods in the SessionAttributes table for
   initiator and target.  These were removed after the -06 discussion
   of having them be symmetrical.  We'll put in whatever is appropriate
   when this has been resolved.

4. Would it be useful to a management station to be able to see the
   InitiatorAlias or TargetAlias of the "other side" of a session?  If
   so, we can add it.

5. We have most of the current negotiated attributes in the
   SessionAttributes table; should we be complete with these, or is
   there just a subset of these that is really useful for a management
   station to look at?

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