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

From: <[email-masked]>
Date: Mon, 20 Sep 2010 11:45:57 -0400

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:[email-masked]]
> Sent: Monday, March 08, 2010 2:06 AM
> To: 'Knight, Frederick'; Black, David; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Knight, Frederick
> > Sent: Tuesday, March 02, 2010 10:20 AM
> > To: [email-masked]; [email-masked]
> > 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 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: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, March 01, 2010 5:53 PM
> > To: [email-masked]
> > 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
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > storm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/storm
> > _______________________________________________
> > storm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/storm
>

---

From: Ralph Weber <[email-masked]>
Date: Mon, 20 Sep 2010 14:19:40 -0500

David,

I disagree with the definition of:

"0 - unknown (equivalent to a NotUnderstood response to the key)"

This conflicts with the existing T10 definition of 0, which is
-- as has been already pointed out -- "(no version claimed)".

Otherwise, I see no problems.

All the best,

.Ralph

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 16:42:42 -0400

Ok, let's make 0 = "no version claimed" ...

... which should still be functionally equivalent to a NotUnderstood response to the text key by the target (as the target is clearly speaking iSCSI, so by not responding to the text key, it has declined to claim support for an iSCSI version).

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Weber
> Sent: Monday, September 20, 2010 3:20 PM
> To: [email-masked]
> Subject: Re: [storm] iSCSI version descriptors (for SCSI SPC-4)
> 
>   David,
> 
> > 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.
> >
> > (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:
> > 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
> > (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
> >
> >

---

From: "Knight, Frederick" <[email-masked]>
Date: Tue, 21 Sep 2010 09:12:31 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 20, 2010 11:46 AM
To: [email-masked]; Knight, Frederick; [email-masked]
Cc: [email-masked]
Subject: iSCSI version descriptors (for SCSI SPC-4)

Comments?

Thanks,
--David

---

From: <[email-masked]>
Date: Tue, 21 Sep 2010 11:40:37 -0400

> 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

> From: Knight, Frederick [mailto:[email-masked]]
> Sent: Tuesday, September 21, 2010 9:13 AM
> To: Black, David; [email-masked]; [email-masked]
> Subject: RE: iSCSI version descriptors (for SCSI SPC-4)
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 22 Sep 2010 00:23:11 -0400

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Tuesday, September 21, 2010 11:41 AM
> To: [email-masked]; [email-masked]; [email-masked]
> > 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
> 
> 
> > 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.
> > 
> > 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
> > 
> > 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.
> > 
> > (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:
> > 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
> > (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 
> > > 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
> > >
> > >
> > >
> > > > From: [email-masked] [mailto:[email-masked]]
On 
> > > > Behalf Of Knight, Frederick
> > > > 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
> > > >
> > > > 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?
> > > >
> > > > David L. Black, Distinguished Engineer EMC Corporation, 
> 176 South 
> > > > St., Hopkinton, MA  01748

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 09:24:19 -0400

Hi Dave,

> includes a reference to the document that registered it.

We're just getting started here, and one of the goals of the current effort is to corral the information that implementers need into as few places as possible.  The registry won't have complete information about what each value means, so at least for now, it's (IMHO) better to define all 3 values in one place.  Over time, as additional registry values are defined (hopefully not a lot of them), they're likely to be in other documents.  For now, the text key and registry exist primarily for the value "2" being defined in the SAM features draft, and the key needs to be specified there (e.g., due to its different NotUnderstood behavior vs. other keys where NotUnderstood is not allowed).

While this is a judgment call, I'd prefer to see the key and its 3 initial values specified in one document so implementers have one place to look to understand it.

> standards process at roughly the same time?

Yes, in fact I think they're going to have to go in tandem, as I believe that each document will  normatively cross-reference the other.

Thanks,
--David

> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, September 22, 2010 12:23 AM
> To: Black, David; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [storm] iSCSI version descriptors (for SCSI SPC-4)
>
> Hi,
>
> (as a contributor)
>

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 22 Sep 2010 12:48:50 -0700

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

> Sent: Monday, September 20, 2010 8:46 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> 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:
> 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
> 
> 
> > Agreed on the SAM-5 version descriptor.  I assume the new draft will
> > 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).
> > 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
> >
> >
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > 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?
> > >
> > > 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
> > > We have some interesting technical decisions to make around asking
> > > for some SCSI version descriptor values.  For those not familiar
> > > 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).
> > >
> > > 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?
> > >
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > St., Hopkinton, MA  01748

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 16:03:17 -0400

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

> Sent: Wednesday, September 22, 2010 3:49 PM
> To: Black, David; [email-masked]; [email-masked]

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 22 Sep 2010 13:43:17 -0700

Markers and auth mechanisms are unimplemented per WG consensus so far, so
they alone should not be the reason for a distinct version # for
consolidated specification.

We have made a few minor changes here and there elsewhere in the draft -
mostly around iSCSI Node concept to accommodate a target and an initiator
node within it in order to cleanly explain XCOPY semantics.  Almost all
other editing is a result of the consolidation process.  We might though
make other TBD changes before we wrap up - in any case, as I said, it is
only a "to be safe" precaution given the size of the draft.  I do not yet
strongly feel about this one way or the other.

Mallikarjun

> Sent: Wednesday, September 22, 2010 1:03 PM
> 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
> 
> 
> > 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.
> >
> > 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).
> > > 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
> > > 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
> > > moves
> > > optimist),
> > > > Agreed on the SAM-5 version descriptor.  I assume the new draft
> > > > will in addition reference SAM-4.
> > > >
> > > > 3720+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).
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > > > 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
> > > > > 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
> > > > > 3720+must
> > > > > 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?
> > > > > 3720+5048+xxx; where xxx=the new SAM features RFC).  If the
> > > > > 3720+5048+device 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
> > > > >
> > > > > 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
> > > > > standards to which a device can claim to comply, and discourages
> > > > > unsuitable.  T10 only assigns version descriptors to drafts of
> > > > > standards that T10 believes
> > to be
> > > > > (draft-
> > > > > 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
> > > > > 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
> > > > > 	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
> > > > > 	for RFC 3720 by itself, as I'm concerned that such a
descriptor
> > would
> > > > > David L. Black, Distinguished Engineer EMC Corporation, 176
> > > > > South St., Hopkinton, MA  01748