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

[pat_thaler@agilent.com]

Bill,

If x-keys are used for this then they should be given proper x-key names: 
x-reversed.dns_name.key_name

It is a bad precedent to ignore domain naming in some of the first x-keys.
People wouldn't want the dns name to be a vendor name in this case but 
perhaps a neutral party such as SNIA or UNH would be willing to have
its domain name used for such keys (and they have nice short DNS names).

Regards,
Pat

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Thursday, June 06, 2002 4:24 PM
To: Dennis Young
Cc: 'Bob Mastors'; Ken Sandars; Ips Reflector (E-mail)
Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys


On Thu, 6 Jun 2002, Dennis Young wrote:

> I think this is useful besides run time interoperability purpose
> (this is a hot button and can be argued either way, just like the
> version # of the draft), such as for reporting problems on a remote
> device to the device manufacturer.

I agree with Dennis.

I think though that Paul is right that these keys should NOT be used as an
excuse to permit interoperability problems. They can though be
informative. If a customer has problems with my code, I'd love to have
revision info, which could be conveniently conveyed with these keys.

As to the poster this morning (whose message I deleted too fast) who said
this is wrong because the info should be available in SCSI sense data, I
disagree. Consider the case of an iscsi->parallel scsi gateway (a box that
has a traditional scsi drive, and exports it over iSCSI). There the scsi
sense data & mode pages are (well might be) those of the attached drive,
which can be from a different vendor than the iscsi device.

Also, don't forget we're talking about an optional thing (they are X-keys
after all). :-)

Take care,

Bill