Re: [storm] iSCSI SAM update: login key

["Mallikarjun Chadalapaka" <[e-mail]>]

Hi David,

I would guess that the iSCSI-equivalent of the bit string approach would be
a comma-separated list of RFC numbers exchanged as text key values during
the login dialog.

Personally, I guess I do not see the need for the flexibility to pick and
choose RFCs out of order.  My first reaction was that doing so might not
always be workable anyways if the later RFCs implicitly or explicitly use
the concepts or terminology defined in one of the earlier RFCs.  But I guess
other protocols obviously must have addressed this issue.

I agree with you though that "Level" has the "everything earlier is
supported" connotation, and should we choose to make this a non-requirement
(although I am comfortable with the current approach), we need to rename the
key.

Mallikarjun


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> David Harrington
> Sent: Sunday, April 11, 2010 7:53 AM
> To: [e-mail]
> Subject: Re: [storm] iSCSI SAM update: login key
> 
> <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
> >
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm