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

[Dennis Young <dyoung@rhapsodynetworks.com>]

Please see comments below.

>-----Original Message-----
>From: Robert Snively [mailto:rsnively@brocade.com]
>Sent: Friday, June 07, 2002 1:49 PM
>To: 'Dennis Young'; Robert Snively; 'Ken Sandars'; Ips Reflector
>(E-mail)
>Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys
>
>
>> 
>> 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 :-)

If this information helps in documenting and communicating
potential login problems, why not include it in the login?
Again, without this information, it is very difficult to
correlate a old trace with the product/revision of a remote device.

>
>> 
>> 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.
>

I agree that this information is already there, I am not suggesting
to replicate, but just provide another means to present it to the client.

Regards,
Dennis