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

From: "Julian Satran" <[email-masked]>
Date: Fri, 7 Jun 2002 19:03:09 +0300

Isn't "generic vendor keys" an oxymoron?  My English was never at Orwelian 
levels - Julo

Ken Sandars <[email-masked]>
Sent by: [email-masked]
06/07/2002 01:49 PM
Please respond to Ken Sandars

        To:     Bill Studenmund <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        Subject:        Re: iSCSI: Some proposed vendor-specific (X-) keys

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).
>
> True. Point taken. Any volinteers?
>

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: Dennis Young <[email-masked]>
Date: Fri, 7 Jun 2002 14:27:15 -0700

Please see comments below.

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

---

From: Dennis Young <[email-masked]>
Date: Fri, 7 Jun 2002 16:12:45 -0700

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

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