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

[Dennis Young <dyoung@rhapsodynetworks.com>]

Bill, 
Well summarized.
I prefer 4 also, but if it is too late for adding regular keys, then 3 will
do.
Regards,
-Dennis

>-----Original Message-----
>From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
>Sent: Friday, June 07, 2002 2:01 PM
[snip]
>** Summary **
>
>Let me see if I can wrap this thread up a little so that we 
>can get closer
>to closure.
>
>There is a suggestion that we add common-use keys to indicate vendor,
>model, and revision. The initial suggestion was for X-foo keys. This
>format violates our standard for how X- keys work, so an alternate of
>X-someone.short.foo was put forth. Dennis suggests above just 
>making them
>standard (I'm assuming Declarative) keys.
>
>Some of us (including myself) see diagnostic value in having 
>these keys in
>common use. One tcpdump of a session includes info about what 
>was talking
>to what.
>
>Some people are concerned that adding these keys will permit or tacitly
>encourage us to slide into a mode where we paper over interop problems
>rather than fix them. I think implicit in this point of view is that we
>don't have major interop problems now.
>
>Others (including myself) believe that the WG and the iSCSI 
>vendors will
>do the right thing and not lazily slide into that mess.
>
>
>So we have a proposal with 4 options and two motivations:
>
>Proposal for keys:
>
>1) Do nothing; don't encourage common-use keys
>2) Add X-vendor, X-product, and X-revision to the common 
>venacular. They
>	would of course be "vendor specific," just a number of vendors
>	would use them.
>3) Some short-named vendor come forward and add names in its space that
>	everyone use. Like say X-edu.unh.vendor, X-edu.unh.product...
>4) Make them standard keys, like Vendor, Product, Revision. 
>I'd vote they
>	are delcarative and per-direction. And if you talk to something
>	that doesn't understand them, you'll be talking to vendor
>	"NotUnderstood". :-)
>
>Motivations
>
>A) makes it easy to identify vendor/product/rev. All you have to do is
>capture a session (tcpdump/ethereal), and you have it. Info is in one
>place.
>
>B) Identify system on other side of connection/session to turn on/off
>quirk support.
>
>
>My thoughts:
>
>I like either option 3) or 4). I'd prefer 4, but I realize 
>this is late in
>the game for the standard, so 3) might be best for now.
>
>I think Motivation A is a damn good one, and reason enough to add these
>key. For Motivation B, as above, I don't think they will get us into
>messes we aren't already in, so they are fine.
>
>Take care,
>
>Bill
>