Subject: Re: [storm] iSCSI SAM update: login key

From: "David Harrington" <[email-masked]>
Date: Sun, 11 Apr 2010 10:52:37 -0400

<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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Saturday, March 27, 2010 1:52 AM
> To: [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Saturday, March 27, 2010 12:28 AM
> > To: Black, David; [email-masked]
> > 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: [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).
> > >
> > > 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
> > > ----------------------------------------------------
> > >
> > >
> > > _______________________________________________
> > > storm mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/storm
> > 
> 
> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm
>

---

From: "Mallikarjun Chadalapaka" <[email-masked]>
Date: Sun, 18 Apr 2010 19:30:38 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: Sunday, April 11, 2010 7:53 AM
> To: [email-masked]

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 19:34:07 -0400

<WG chair hat off>

I concur with Mallikarjun, as this is not about individual feature
negotiation - iSCSI has lots of text keys to negotiate individual
features, and it's straightforward to add more - see the iSCSI
Login/Text Keys Registry here:
http://www.iana.org/assignments/iscsi-parameters .

Rather, this is about putting in some low level changes in iSCSI (as a
SCSI transport) to match changes in SCSI architecture and functionality
since iSCSI was first defined.  The established practice in SCSI is to
use a single version descriptor value to report this sort of
functionality (see Annex D.8 in the current working draft of SPC-4).

Overall, I think "Level" is consistent with what this key is
negotiating, in large part because in iSCSI, separate "(independent)
features" ought to be handled by separate (independent) keys, for which
there are plenty of existing examples.  In Dave Harrington's example,
the (IMHO) right approach would be to define three text keys, one for
each of RFCs 7501, 7522, and 7599 ... using meaningful key names rather
than RFC numbers ;-).

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mallikarjun Chadalapaka
> Sent: Sunday, April 18, 2010 10:31 PM
> To: 'David Harrington'; [email-masked]