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

From: Bill Studenmund <[email-masked]>
Date: Thu, 6 Jun 2002 16:57:50 -0700 (PDT)

On Thu, 6 Jun 2002 [email-masked] wrote:

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

True. Point taken. Any volinteers?

Take care,

Bill

---

From: [email-masked]
Date: Thu, 6 Jun 2002 17:52:03 -0600

Bill,

Regards,
Pat

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
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

---

From: Ken Sandars <[email-masked]>
Date: Fri, 7 Jun 2002 10:49:31 +0000

On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote:
> > 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).
>

I agree that proper vendor-specific x-keys should use the reverse-dns format 
as stated. However, in this case the proposed keys are generic (for the good 
of all) and I'd hope are consistent.

Can we have a set of "well-known" X-keys which just start "X-"? 

It certainly is a legal format according to the spec. Support of course would 
be completely optional for these.

-- 
Ken Sandars
Eurologic Systems Ltd
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Fri, 7 Jun 2002 10:04:00 -0400

>>>>> "Ken" == Ken Sandars <[email-masked]> writes:

 Ken> On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote:
 >> On Thu, 6 Jun 2002 [email-masked] wrote: > 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).
 >> 

 Ken> I agree that proper vendor-specific x-keys should use the
 Ken> reverse-dns format as stated. However, in this case the proposed
 Ken> keys are generic (for the good of all) and I'd hope are
 Ken> consistent.

 Ken> Can we have a set of "well-known" X-keys which just start "X-"?

 Ken> It certainly is a legal format according to the spec. Support of
 Ken> course would be completely optional for these.

I am strongly opposed to any of this.

Clearly there's no way to stop people at foo.com defining an
x-com.foo.whatever, but I DO NOT like the idea of giving this notion
any semblance of official sanction by creating "standard" X- keys to
do what's proposed here.

   paul