Subject: [storm] iSCSI SAM update: login key

From: <[email-masked]>
Date: Fri, 26 Mar 2010 14:48:03 -0400

Based on discussion in the Anaheim meeting, here's the proposal that emerged for the login key to negotiate usage of the new features in the iSCSI SAM update draft (draft-ietf-storm-iscsi-sam-00).

Past concerns (that I can recall) about this have been:
- Key needs to negotiate iSCSI PDU format/content changes only.
- Detecting device support or lack thereof for SCSI features
	should be handled at the SCSI level (e.g., via SCSI commands).
- Using a SAM version number in this iSCSI key is not a good idea.
- Would like something that can accommodate future changes.
- Changing the key name from what's in the draft may be desired.

The proposal that emerged is:

The key name will be PDUFormatLevel.  It's a numeric (not boolean) key with two defined values:
	- 1 = Current iSCSI (all four RFCs - 3720, 3980, 4850 and 5048,
		but no change to required vs. optional features).
	- 2 = Current iSCSI plus features in update draft.
Usage is Leading Only (LO), scope is Session Wide (SW).
Default value is 1, result function is Minimum.

This will be an IETF key whose values are assigned by IETF standards action (standards-track RFC); it is not linked to SAM versions (e.g., a new version of SAM is not a prerequisite to assigning the value 3).

This key also provides a clean way to handle definition of iSCSI version descriptors in SPC-4:
- 0960h would remain "iSCSI (no version claimed)"
- The range 0961h-097Fh would be defined as 0960h + value
	of PDUFormatLevel key used by the device.
That results in one place (IANA registry) covering both definitions (key & version descriptor).

In order to support iSCSI version descriptors, we would ask IANA to put the values of the PDUFormatLevel key into a separate registry with its own URL, and then ask T10 to modify SPC-4.  The latter is not an immediate action - I would not anticipate bringing the SPC-4 proposal for that to T10 until after the RFC is published and the IANA registry is created.

This was the sense of the room + WebEx in Anaheim.  Absence of objection on the list will confirm the above as the approach to be taken (rough consensus of the storm WG).

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: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Fri, 26 Mar 2010 21:28:15 -0700

> This will be an IETF key whose values are assigned by IETF standards action
> (standards-track RFC); it is not linked to SAM versions (e.g., a new version
> of SAM is not a prerequisite to assigning the value 3).

Decoupling this key from SAM numbering space is a good idea.

I also suggest decoupling it from PDU structure changes.  Any new iSCSI standards track RFC, whether or not it extends/changes PDU format, should be able to claim a number by WG consensus.  Reasons for claiming a new number could include things like:
1) New feature introduction (e.g. new Opcodes, new TMF Codes, new Async codes) 
2) Major bug fix to the iSCSI protocol that affects end node processing
3) Change in semantics to keep up with changing SCSI semantics
4) A PDU Format enhancement
5) TBD reason by WG consensus

Reasons 1-3 may not have associated PDU format changes, unlike 4.  I suggest these should all be grounds for the WG to consider assigning a number.

Doing this allows implementations to negotiate a shared milestone at an RFC granularity (if that RFC has a number), as opposed to feature-by-feature negotiation (e.g. TaskReporting="FastAbort") with some gray areas that we had to resort to so far. 

Thanks.

Mallikarjun

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, March 26, 2010 11:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [storm] iSCSI SAM update: login key
> 
> Based on discussion in the Anaheim meeting, here's the proposal that emerged
> for the login key to negotiate usage of the new features in the iSCSI SAM
> update draft (draft-ietf-storm-iscsi-sam-00).
> 
> This will be an IETF key whose values are assigned by IETF standards action
> (standards-track RFC); it is not linked to SAM versions (e.g., a new version
> of SAM is not a prerequisite to assigning the value 3).
> 
> In order to support iSCSI version descriptors, we would ask IANA to put the
> values of the PDUFormatLevel key into a separate registry with its own URL,
> and then ask T10 to modify SPC-4.  The latter is not an immediate action - I
> would not anticipate bringing the SPC-4 proposal for that to T10 until after
> the RFC is published and the IANA registry is created.
> 
> This was the sense of the room + WebEx in Anaheim.  Absence of objection on
> the list will confirm the above as the approach to be taken (rough consensus
> of the storm WG).
> 
> Thanks,
> --David
> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm

---

From: <[email-masked]>
Date: Sat, 27 Mar 2010 01:52:13 -0400

Mallikarjun,

That makes sense (decouple from PDU structure changes), and suggests that we need a key name that doesn't use "PDUFormat" ...
... How about iSCSIProtocolLevel ?

It will be necessary to be conservative in defining new values - the requirement to publish a standards track RFC to define a new value should help with that.

Thanks,
--David

> From: Mallikarjun Chadalapaka [mailto:[email-masked]]
> Sent: Saturday, March 27, 2010 12:28 AM
> To: Black, David; [email-masked]
> Subject: RE: [storm] iSCSI SAM update: login key
> 
> I also suggest decoupling it from PDU structure changes.  Any new iSCSI standards track RFC, whether
> or not it extends/changes PDU format, should be able to claim a number by WG consensus.  Reasons for
> claiming a new number could include things like:
> Reasons 1-3 may not have associated PDU format changes, unlike 4.  I suggest these should all be
> grounds for the WG to consider assigning a number.
> 
> Doing this allows implementations to negotiate a shared milestone at an RFC granularity (if that RFC
> has a number), as opposed to feature-by-feature negotiation (e.g. TaskReporting="FastAbort") with some
> gray areas that we had to resort to so far.
> 
> Thanks.
> 
> Mallikarjun
>

---

From: Julian Satran <[email-masked]>
Date: Sat, 27 Mar 2010 09:57:24 +0300

I would suggest gen instead of level (level has too much of a value 
connotation - at least it my part of the world :-))

Julo

On 27/03/10 08:52, [email-masked] wrote:
>>> That results in one place (IANA registry) covering both definitions (key&
>>> version descriptor).
>>>

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Mon, 29 Mar 2010 17:15:05 -0700

OK, I then suggest iSCSIProtocolTier

I would be OK with iSCSIProtocolLevel as well.

Glad to see the consensus, thanks.

Mallikarjun

> From: Julian Satran [mailto:[email-masked]]
> Sent: Friday, March 26, 2010 11:57 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [storm] iSCSI SAM update: login key
> 
> > That makes sense (decouple from PDU structure changes), and suggests
that we
> need a key name that doesn't use "PDUFormat" ...
> > It will be necessary to be conservative in defining new values - the
> requirement to publish a standards track RFC to define a new value should
help
> with that.
> >> or not it extends/changes PDU format, should be able to claim a number
by
> WG consensus.  Reasons for
> >> Doing this allows implementations to negotiate a shared milestone at an
RFC
> granularity (if that RFC
> >>> The key name will be PDUFormatLevel.  It's a numeric (not boolean) key
> with
> >>> two defined values:
> >>> This key also provides a clean way to handle definition of iSCSI
version
> >>> descriptors in SPC-4:
> >>> In order to support iSCSI version descriptors, we would ask IANA to
put
> the
> >>> and then ask T10 to modify SPC-4.  The latter is not an immediate
action -
> I
> >>> This was the sense of the room + WebEx in Anaheim.  Absence of
objection
> on

---

From: <[email-masked]>
Date: Mon, 29 Mar 2010 21:59:02 -0400

<WG co-chair hat OFF>

We already have ErrorRecoveryLevel, so I don't see a problem with a
second key that ends in "Level".

Thanks,
--David

> Sent: Monday, March 29, 2010 8:15 PM
> To: 'Julian Satran'; Black, David
> Cc: [email-masked]
> > >>> This will be an IETF key whose values are assigned by IETF
standards
> > action
> > >>> (standards-track RFC); it is not linked to SAM versions (e.g., a
new
> > >> I also suggest decoupling it from PDU structure changes.  Any new
iSCSI
> > standards track RFC, whether
> > >> 1) New feature introduction (e.g. new Opcodes, new TMF Codes, new
Async
> > codes)
> > >> Reasons 1-3 may not have associated PDU format changes, unlike 4.
I
> > suggest these should all be
> > >>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of
> > >>> Based on discussion in the Anaheim meeting, here's the proposal
that
> > emerged
> > >>> for the login key to negotiate usage of the new features in the
iSCSI
> SAM
> > >>> This will be an IETF key whose values are assigned by IETF
standards
> > action
> > >>> (standards-track RFC); it is not linked to SAM versions (e.g., a
new
> > >>> That results in one place (IANA registry) covering both
definitions
> (key&
> > >>> values of the PDUFormatLevel key into a separate registry with
its own
> > URL,
> > >>> would not anticipate bringing the SPC-4 proposal for that to T10
until
> > after
> > >>> the list will confirm the above as the approach to be taken
(rough
> > consensus

---

From: Julian Satran <[email-masked]>
Date: Tue, 30 Mar 2010 07:42:46 +0300

It was just cosmetics. Anyhow with error recovery level really meant  
level. I wonder if with protocol we want every level to include all  
the preceding levels (including some obsolition) - in which case level  
is appropriate or merely a combination of things in which case I would  
suggest bundle. Also if it level the negotiation is numeric while for  
a combination it is boolean.

Regards,
Julo

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Tue, 30 Mar 2010 10:13:15 -0700

I tend to agree with David that "iSCSIProtocolLevel" is a reasonable name
given the precedent.

To Julian's point, just like ErrorRecoveryLevel, I suggest each value of
iSCSIProtocolLevel to be a logical superset of prior values - any deprecated
features should be automatically covered in this scheme assuming that each
such RFC that deprecates a feature requests a protocol level milestone.

I suggest the following verbiage to the new key description to make this
very clear:

Negotiation of iSCSIProtocolLevel key to a value claimed by an RFC indicates
that both negotiating parties are compliant to the RFC in question, and
agree to support the corresponding semantics on that iSCSI session.  An
operational value of iSCSIProtocolLevel=x on an iSCSI session requires that
the iSCSI protocol semantics on that iSCSI session be a logical superset of
the capabilities in all RFCs that have claimed values of iSCSIProtocolLevel
< x.

Thanks.

Mallikarjun

> Julian Satran
> Sent: Monday, March 29, 2010 9:43 PM
> To: <[email-masked]>
> Cc: [email-masked]; <[email-masked]>

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 21:39:26 -0400

<WG chair hat on>

I believe I see agreement on "iSCSIProtocolLevel".

Fred should consider Mallikarjun's text as input to the text describing
this key in the iSCSI update draft.

Thanks,
--David

> Sent: Tuesday, March 30, 2010 1:13 PM
> Cc: Black, David; [email-masked]
Behalf Of
> > >>>> It will be necessary to be conservative in defining new values
-
> > > the
> > >>> requirement to publish a standards track RFC to define a new
value
> > > should
> > >>>>> or not it extends/changes PDU format, should be able to claim
a
> > > number
> > >>>>> Doing this allows implementations to negotiate a shared
milestone
> > > at an
> > >> RFC
> > >>> granularity (if that RFC
> > >>>>> has a number), as opposed to feature-by-feature negotiation
(e.g.
> > >>> TaskReporting="FastAbort") with some
> > >>>>>> In order to support iSCSI version descriptors, we would ask
IANA
> > > to