Re: [storm] iSCSI SAM update: login key

["David Harrington" <[e-mail]>]

<as individual contributor>

Level seems to imply that anything earlier is supported, so (using
rfc#s as levels for my example):
if there existed (independent) features in rfc 7501, 7522, and 7599, 
then level=rfc7599 would imply that 7501 and 7522 MUST be supported as
well?
And nothing could ever be not-backwards-compatible.
Maybe that is what the WG wants.

I wonder if it might be more flexible to define an approach, such as
bits in a bit string, so different combinations could be supported:
	bit 1: 7501
	bit 2: 7522
	bit 3: 7599

so an implementation could support, for example, rfcs 7501 and 7599
but not 7522.
Many IETF protocols allow for this type of RFC mix-and-match
compliance flexibility.

Or does the WG consider this flexibility undesirable?

dbh

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of [e-mail]
> Sent: Saturday, March 27, 2010 1:52 AM
> To: [e-mail]; [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Saturday, March 27, 2010 12:28 AM
> > To: Black, David; [e-mail]
> > 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of
> > > [e-mail]
> > > Sent: Friday, March 26, 2010 11:48 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > > [phone]             FAX: [phone]
> > > [e-mail]        Mobile: [phone]
> > > ----------------------------------------------------
> > >
> > >
> > > _______________________________________________
> > > storm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/storm
> > 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>