Re: [storm] iSCSI version descriptors

[Mallikarjun Chadalapaka <[e-mail]>]

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


 

>-----Original Message-----
>  From: [e-mail] [mailto:[e-mail]]
>  Sent: Tuesday, March 08, 2011 8:22 AM
>  To: [e-mail]; [e-mail]
>  Subject: RE: [storm] iSCSI version descriptors
>  
>  Mallikarjun,
>  
>  While I think your option 1) is ok:
>  
>  > 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.
>  
>  > 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.
>  
>  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
>  
>  > -----Original Message-----
>  > From: Mallikarjun Chadalapaka [mailto:[e-mail]]
>  > Sent: Monday, March 07, 2011 5:13 PM
>  > To: Black, David; [e-mail]
>  > Subject: RE: [storm] iSCSI version descriptors
>  >
>  > 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: [e-mail] [mailto:[e-mail]] On
>  Behalf
>  >   Of [e-mail]
>  >   Sent: Thursday, October 21, 2010 10:15 PM
>  >   To: [e-mail]
>  >   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
>  >   [phone]             FAX: [phone]
>  >   [e-mail]        Mobile: [phone]
>  >   ----------------------------------------------------
>  >
>  >   _______________________________________________
>  >   storm mailing list
>  >   [e-mail]
>  >   https://www.ietf.org/mailman/listinfo/storm
>  >
>
>