Re: [storm] Consolidated iSCSI draft and TaskReporting

[Mallikarjun Chadalapaka <[e-mail]>]

I'm OK with leaving out the phrase you point out - I meant it to cover the
case of an acceptor in a key negotiation.  But I see your point.

I was thinking along the lines of each spec "claiming" a number for the
iSCSIProtocolLevel key, so no one spec necessarily has a table of all the
keys.  Currently, Consolidated draft claims  "1", and SAM draft claims "2".
Sounds like you're thinking a table with currently claimed
iSCSIProtocolLevel values in this spec?  I am fine with that too.

Thanks.

Mallikarjun


  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]
  Sent: Thursday, June 30, 2011 1:31 PM
  To: [e-mail]; [e-mail]; [e-mail]
  Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting
  
  <WG chair hat on>
  
  We should do what Mallikarjun proposes.  A table will be needed that lists
  the RFCs for each value of the iSCSIProtocolLevel key.
  
  One change - "(or would have offered)" should be removed from
  Mallikarjun's proposed text.  Hypothetical requirements tend to be
difficult
  to test and moreover are usually pointless - the values that are actually
  used in negotiation are what should govern protocol behavior.
  
  Thanks,
  --David
  ----------------------------------------------------
  David L. Black, Distinguished Engineer
  EMC Corporation, 176 South St., Hopkinton, MA  01748
  [phone]             FAX: [phone]
  [e-mail]        Mobile: [phone]
  ----------------------------------------------------
  
  > -----Original Message-----
  > From: [e-mail] [mailto:[e-mail]] On
  Behalf
  > Of Mallikarjun Chadalapaka
  > Sent: Friday, June 17, 2011 8:24 PM
  > To: 'Patrick MacArthur'; [e-mail]
  > Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting
  >
  > Hi Patrick,
  >
  > I tend to agree with you, you raise a valid point.
  >
  > The problem lies in special-casing RFC 3720.  I think the right way to
  > address your comment is to require that an implementation's
  "NotUnderstood"
  > response should correlate to the highest protocol version that it has
  > offered (or would have offered) for the iSCSIProtocolLevel key in a
  > negotiation.   E.g., let's say if an iSCSI implementation has *offered*
a
  > value of 2 in a negotiation (even though the other side has negotiated
  > it down to 1), it means that the offering implementation can
  > comprehend all text keys defined through the spec with
  > iSCSIProtocolLevel=2.  So it must not respond to any of those text keys
  with a "NotUnderstood".
  >
  > So the formal verbiage would look something like the following:
  >
  > An iSCSI implementation MUST comprehend all text keys defined in iSCSI
  > Protocol specifications from [RFC3720] through the RFC keyed to the
  > highest protocol version that the implementation has offered (or would
  > have offered) for the iSCSIProtocolLevel key in a negotiation.
  > Returning a NotUnderstood response on any of these text keys therefore
  > MUST be considered a protocol error and handled accordingly.  For all
  > other "later" keys, i.e. text keys defined in specifications keyed to
  > higher values of iSCSIProtocolLevel, a NotUnderstood  answer concludes
  > the negotiation for a negotiated key whereas for a declarative key, a
  > NotUnderstood answer simply informs the declarer of a lack of
  comprehension by the receiver.
  >
  > Please let me know if you have comments or questions.  Thanks.
  >
  > Mallikarjun
  >
  >
  >
  >   -----Original Message-----
  >   From: [e-mail] [mailto:[e-mail]] On
  Behalf
  >   Of Patrick MacArthur
  >   Sent: Friday, June 17, 2011 7:38 AM
  >   To: [e-mail]
  >   Subject: [storm] Consolidated iSCSI draft and TaskReporting
  >
  >   Hi,
  >
  >   I wanted to ask for clarification on an item appearing in the
consolidated
  >   iSCSI draft.
  >
  >       "All keys defined in [RFC3720] MUST be supported by all
  >       compliant implementations; a NotUnderstood answer on any of the
  >       [RFC3720] keys therefore MUST be considered a protocol error and
  >       handled accordingly. For all other later keys, a NotUnderstood
  >       answer concludes the negotiation for a negotiated key whereas for
  >       a declarative key, a NotUnderstood answer simply informs the
  >       declarer of a lack of comprehension by the receiver."
  >
  >   I would like to request that the references to RFC3720 above be
changed
  to
  >   RFC3720 and RFC5048.  The comments on this list seem to indicate that
  the
  >   baseline for the iSCSI work is on the combination of RFC 3720 and RFC
  >   5048, which I interpret to mean that it would be applicable only to
  >   implementations compliant with both RFCs.  An implementation that
  >   claims to be RFC 5048-compliant and responds with
  >   TaskReporting=NotUnderstood is broken IMHO. In that case, is there a
  >   reason that we allow a NotUnderstood response on an RFC 5048 key
  >   (TaskReporting)?
  >
  >   If the STORM WG is trying to ensure compatibility with the
requirements
  of
  >   RFC 3720 and RFC 5048 combined, it seems strange to be allowing
  >   implementers not to implement the key requirement of RFC 5048.
  >
  >   Thanks,
  >
  >   --
  >   Patrick MacArthur
  >   Research and Development
  >   iSCSI/OFA/IPv6 Consortia
  >   UNH InterOperability Laboratory
  >
  >   _______________________________________________
  >   storm mailing list
  >   [e-mail]
  >   https://www.ietf.org/mailman/listinfo/storm
  >
  > _______________________________________________
  > storm mailing list
  > [e-mail]
  > https://www.ietf.org/mailman/listinfo/storm