Date: Fri, 6 Jun 2003 16:46:10 +0000 (UTC)
From: wrstuden@wasabisystems.com
To: "Elizabeth G. Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>
Cc: "'KRUEGER,MARJORIE (HP-Roseville,ex1)'" <marjorie.krueger@hp.com>,
   "'Venkat Movva'" <vmovva@istor.com>, mbakke@cisco.com, black_david@emc.com,
   "'Ips@Ece.Cmu.Edu'" <ips@ece.cmu.edu>,
   "'Michele Hallak - Stamler'" <michele@SANRAD.COM>
Subject: RE: question about iscsiTgtPortalAttributesTable
In-Reply-To: <00e301c32bda$ad517ed0$d5839aa6@EGRodriguez>
Message-ID: <Pine.NEB.4.53.0306061601270.233@neverwinter.home-net.icnt.net>
References: <00e301c32bda$ad517ed0$d5839aa6@EGRodriguez>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Thu, 5 Jun 2003, Elizabeth G. Rodriguez wrote:

> Hi Bill,
>
> First off, wouldn't this need to be covered in the auth MIB instead of the
> iSCSI MIB?  (though both are in the hands of the ADs at this point).

Probably not. These "self" auths are auths just like any other, and the
current Auth-MIB structure describes them well.

> Do you have a proposed solution to the issue?
> Is this something that can be addressed in a new MIB, or does it really need
> to belong in one of the above named MIBs?

There are two solutions that I've thought of. One would be to add tables
say named iscsiTgtSelfAuth and iscsiIntrSelfAuth that parallel
iscsiTgtAuth and iscsiIntrAuth respectively yet contain the "self" auth
pointers. If someone comes up with a better name, I'd appreciate that too.
:-)

The other idea is to place a special meaning on items in either
iscsiTgtAuth or iscsiIntrAuth with the same name as the iSCSI node. Those
auths are taken to be the "self" auths.

The second idea is the most backwards-engineerable, but it means that
every time a program scans an auth list, it has to filter out the "self"
auths. Having two separate lists prevents that.

The two separate lists idea (adding new MIB tables) strikes me as the
cleanest, but I look forward to the working group's input. It also could
be done either in the iSCSI MIB RFC or in a follow-on RFC.

Our configuration language was modeled on the MIBs, both as they served as
a complete guide, and to make SNMP support simple. At different times,
we've implemented both the special names option and the separate list
option, and the separate list option was cleaner both in code and in
configuration documentation.

Take care,

Bill