Re: [storm] iSCSI version descriptors

[<[e-mail]>]

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

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:[e-mail]]
> Sent: Wednesday, March 09, 2011 3:51 PM
> To: Black, David; [e-mail]
> Subject: RE: [storm] iSCSI version descriptors
> 
> 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
> >  >
> >
> >
>