Re: [storm] iSCSI SAM update: login key

> 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: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of
> Black_David@emc.com
> Sent: Friday, March 26, 2010 11:48 AM
> To: storm@ietf.org
> Cc: Black_David@emc.com
> 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).
> 
> 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
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm