Re: [storm] Consolidated iSCSI draft and TaskReporting

["Mark Bakke (mbakke)" <[e-mail]>]

Great; thanks, David.

Mark

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, July 05, 2011 7:39 AM
To: Mark Bakke (mbakke); [e-mail]; [e-mail]; [e-mail]
Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting

Mark,

That will suffice for now.  The next version of the SAM draft will create an IANA registry for these values; I would reference the SAM draft for the definition of iSCSIProtocolLevel (as you've done) plus the registry for the values.

Thanks,
--David

> -----Original Message-----
> From: Mark Bakke (mbakke) [mailto:[e-mail]]
> Sent: Sunday, July 03, 2011 11:51 PM
> To: Mallikarjun Chadalapaka; Black, David; [e-mail]; [e-mail]
> Subject: 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: [e-mail] [mailto:[e-mail]] On Behalf Of Mallikarjun Chadalapaka
> Sent: Thursday, June 30, 2011 5:07 PM
> To: [e-mail]; [e-mail]; [e-mail]
> 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: [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
> 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm