Re: [storm] iSCSI version descriptors

[<[e-mail]>]

I've talked to Fred Knight (author of the iSCSI-SAM extensions draft), and the plan that seems to make the most sense is the following (which matches your views):

> So at the moment, IMO, there's only need for 3 version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048 through RFC-consolidated
> 2: RFC iSCSI-SAM

We should endeavor to get reviews of the new drafts from important iSCSI implementers, and for now, I would prefer to put anything that isn't backwards compatible into the extensions draft (uses the value "2" above).

I do believe that's "rough consensus" for 3 values (0, 1, 2).

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:[e-mail]]
> Sent: Monday, March 07, 2011 5:41 PM
> To: 'David Harrington'; Black, David; [e-mail]
> Cc: [e-mail]
> Subject: RE: [storm] iSCSI version descriptors
> 
> Hi David (Harrington),
> 
> I agree with your summary, and I wanted to get your feedback on the
> following approach for the iSCSI Consolidated spec.
> 
> Unless I am seriously forgetting something, the nature of protocol changes
> in the iSCSI Consolidated spec so far fall roughly into three categories:
> 
> 1) Removing an optional feature
> 2) Removing non-mandatory negotiation options for a mandatory feature
> 3) Adding an optional feature
> 
> WG still has *not* come up with a need for the following:
> 4) Adding/Changing the mandatory behavior of protocol
> 5) Removing a previously mandatory feature
> 6) Removing previously mandatory negotiation options for a mandatory feature
> 
> 
> I do not believe changes of categories #1, #2 and #3 require a version
> number bump-up - consistent with your discussion below.   So at the moment,
> IMO, there's only need for 3 version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048 through RFC-consolidated
> 2: RFC iSCSI-SAM
> 
> However, *should* the WG decide to make any changes in categories #4, #5 or
> #6 down the road, I submit that (the eventual) RFC-consolidated will require
> its own version number because that will be a semantic change in a mandatory
> portion of the protocol.  So at that point, IMO, we should switch to 4
> version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048
> 2: RFC-consolidated
> 3: RFC iSCSI-SAM
> 
> Comments/corrections are welcome.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
>   -----Original Message-----
>   From: [e-mail] [mailto:[e-mail]] On Behalf
>   Of David Harrington
>   Sent: Wednesday, December 08, 2010 7:01 AM
>   To: [e-mail]; [e-mail]
>   Cc: [e-mail]
>   Subject: Re: [storm] iSCSI version descriptors
> 
>   Hi,
> 
>   Jumping in late ...
> 
>   I think compliance requirements are key here.
>   If you can be "compliant to version 1" if you implement mandatory feature
>   X AND if you do NOT implement mandatory feature X, then you don't have
>   a very good compliance requirement.
>   The purpose of a version # is to help identify the set of features that
> can be
>   expected to be supported by OTHER implementations, to ensure
>   interoperability.
>   (obviously, if the feature was originally, and continues to be, protocol-
>   negotiable that's not a problem within a version#)
> 
>   I think it could be a poor engineering choice to have version 1 refer to
>   multiple different possible sets of features. I disagree that "Yes, using
> the
>   same version should be a goal", if the set of features one implementation
>   can expect of another implementation changes; interoperability should be
>   the goal. You can ignore my engineering advice (I assume the WG knows the
>   technology better than me). But I would appreciate being educated why this
>   is OK.
> 
>   Interoperability is considered during IESG Evaluation
>   http://www.ietf.org/iesg/statement/discuss-criteria.html. If I question
> the
>   interoperability of using the same version #, others in the IESG also
> might
>   question this. So you should ***document in each
>   draft*** why using the same version # to identify the changes proposed in
>   that draft is OK technically from an interoperability standpoint.
> 
>   (p.s. "we've already implemented it that way from the draft" is NOT an
>   argument that holds much weight with the IESG).
> 
>   David Harrington
>   Director, IETF Transport Area
>   [e-mail] (preferred for ietf)
>   [e-mail]
>   [phone] (cell)
> 
>   > -----Original Message-----
>   > From: [e-mail] [mailto:[e-mail]] On
>   Behalf
>   > Of [e-mail]
>   > Sent: Monday, October 25, 2010 9:56 AM
>   > To: [e-mail]
>   > Cc: [e-mail]
>   > Subject: Re: [storm] iSCSI version descriptors
>   >
>   > > For now, I believe we should say 3270/5048 and not mention
>   > "new consolidated draft".  It doesn't
>   > > seem appropriate to reference a draft.  If we end up being
>   > able to reuse the code for the
>   > > consolidated spec, as intended, then at the time that spec
>   > comes out, the description of the code
>   > > points would be updated to say that it applies to that RFC as
>   well.
>   >
>   > Yes, the specifications of the version code values need to be in terms
>   > of RFC numbers, not references to Internet-Drafts.
>   >
>   > Thanks,
>   > --David
>   >
>   >
>   > > -----Original Message-----
>   > > From: Paul Koning [mailto:[e-mail]]
>   > > Sent: Friday, October 22, 2010 11:14 AM
>   > > To: Black, David
>   > > Cc: [e-mail]
>   > > Subject: Re: [storm] iSCSI version descriptors
>   > >
>   > >
>   > > On Oct 22, 2010, at 1:14 AM, <[e-mail]>
>   > <[e-mail]> wrote:
>   > >
>   > > > One more time on this issue.  This is for discussion -
>   > it's not an announcement of a decision.
>   > > This is the only real issue that needs to be resolved to
>   > complete the new (SAM) features draft for
>   > > iSCSI.
>   > > >
>   > > > Reminder: we need to define a set of small positive
>   > integer values to describe the iSCSI version
>   > > starting with 0 = "no version claimed".  After some private
>   > discussions, it appears that we need two
>   > > additional version values beyond 0.
>   > > >
>   > > > The first observation is that the baseline should be at
>   > least RFC 3720 (original iSCSI) + RFC 5048
>   > > (Corrections and Clarifications).  That would be version value 1.
>   > > >
>   > > > The next observation is that taking features out of the
>   > consolidated iSCSI draft may allow a
>   > > visible behavior change.  RFC 3720 has this to say about
>   > text keys for negotiation:
>   > > >
>   > > >   All keys in this document, except for the X extension
>   > formats, MUST
>   > > >   be supported by iSCSI initiators and targets when used
>   > as specified
>   > > >   here.  If used as specified, these keys MUST NOT be
>   > answered with
>   > > >   NotUnderstood.
>   > > >
>   > > > When we take out a feature in the new iSCSI consolidated
>   > draft, the easiest thing to do is allow a
>   > > NotUnderstood response to the keys that negotiate that
>   > feature.  This should not pose a problem for
>   > > unimplemented features, but it would be a behavior change.
>   > The completely backwards-compatible
>   > > alternative is have the consolidated iSCSI draft list the
>   > keys used for removed features and
>   > > prohibit  a NotUnderstood response to those keys (Reject
>   > would be an acceptable alternative
>   > > response).
>   > >
>   > > That sounds right.  Does it cause problems for that to be
>   > the answer?
>   > >
>   > > > If we're careful about this, the same version value can
>   > apply to 3720/5048 and the consolidated
>   > > iSCSI draft.  I'd suggest that we be careful, and the
>   > details of how can be worked out as we
>   > > finalize the consolidated draft - I think we should have at
>   > least one more round of looking at
>   > > features to remove.
>   > >
>   > > Yes, using the same version should be a goal.
>   > >
>   > > > After that, we'll need a version value for the new (SAM)
>   > features draft additions.  The result
>   > > would be 3 version values:
>   > > > 	0 = no version claimed
>   > > > 	1 = 3720/5048 or new consolidated draft
>   > > > 	2 = (3720/5048 or new consolidated draft) + SAM 4/5
>   > features from the SAM draft.
>   > >
>   > > I assume these numbers will be handled by IANA, so they'll
>   > need an IANA Considerations section
>   > > spelling out how.
>   > >
>   > > For now, I believe we should say 3270/5048 and not mention
>   > "new consolidated draft".  It doesn't
>   > > seem appropriate to reference a draft.  If we end up being
>   > able to reuse the code for the
>   > > consolidated spec, as intended, then at the time that spec
>   > comes out, the description of the code
>   > > points would be updated to say that it applies to that RFC as
>   well.
>   > >
>   > > For the SAM draft, can we reference a specific draft?  I
>   > think it's quite absurd that drafts even
>   > > have standard status in the first place, but given that
>   > they do, we need to be precise about which
>   > > document we're talking about.  If we say "draft 2010/10/34"
>   > now, and then a followup draft comes out
>   > > for which the same code point is appropriate, we'd update
>   > the description of the code point to list
>   > > that one as well.  But we can't leave it unstated.
>   > >
>   > > 	paul
>   > >
>   >
>   > _______________________________________________
>   > storm mailing list
>   > [e-mail]
>   > https://www.ietf.org/mailman/listinfo/storm
>   >
> 
>   _______________________________________________
>   storm mailing list
>   [e-mail]
>   https://www.ietf.org/mailman/listinfo/storm
>