Re: [storm] iSCSI SAM update: login key

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

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Saturday, March 27, 2010 12:28 AM
> To: Black, David; storm@ietf.org
> Subject: 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
> 