|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: question about iscsiTgtPortalAttributesTableOn 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
Home Last updated: Thu Jun 12 22:19:21 2003 12637 messages in chronological order |