RE: iSCSI: Some proposed vendor-specific (X-) keys

[Robert Snively <rsnively@Brocade.COM>]

> 
> Regarding the management component, it is very useful to
> have the vendor product name and revision number available 
> as part of the iSCSI login negotiation, this would allow 
> the developer/administrator to save the login trace to syslog 
> or something similar for immediate or future analysis or 
> bug reporting.  Without this information embedded in the trace, 
> it would be very difficult to go back to the old log and
> know for sure which revision of the product you were dealing 
> with.

Not a function of the login.  This is a function of the
MIB at the management level and of the SCSI Inquiry at
the driver level.  Unless of course you don't believe in
standard internet and storage management protocols :-)

> 
> Accessing iSCSI MIB requires a separate step, path, management
> tool.  Some low end products may not provide it at all.
> And most importantly, it won't help you if you have to analyze 
> some old traces.
> 

Are there actually devices in an iSCSI environment that will
have no MIB? 

> Think of this scenario, suppose you are building an iSCSI HBA
> and you need to do login interoperability testings with 10 
> different iSCSI targets, wouldn't it be nice that all you have 
> to do is to run the tests and save the login traces, knowing that 
> the product id and revision is embedded in the trace.
> 

Nope.  I know who they are by their MIB or CIM information.

> I feel that this kind of information should definitely be there, 
> if X key is not appropriate, I would suggest to use regular key.

I feel that this information is already there and creating
a redundant and non-standard mechanism for replicating this
information is a real problem.