Re: [storm] iSCSI SAM update: login key

It was just cosmetics. Anyhow with error recovery level really meant  
level. I wonder if with protocol we want every level to include all  
the preceding levels (including some obsolition) - in which case level  
is appropriate or merely a combination of things in which case I would  
suggest bundle. Also if it level the negotiation is numeric while for  
a combination it is boolean.

Regards,
Julo

On 30/03/2010, at 04:59, <Black_David@emc.com> wrote:

> <WG co-chair hat OFF>
>
> We already have ErrorRecoveryLevel, so I don't see a problem with a
> second key that ends in "Level".
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
>> Sent: Monday, March 29, 2010 8:15 PM
>> To: 'Julian Satran'; Black, David
>> Cc: storm@ietf.org
>> Subject: RE: [storm] iSCSI SAM update: login key
>>
>> OK, I then suggest iSCSIProtocolTier
>>
>> I would be OK with iSCSIProtocolLevel as well.
>>
>> Glad to see the consensus, thanks.
>>
>> Mallikarjun
>>
>>> -----Original Message-----
>>> From: Julian Satran [mailto:julian.satran@gmail.com]
>>> Sent: Friday, March 26, 2010 11:57 PM
>>> To: Black_David@emc.com
>>> Cc: cbm@chadalapaka.com; storm@ietf.org
>>> Subject: Re: [storm] iSCSI SAM update: login key
>>>
>>>  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, Black_David@emc.com 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: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
>>>> _______________________________________________
>>>> storm mailing list
>>>> storm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/storm
>>
>>
>
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm