Re: [storm] Consolidated iSCSI draft and TaskReporting

Mallikarjun and David,

In the iSCSI MIB (draft-00 will be posted by tomorrow morning PST), we have added iSCSIProtocolLevel to the Session attributes:

iscsiSsnProtocolLevel OBJECT-TYPE
    SYNTAX        Unsigned32 (1..65535)
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "The iSCSI protocol level negotiated for this session."
    REFERENCE
        "[iSCSI-SAM], Section 7.1.1, iSCSIProtocolLevel"
    DEFVAL        { 1 }
::= { iscsiSessionAttributesEntry 22 }

Instead of describing what the numbers mean as below, we are just referencing the SAM draft.  Is that the right thing, or is there more description we should be adding?

I'm fine with just referencing another spec, since that means we won't have to respin the MIB if another protocol level is added.

Thanks,

Mark

-----Original Message-----
From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
Sent: Thursday, June 30, 2011 5:07 PM
To: david.black@emc.com; pmacarth@iol.unh.edu; storm@ietf.org
Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting

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: david.black@emc.com [mailto:david.black@emc.com]
  Sent: Thursday, June 30, 2011 1:31 PM
  To: cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org
  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
  +1 (508) 293-7953             FAX: +1 (508) 293-7786
  david.black@emc.com        Mobile: +1 (978) 394-7754
  ----------------------------------------------------

  > -----Original Message-----
  > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
  Behalf
  > Of Mallikarjun Chadalapaka
  > Sent: Friday, June 17, 2011 8:24 PM
  > To: 'Patrick MacArthur'; storm@ietf.org
  > 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: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
  Behalf
  >   Of Patrick MacArthur
  >   Sent: Friday, June 17, 2011 7:38 AM
  >   To: storm@ietf.org
  >   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
  >   storm@ietf.org
  >   https://www.ietf.org/mailman/listinfo/storm
  >
  > _______________________________________________
  > storm mailing list
  > storm@ietf.org
  > https://www.ietf.org/mailman/listinfo/storm

_______________________________________________
storm mailing list
storm@ietf.org
https://www.ietf.org/mailman/listinfo/storm