RE: SCSI MIB: Open Issues

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie.krueger@hp.com>]

> From Marjorie Krueger's email:
> subject: Comments on draft-ietf-ips-scsi-mib-04
> Sent: Wednesday, December 11, 2002 21:40
> 
> 6)scsiInstAlias, scsiDeviceAlias, etc -why are these admin strings 
> limited to 79 characters?  IMO, these SYNTAX should just be 
> SnmpAdminString w/no additional size limitation.
> 
> MHS>>>>>>>>>> I would like to hear other opinions.

The question was "Why are these limited to 79 characters?"  I don't remember
the team discussing this.  I'm not aware that it's a standard thing to do.
Unless there's valid logic to this choice, the generically accepted thing to
do is leave the size as default (256 char) and if an implementation can't
handle this much, it truncates the string - I've seen it done before.

> 
> 8) scsiDscLunLun - the discovered LUN number is a natural 
> index for this table, there is no need for another artificial 
> index.  So this table 
> should look like: ......
> 
> MHS>>>>>>>>>>> LUN is generally an 8-bytes integer that can be 0:
> 1. To have it as an index looks heavy from my point of view.

What does "heavy" mean in this context?

> 2. It is generally not recommended to have 0 as an index.

Thats only true for integer, artifically created indexes, and it's guideline
for "range limited indexes".  The natural index for a table is generally the
"friendliest" to use.

> (Sajay's comments)
> Hi all,
> 
>      Regarding usage of scsiDscLunLun as the index, I agree 
> with Michelle that it introduces complexities. Additionally,

What complexities?  An implementation already has to generate this object,
using it as the index does not "introduce additional complexity".

> 
> - The default nature of LUN0 might be confused with a special index
>   value of 0

How?  This field is not defined as a "special index value of 0".  That seems
clear to me.
 
> - I'm not sure how well it scales for hierarchical LUN addressing.

??? Again, this object as currently defined already has to be generated, how
does using it as an index add any new problems?

> 
> - Non-contiguous possibility of the index will be just that much
>   more difficult to implement.

Not true at all.  I've implemented many many "non-contiguous" indexes, there
is no correlation between "contigousness" and "ease of implementation"
(unless you are implementing everything as simple arrays, and that would be
a limitation of your implementation, not a choice that should be imposed by
a standard MIB definition!)

> While none of these make the choice of scsiDscLunLun as an index 
> invalid, I think they add up to a present a failrly substantial case 
> against it.

I don't feel your comments are detailed enough add up to a case against
this.  

There is often a "natural key" for a table of information, the item that
uniquely identifies a table record, and that is the easiest object to use to
look up information - this is basic database design 101.  The LUN is the
natural key for this table.