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

["David Harrington" <[e-mail]>]

Hi,

(as a contributor)

I am not following very closely, so I have a question. 

> Also, this approach is potentially confusing - all 3 values 
> need to be in the same document,

Why? Isn't it common for IANA registries to have values added from
multiple documents?
I presume the registry is defined in such a way that each value also
includes a reference to the document that registered it.

so the approach of:
> > As written now, the drafts create the key in the SAM draft 
> (with the 
> > value 2), and the consolidated draft adds the value 0 and 1.

would seem reasonable.

Is it also not fairly likely the two documents would go through the
standards process at roughly the same time?

I may be missing something...

dbh

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of [e-mail]
> Sent: Tuesday, September 21, 2010 11:41 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [storm] iSCSI version descriptors (for SCSI SPC-4)
> 
> > As written now, the drafts create the key in the SAM draft 
> (with the 
> > value 2), and the consolidated draft adds the value 0 and 1.
> 
> The current version of the consolidated draft doesn't (yet) 
> appear to contain the text to add the 0 and 1 values.
> 
> Also, this approach is potentially confusing - all 3 values 
> need to be in the same document, which could be the SAM 
> draft.  In addition, more IANA Considerations  text is needed 
> to create a separate IANA registry for the values of the new 
> "iSCSIProtocolLevel" key and provide its initial content (all 
> 3 values).  On the assumption that it's better to have all 3 
> initial values in one place, the SAM draft would be that place.
> 
> The consolidated draft needs to be careful about the new 
> "iSCSIProtocolLevel" key, as a NotUnderstood response is 
> acceptable for that key, in contrast to most other iSCSI 
> keys.  If the key is defined in the SAM draft, then the 
> consolidated draft can say what the value 1 declares support 
> for and then normatively reference the SAM draft for the full 
> definition of the key (plus say that a NotUnderstood response 
> is acceptable for that new key).
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Knight, Frederick [mailto:[e-mail]]
> > Sent: Tuesday, September 21, 2010 9:13 AM
> > To: Black, David; [e-mail]; [e-mail]
> > Subject: RE: iSCSI version descriptors (for SCSI SPC-4)
> > 
> > Most of this is fine, but I do have 1 question.
> > 
> > We originally debated whether to create 1 draft that included 
> > everything (consolidated + SAM 4/5), or to create 2 drafts (1 for 
> > consolidated and 1 for new SAM 4/5 features).  The 
> consensus at the time was for 2 drafts.
> > 
> > Put "running code" based stuff in the consolidated draft.
> > 
> > Put all the new stuff in the SAM4/5 features draft.
> > 
> > This suggestion (adding a new key to the consolidated 
> draft) sort of 
> > muddies the waters.  I think we should be careful about 
> starting down 
> > a path where we pick and choose which new features we 
> decide to fold back into the consolidated draft, and which 
> new features we decide to exclude.
> > 
> > As written now, the drafts create the key in the SAM draft 
> (with the 
> > value 2), and the consolidated draft adds the value 0 and 1.
> > 
> > I'm not sure how much this matters, but we had reasons for the 
> > original choice we made about "running code" vs. "new" stuff, and 
> > while valid to revisit those reasons, I would prefer that 
> we do so explicitly.
> > 
> > 	Fred
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Monday, September 20, 2010 11:46 AM
> > To: [e-mail]; Knight, Frederick; [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
> > >
> > 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>