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

[Santosh Rao <santoshr@cup.hp.com>]

I don't see why this thread is going forever. There are other scsi
transports that deal with these types of issues without having to define
scsi transport protocol keys to indicate vendor_id, product_id and
product_rev. You can do one of the following :

a) Parse out the DNS name of the target device from the exchanged
TargetName key, if you're an initiator. Similarly, parse out the DNS
name of the initiator from the exchanged InitiatorName key, if you're a
target. Use the DNS name as an indication of which device you're
speaking to and add your device specific tweaks based on this.

If the InitiatorName or TargetName is in EUI-64 format, you can obtain
the vendor_id information from the upper 3 bytes of the EUI-64 name.

b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and
product_revisison_level of the device. Use this data to perform any
device specific tweaks in your software/firmware.

c) Provide out-of-band static configuration mechanisms in your initiator
or target to assign a vendor specific identity to 1 or more initiators
or targets. This allows the target configuration personnel to configure
the device appropriately for the initiators it is speaking to. 

I don't see any need to be defining iscsi login keys to duplicate the
vendor_id, product_id information. 

- Santosh


Bill Studenmund wrote:
> 
> On Mon, 10 Jun 2002, David Robinson wrote:
> 
> > > What happens if we're somewhere inbetween? Or what if we find an issue
> > > where 80% of the implementations all chose the same way?
> > >
> > > I'm trying to scope out the shades of gray we might run into.
> >
> >
> > As a reminder about the IETF standards process, RFC2026. The IPS
> > working group is driving towards "Proposed Standard" which
> > by definition: "Implementors should treat Proposed Standards as
> > immature specifications." The next step is "Draft Standard"
> > where there is expectation that changes will be made between
> > Proposed and Draft.  "A Draft Standard is normally considered
> > to be a final specification..."
> >
> > To move from Proposed to Draft is where two independant implementations
> > are required and where the "80%" implementation problems are caught
> > and fixed.
> >
> > The RFC we are driving towards is just the first step in a long
> > path, there will be plenty of opportunities to fix "bugs" that
> > are found we real implementations are built. Thus vendor specific
> > keys are not needed, what we have today is not going to be
> > the "Internet Standard."
> 
> So what do we tell our customers? Our paying, cranky customers? That they
> are part of the great iSCSI experiment? Or worse yet, what are you going
> to tell your sales folks when a big sale doesn't go because of some
> interop quirk? Try again in 6 months when the equipment has already been
> bought? :-)
> 
> I'm not saying we shouldn't work (hard) to fix all the problems we can.
> 
> I'm saying that a policy of, "You loose," to the customers who run into an
> interop problem is impolite. :-|
> 
> Take care,
> 
> Bill

-- 
The world is so fast that there are days when the person who says 
it can't be done is interrupted by the person who is doing it.
	~ Anon