Re: [storm] iSCSI SAM update: login key

[Julian Satran <[e-mail]>]

  I would suggest gen instead of level (level has too much of a value 
connotation - at least it my part of the world :-))

Julo


On 27/03/10 08:52, [e-mail] wrote:
> 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