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

From: Dennis Young <[email-masked]>
Date: Fri, 7 Jun 2002 11:05:30 -0700

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.

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.

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.

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

Regards,
-Dennis 

>-----Original Message-----
>From: Robert Snively [mailto:[email-masked]]
>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.
>
>The management component already has standard mechanisms
>for determining such information, including MIBs and CIM
>objects.  The operational components already have standard
>mechanisms for determining such information, including
>SCSI INQUIRY commands.  I cannot see how this additional
>(non-standard) mechanism for capturing this information is
>going to help iSCSI achieve its goals.
>
>Those legacy devices that are being supported by non-standard
>programs and non-standard protocol events are simply NOT
>compliant iSCSI devices.  If anyone cares about using them
>in an iSCSI environment, they must be upgraded to iSCSI
>compliance.
>
>Bob
>
>
>
>> -----Original Message-----
>> From: Ken Sandars [mailto:[email-masked]]
>> Sent: Friday, June 07, 2002 4:20 AM
>> To: Robert Snively; Ips Reflector (E-mail)
>> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
>> 
>> 
>> Hi Bob,
>> 
>> No, that's not what I'm suggesting. I was not looking at 
>> affecting anything 
>> at the SCSI layer. This proposal is purely communicating 
>> information between 
>> the iSCSI (transport) layers. I wouldn't expect this information to 
>> necessarily be passed to the SCSI layer on either target or 
>initiator.
>> 
>> This information was intended to be used at the iSCSI layer 
>> to "tune" iSCSI 
>> behaviour, and to provide additional information to the 
>> management component 
>> of each implementation. The latter reason is more important 
>> as it can assist 
>> in maintaining an iSCSI SAN, and this is where I'd like to 
>> see this end up.
>> 
>

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 7 Jun 2002 14:01:08 -0700 (PDT)

> know for sure which revision of the product you were dealing

True. Very true.

> And most importantly, it won't help you if you have to analyze

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

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

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

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

---

From: Paul Koning <[email-masked]>
Date: Sun, 9 Jun 2002 14:12:06 -0400

Excerpt of message (sent 7 June 2002) by Bill Studenmund:
> ...

Those are defects in the spec; if those cases are real then the spec
must be fixed prior to being released.  
 
> don't. I do not believe that adding or not adding these keys will change

That's not what I said.  What I said is that adding these keys will
weaken the incentive to fix the interoperability problems, which will
harm the success of iSCSI.
 
> way to sell iSCSI systems. :-|

So what makes iSCSI different from the dozens of protocols that have
been created in the past that do not do this? 
 
> don't have major interop problems now.

I never said that we do not have major interop problems.  Maybe we do,
maybe we don't.  If we do, how about exposing them explicitly and
FIXING THEM?

> do the right thing and not lazily slide into that mess.

I have seen protocols that implement this sort of feature, and based
on that experience I am not as optimistic as you are. 

> 	that doesn't understand them, you'll be talking to vendor

I am in favor of 1, and object strongly to 2, 3, and 4.

    paul