Subject: Re: [storm] iSCSI version descriptors

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Mon, 7 Mar 2011 14:13:28 -0800

David,

In trying to determine what if any text needs to change in the consolidated
spec after this discussion, I did a re-reading of this whole thread - up to
DavidH's most recent note.   I stumbled on the following:

>  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).

I do not believe the consolidated spec needs to change the current
negotiation semantics.  I suggest a third option: 
1) When a feature is completely obsoleted (e.g. markers) relative to 3720,
iSCSI consolidated spec requires that the corresponding keys be negotiated
to "No" (e.g. OFMarker=No).

2) When a feature *option* is obsoleted (e.g. SPKM1 & SPKM2 for AuthMethod),
the spec does nothing special.    The existing iSCSI negotiation semantics
are comprehensive enough that two spec-compliant implementations will
negotiate to the correct result because the obsoleted options for that
feature are not offered as negotiables.

This should minimize the core protocol changes, and related impacts to
existing interop tests.
 
Comments are welcome.  With the fast-approaching Prague deadline, I will go
ahead with the spec'ing this option if I don't hear any disagreement on this
by this Wednesday.

Thanks.

Mallikarjun

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf
  Of [email-masked]
  Sent: Thursday, October 21, 2010 10:15 PM
  To: [email-masked]
  Subject: [storm] iSCSI version descriptors
  
  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).
  
  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.
  
  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.
  
  Comments?
  
  The SAM 4/5 features draft will expire while draft submission is closed
for
  the Beijing meeting - if we can resolve this issue, the next version of
that
  draft could be submitted shortly after draft submission opens again, and
  would probably go to WG Last Call shortly thereafter.
  
  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

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Mon, 7 Mar 2011 14:40:44 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf
  Of David Harrington
  Sent: Wednesday, December 08, 2010 7:01 AM
  To: [email-masked]; [email-masked]
  Cc: [email-masked]
  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
  [email-masked] (preferred for ietf)
  [email-masked]
  +1 603 828 1401 (cell)
  
  > Sent: Monday, October 25, 2010 9:56 AM
  > To: [email-masked]
  > Cc: [email-masked]
  > 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
  >
  >
  > > From: Paul Koning [mailto:[email-masked]]
  > > Sent: Friday, October 22, 2010 11:14 AM
  > > To: Black, David
  > > Cc: [email-masked]
  > > Subject: Re: [storm] iSCSI version descriptors
  > >
  > >
  > > On Oct 22, 2010, at 1:14 AM, <[email-masked]>
  > <[email-masked]> 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
  > > > 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
  > > > 	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
  > >
  >

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 11:22:05 -0500

Mallikarjun,

> to "No" (e.g. OFMarker=No).

My design preference is to recommend (SHOULD) a "Reject" value response, which is allowed by RFC 3720 and has the additional virtue of carrying a "What on earth do you think you're doing?" implication back to the clue-impaired implementation that tried to use the obsolete feature.  In any case, we're in clear agreement that a "NotUnderstood" response has to be prohibited.

> feature are not offered as negotiables.

That covers half the cases - new initiator with new or old responder.  With an old initiator, it is possible that obsolete options are offered.  If obsolete options are offered in combination with one or more supported options, everything should work fine.  If obsolete options are the only ones offered, "Reject" is an appropriate response.

Thanks,
--David

> From: Mallikarjun Chadalapaka [mailto:[email-masked]]
> Sent: Monday, March 07, 2011 5:13 PM
> To: Black, David; [email-masked]
> Subject: RE: [storm] iSCSI version descriptors
> 
> David,
> 
> >  When we take out a feature in the new iSCSI consolidated draft, the easiest

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 11:32:33 -0500

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

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

> Sent: Monday, March 07, 2011 5:41 PM
> To: 'David Harrington'; Black, David; [email-masked]
> Cc: [email-masked]

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 9 Mar 2011 12:51:13 -0800

David, 

I believe we are in general agreement.  Just a couple of comments.

>  My design preference is to recommend (SHOULD) a "Reject" value response,
>  which is allowed by RFC 3720 and has the additional virtue of carrying a
>  "What on earth do you think you're doing?" implication back to the clue-
>  impaired implementation that tried to use the obsolete feature.

I am fine with:  SHOULD "Reject", MAY reply with "No", MUST NOT reply with a
"NotUnderstood".

I have re-read the relevant RFC 3720 text and the formulation above is
compliant with its semantics.

>  That covers half the cases - new initiator with new or old responder.
With
>  an old initiator, it is possible that obsolete options are offered.  If
obsolete
>  options are offered in combination with one or more supported options,
>  everything should work fine.  If obsolete options are the only ones
offered,
>  "Reject" is an appropriate response.

We may be in violent agreement, :)  I agree with what you say, except I will
point out that the relevant list negotiation semantics are already in RFC
3720 (and by extension, already in Consolidated draft).  So nothing new
needs to be specified (which is what I meant by "nothing special"), consider
the following text in section 5.2.1 of RFC 3720:

   If an acceptor does not understand any particular value in a list, it
   MUST ignore it.  If an acceptor does not support, does not
   understand, or is not allowed to use any of the proposed options with
   a specific originator, it may use the constant "Reject" or terminate
   the negotiation.

Thanks.

Mallikarjun

>  From: [email-masked] [mailto:[email-masked]]
>  Sent: Tuesday, March 08, 2011 8:22 AM
>  To: [email-masked]; [email-masked]
>  > 1) When a feature is completely obsoleted (e.g. markers) relative to
>  > 3720, iSCSI consolidated spec requires that the corresponding keys be
>  > negotiated to "No" (e.g. OFMarker=No).
>  
>  My design preference is to recommend (SHOULD) a "Reject" value response,
>  which is allowed by RFC 3720 and has the additional virtue of carrying a
>  "What on earth do you think you're doing?" implication back to the clue-
>  impaired implementation that tried to use the obsolete feature.  In any
>  case, we're in clear agreement that a "NotUnderstood" response has to be
>  prohibited.
>  
>  That covers half the cases - new initiator with new or old responder.
With
>  an old initiator, it is possible that obsolete options are offered.  If
obsolete
>  options are offered in combination with one or more supported options,
>  everything should work fine.  If obsolete options are the only ones
offered,
>  "Reject" is an appropriate response.
>  
>  Thanks,
>  --David
>  
>  > In trying to determine what if any text needs to change in the
>  > consolidated spec after this discussion, I did a re-reading of this
whole
>  thread - up to
>  > > 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).
>  >
>  > 1) When a feature is completely obsoleted (e.g. markers) relative to
>  > 3720, iSCSI consolidated spec requires that the corresponding keys be
>  > negotiated to "No" (e.g. OFMarker=No).
>  >
>  > Comments are welcome.  With the fast-approaching Prague deadline, I
>  > will go ahead with the spec'ing this option if I don't hear any
>  > disagreement on this by this Wednesday.
>  >
>  > Thanks.
>  >
>  > Mallikarjun
>  >
>  >
>  >
>  >
>  >   (original iSCSI) + RFC 5048 (Corrections and Clarifications).  That
>  > would be
>  >   version value 1.
>  >
>  >   The SAM 4/5 features draft will expire while draft submission is
>  > closed for
>  >   the Beijing meeting - if we can resolve this issue, the next version
>  > of that

---

From: <[email-masked]>
Date: Wed, 9 Mar 2011 18:08:16 -0500

Yes, we're in agreement, violent or otherwise ;-).

Thanks,
--David

> Sent: Wednesday, March 09, 2011 3:51 PM
> >  That covers half the cases - new initiator with new or old responder. With
> >  an old initiator, it is possible that obsolete options are offered.  If obsolete
> >  everything should work fine.  If obsolete options are the only ones offered,