Re: [storm] iSCSI version descriptors (for SCSI SPC-4)

[<[e-mail]>]

So, far, I believe all the functionality that we've decided to remove in the consolidated draft is unimplemented.  Assuming that remains the case, I'm not clear on the rationale for a functional distinction between [3720, 5048 and friends] vs. the new consolidated specification.

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:[e-mail]]
> Sent: Wednesday, September 22, 2010 3:49 PM
> To: Black, David; [e-mail]; [e-mail]
> Subject: RE: iSCSI version descriptors (for SCSI SPC-4)
> 
> Hi David,
> 
> Thanks for circling back to this.
> 
> Your outline looks good overall, I like the proposed ability to let the
> relevant IETF WG choose the iSCSI version descriptors and associated
> semantics - based on a "pre-approved" numbering space from T10, albeit the
> "pre-approval" might in fact happen at the end as you say once we have the
> RFC numbers and an established IANA registry.
> 
> I have two specific comments:
> 
> 1) To be safe, I think we need one more defined value for
> iSCSIProtocolLevel:
> 	0: No version claimed (legacy implementations)
> 	1: RFC 3720+RFC 5048 (iSCSI protocol, with corrections and
> clarifications)
> 	2: RFC-iSCSI-consolidated (with obsoleted markers & auth mechanisms
> and all other tweaks relative to previous baseline)
> 	3: RFC-SAM-4 (with SAM-4 compliance support)
> 
> 2) If the above looks reasonable, particularly the ordering (with implied
> superset semantics), seems to me that the iSCSIProtocolLevel key definition
> has to be in the RFC-iSCSI-consolidated for it to be able to claim a smaller
> number (as smaller numbers indicate chronological predecessors).
> 
> Thanks.
> 
> Mallikarjun
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Monday, September 20, 2010 8:46 AM
> > To: [e-mail]; [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: iSCSI version descriptors (for SCSI SPC-4)
> >
> > It's time to come back to this topic.
> >
> > I believe that what should happen is to have SPC-4 point to an IANA
> registry for
> > all iSCSI version descriptors other than the existing "(no version
> claimed)"
> > descriptor (might be SPC-5 by the time we get all the pieces in place).
> The
> > reason for doing this is to put IETF in a position to create new version
> > descriptors for iSCSI without having to ask T10 to do so (although, it
> makes
> > sense to ask T10 to reflect the currently-valid version descriptors for
> iSCSI in
> > each version of SPC).
> >
> > Getting this to happen requires some work.  For starters, note that the
> existing
> > 0x960 iSCSI version descriptor can be used by any version of iSCSI - "no
> version
> > claimed" means that no assumptions can be made about presence or absence
> of
> > functionality.  For that reason, my personal (not as WG chair) preference
> is that
> > we create a version descriptor for RFC 3720 + RFC 5048 as reflected in the
> new
> > combined iSCSI draft, in order to provide a means for an implementation to
> > promise support for the corrections and clarifications in RFC 5048 - that
> > descriptor should also promise support for NAA iSCSI names (RFC 3980) and
> the
> > Node Architecture key (RFC 4850).  Not using any iSCSI version descriptor,
> or
> > using the existing 0x960 version descriptor, doesn't declare absence of
> support -
> > the only valid inference that an application client (initiator) can make
> is "don't
> > know".  We do need to get to a conclusion on whether to define this
> version
> > descriptor.
> >
> > The actual mechanics for coordinating this across IETF and T10 involve
> several
> > steps:
> > (1) The "iSCSIProtocolLevel" key should be defined in the consolidated
> iSCSI
> > draft, including creation of an IANA registry for its values (range: 0 -
> 31) and
> > defining the first two values:
> > 	0 - unknown (equivalent to a NotUnderstood response to the key)
> > 	1 - 3720 + 5048, etc., as reflected in the consolidated iSCSI draft.
> > I included 0 for completeness - it's not strictly necessary.  This moves
> creation of
> > that key from the SAM 4/5 features update draft to the main consolidated
> draft
> > (2) The new SAM-4/5 features draft then defines the value 2 and adds it to
> that
> > IANA registry.
> > (3) As an interim measure, after WG last call is completed, we (that
> probably
> > means Fred and I) write a T10 proposal to create the version descriptors
> 0x961
> > and 0x962 (corresponding to the values 1 and 2 for the
> "iSCSIProtocolLevel"
> > key).  That makes both version descriptors usable, and provides an
> opportunity
> > for the (inevitable) T10 input on exactly how the values of the
> > "iSCSIProtocolLevel" key are specified.
> > (4) After the RFCs are published for both drafts (yes, I'm an optimist),
> another
> > T10 proposal then updates SPC-4 to cross-reference the IANA registry.
> >
> > Combining steps (3) and (4) at T10 would require both early creation of
> the IANA
> > registry and early assignment of the RFC numbers.  It's not immediately
> clear to
> > me that this should be done - we can figure out whether/how to do this at
> the
> > time when the first T10 proposal needs to be written.
> >
> > Comments?
> >
> > Thanks,
> > --David
> >
> >
> > > -----Original Message-----
> > > From: Mallikarjun Chadalapaka [mailto:[e-mail]]
> > > Sent: Monday, March 08, 2010 2:06 AM
> > > To: 'Knight, Frederick'; Black, David; [e-mail]
> > > Subject: RE: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > >
> > > Agreed on the SAM-5 version descriptor.  I assume the new draft will
> > > in addition reference SAM-4.
> > >
> > > On the iSCSI version descriptions, I actually think creating a
> > > 3720+5048 version descriptor is a good start.  As Fred says, existing
> > > implementations will be initially not reporting this so the initiator
> > > is left to other means to figure out the compliance level (and iSCSI
> > > provides the hooks to discern that).  However, I believe this new
> > > version descriptor will help provide clarity down the road as existing
> > > implementations catch up to the standard - as opposed to leaving it
> > > open-ended until all implementations catch up to the SAM-5 draft (which
> takes
> > even longer to get to).
> > >
> > > So I guess my preference is to create a 3720+5048 version descriptor,
> > > assuming it's OK to approach T10 any time in future with a request to
> > > add additional milestones based on implementation feedback from the WG.
> > >
> > > Thanks.
> > >
> > > Mallikarjun
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > > > Behalf Of Knight, Frederick
> > > > Sent: Tuesday, March 02, 2010 10:20 AM
> > > > To: [e-mail]; [e-mail]
> > > > Subject: Re: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > > >
> > > > I agree, we need to request a frozen SAM-5 version descriptor, and
> > > > see what they say.
> > > >
> > > > I'm reluctant to create a new descriptor to indicate compliance with
> > > > something old (3720+5048).
> > > >
> > > > All those existing implementations that support 3720+5048 will NOT
> > > > have that descriptor.  What is an initiator to think?  How will the
> > > > initiator tell an old compliant device that supports 3720+5048 with
> > > > no descriptor from the new compliant device that supports 3720+5048
> > > > but has the descriptor?  My fear is a host that assumes that if the
> > > > 3720+5048 descriptor you propose is NOT present, then the device must
> > NOT be 3720+5048 compliant.
> > > >
> > > > I'm reluctant to punish existing compliant devices by creating a
> > > > descriptor that they will not report.  The horse is already out of
> > > > the barn, what good will it do to post a "please close the door" sign?
> > > >
> > > > We should however, request that T10 create a descriptor that
> > > > indicates compliance with the new SAM features draft (which
> > > > therefore means
> > > > 3720+5048+xxx; where xxx=the new SAM features RFC).  If the device
> > > > 3720+5048+doesn't
> > > > report this new descriptor, then you must use iSCSI mechanisms to
> > > > determine if the device is 3720 only, or 3720+5048.
> > > >
> > > > 	Fred Knight
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Monday, March 01, 2010 5:53 PM
> > > > To: [e-mail]
> > > > Subject: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > > >
> > > > <WG Chair Hat On>
> > > >
> > > > We have some interesting technical decisions to make around asking
> > > > for some SCSI version descriptor values.  For those not familiar
> > > > with them, a SCSI device can return up to 8 2-byte version
> > > > descriptors in bytes 58-73 of standard INQUIRY data (see section
> > > > 6.4.2 in SPC-3 or the latest draft of SPC- 4).  A version descriptor
> value
> > specifies both a standard and a revision.
> > > > Version descriptor values are defined by explicit action at T10;
> > > > this serves as an indirect control over which versions of standards
> > > > to which a device can claim to comply, and discourages compliance
> > > > with revisions that are unstable or otherwise unsuitable.  T10 only
> > > > assigns version descriptors to drafts of standards that T10 believes
> to be
> > stable (e.g., suitable to implement from).
> > > >
> > > > The straightforward decision is that the iSCSI features update draft
> > > > (draft-
> > > > ietf-storm-iscsi-sam) will need to reference a stable version of the
> > > > SAM-5 standard (under development) prior to the completion of SAM-5
> work
> > at T10.
> > > I
> > > > suggest that Fred Knight (editor of the draft) and I discuss this at
> > > > next week's meeting of T10 (specifically, the CAP WG in T10) in a
> > > > couple of weeks and bring the resulting recommendation to the storm
> > > > WG list and the Anaheim meeting.  Based on what's in the current
> > > > draft of SAM-5, T10 may assign a version descriptor, or recommend
> > > > that we wait for some more things that are known to be inbound.
> > > >
> > > > The more interesting decision is version descriptors for iSCSI.
> > > > Currently, there's only a generic version descriptor value , 0x960h
> > > > "iSCSI (no version claimed)".  There are an additional 31 descriptor
> > > > values available to iSCSI, and so the question to the storm WG is -
> what
> > would we like to see defined?
> > > >
> > > > I have two initial suggestions:
> > > > 1) I suggest asking that a version descriptor be defined for the
> combination
> > > > 	of RFC 3720 (iSCSI) and RFC 5048 (iSCSI corrections and
> clarifications)
> > > > 	to enable a device to claim that it has implemented RFC 5048.  We
> could
> > > > 	add additional RFCs to this set, e.g., RFC 3980 for NAA names,
> although
> > > > 	I'm not sure that's useful to know post-login.'
> > > > 2) I strongly suggest *not* asking that a version descriptor be
> defined
> > > > 	for RFC 3720 by itself, as I'm concerned that such a descriptor
> would
> > > > 	serve as a (small) disincentive to implement RFC 5048.
> > > > Please comment on these.
> > > >
> > > > Thanks,
> > > > --David
> > > > ----------------------------------------------------
> > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > > St., Hopkinton, MA  01748
> > > > [phone]             FAX: [phone]
> > > > [e-mail]        Mobile: [phone]
> > > > ----------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > storm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/storm
> > > > _______________________________________________
> > > > storm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/storm
> > >
> 
>