Subject: [storm] Consolidated iSCSI draft and TaskReporting

From: Patrick MacArthur <[email-masked]>
Date: Fri, 17 Jun 2011 10:38:17 -0400

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

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Fri, 17 Jun 2011 17:23:56 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
  Of Patrick MacArthur
  Sent: Friday, June 17, 2011 7:38 AM
  To: [email-masked]
  Subject: [storm] Consolidated iSCSI draft and TaskReporting
  
  Hi,
  
  I wanted to ask for clarification on an item appearing in the consolidated
  iSCSI draft.

  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,

  _______________________________________________
  storm mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/storm

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 16:30:39 -0400

<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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallikarjun Chadalapaka
> Sent: Friday, June 17, 2011 8:24 PM
> To: 'Patrick MacArthur'; [email-masked]
> Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting
> 
> Hi Patrick,
>

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Thu, 30 Jun 2011 15:06:42 -0700

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: [email-masked] [mailto:[email-masked]]
  Sent: Thursday, June 30, 2011 1:31 PM
  To: [email-masked]; [email-masked]; [email-masked]
  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
  
  > Of Mallikarjun Chadalapaka
  > 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".
  > 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.
  >   I wanted to ask for clarification on an item appearing in the
consolidated
  >   I would like to request that the references to RFC3720 above be
changed
  to
  >   If the STORM WG is trying to ensure compatibility with the
requirements
  of

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 19:15:04 -0400

In running this down, I found something else.   Neither the consolidated draft nor the SAM draft instructs IANA to add the iSCSIProtocolLevel key to the key registry - the SAM draft needs to do that (it currently does something close, but not quite right - see next paragraph).

In addition, the SAM draft needs to create a new "iSCSI Protocol Level" IANA registry for values of the iSCSIProtocolLevel key (it currently attempts to add the iSCSIProtocolLevel key and the value "2" to the key registry, which is not what should be done).  The SAM draft also needs to define the values "0" (no version claimed) and "2" for that registry.  Then the claiming approach will work - each draft states the requirements for understanding text keys based on its own protocol level. 

Thanks,
--David

> From: Mallikarjun Chadalapaka [mailto:[email-masked]]
> Sent: Thursday, June 30, 2011 6:07 PM
> To: Black, David; [email-masked]; [email-masked]