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

[Dennis Young <dyoung@rhapsodynetworks.com>]

Hi Bob,

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.

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.

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.

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

Regards,
-Dennis 

>-----Original Message-----
>From: Robert Snively [mailto:rsnively@Brocade.COM]
>Sent: Friday, June 07, 2002 8:32 AM
>To: 'Ken Sandars'; Robert Snively; Ips Reflector (E-mail)
>Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys
>
>
>Ken,
>
>In my experience, "vendor specific" is a synonym for
>"non-interoperable".  Realistically, if there is any tuning
>to be done with respect to the iSCSI transport behavior, then
>it should be done through standardized mechanisms during
>the login, not through vendor specific mechanisms.
>
>The management component already has standard mechanisms
>for determining such information, including MIBs and CIM
>objects.  The operational components already have standard
>mechanisms for determining such information, including
>SCSI INQUIRY commands.  I cannot see how this additional
>(non-standard) mechanism for capturing this information is
>going to help iSCSI achieve its goals.
>
>Those legacy devices that are being supported by non-standard
>programs and non-standard protocol events are simply NOT
>compliant iSCSI devices.  If anyone cares about using them
>in an iSCSI environment, they must be upgraded to iSCSI
>compliance.
>
>Bob
>
>
>
>> -----Original Message-----
>> From: Ken Sandars [mailto:ksandars@eurologic.com]
>> Sent: Friday, June 07, 2002 4:20 AM
>> To: Robert Snively; Ips Reflector (E-mail)
>> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
>> 
>> 
>> Hi Bob,
>> 
>> No, that's not what I'm suggesting. I was not looking at 
>> affecting anything 
>> at the SCSI layer. This proposal is purely communicating 
>> information between 
>> the iSCSI (transport) layers. I wouldn't expect this information to 
>> necessarily be passed to the SCSI layer on either target or 
>initiator.
>> 
>> This information was intended to be used at the iSCSI layer 
>> to "tune" iSCSI 
>> behaviour, and to provide additional information to the 
>> management component 
>> of each implementation. The latter reason is more important 
>> as it can assist 
>> in maintaining an iSCSI SAN, and this is where I'd like to 
>> see this end up.
>> 
>