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

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 7 Jun 2002, Dennis Young wrote:

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

True. Very true.

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

Plus it's a piece of separate information that must manually be
assosciated with the trace.

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

More to the point, if I have a customer come to me with a problem, if
these keys are in the login sequence, I can have the customer tcpdump the
session and send it to me. Info about exactly what rev of my product and
of the other side are in that dump. It means there's one file to send in
for analysis.

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

Sounds like there is enough interest that regular keys might be warranted.

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

Robert,

What about the case(s) Luben describes, where due to problems in the spec,
two different implementations that both follow the spec don't
interoperate? The case of compliant-non-interoperability?

I don't think anyone on this list wants that, but from what Luben says, we
have it now.

I gather that you believe that if we add these keys, we will be opening
the door to an interoperability mess. I believe that is not correct; we
either have a spec that permits compliant-non-interoperability, or we
don't. I do not believe that adding or not adding these keys will change
that.

All adding these keys will do would be to make it easier for iSCSI code to
cope with discovered compliant-non-interoperability; for them to encourage
it would mean that the working group has stopped improving the spec.

Also, what do we do with installed systems? Say we find and correct a
problem. Until our end users upgrade field-deployed systems, the problem
continues. Are the sysadmins of our customers going to be happy if we try
to force them to upgrade production "seems-to-work" systems, just because
we found a bug in the spec? My experience as a sysadmin and with sysadmins
is that they will say rude things to us and ignore us. That's not a good
way to sell iSCSI systems. :-|

** 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