RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands

On Mon, 2 Feb 2004 pat_thaler@agilent.com wrote:

> Ken,
>

> Good point. I had missed that the DataIn and R2T are one SNACK type.
> Changing that would affect current implementations even if they don't do
> bidirectional. While I don't like the one variable, two names thing,
> changing it isn't worth that turmoil.
>
> Given that, I think we need to keep target DataSN and R2TSN as one
> sequence for bidirectional.

Not necessarily. We could add a new SNACK type for BiDi commands, say for
R2Ts for a BiDi. If we make the new type used only for BiDi commands, we
do not impact implementations that do not handle BiDi commands (for which
there is no such ambiguity).

This would, though, impact existing implementations that do support BiDi
commands. I'm not sure if we want to be that tramatic.

> There is another way to clean things up which is editorially
> significantly more radical but which should be less tramatic for
> implementations.

This option also would work.

> DataSN (for DataIn PDUs) and R2TSN are really two names for one counter
> variable -
> Write only commands use the counter for R2T PDUs and call it R2TSN
> Read only commands use the counter for DataIn PDUs and call it DataInSN
> Bidirectional commands use the counter for both kinds of PDUs and both
> names are applied to it depending on the PDU type.
>
> The obvious way to clean this up is to give the SNs generated for DataIn
> and R2T PDUs a single name such as:
> DataR2TSN
> DRSN
> or even just the current DataSN
> The justification for DataSN is that both R2T and DataIn are concerned
> with the movement of data. (See also iSER which classifies both PDUs as
> iSCSI data type PDUs.) Keeping this name would minimize the amount of
> editorial change.
>
> I know this editorial change would have to be carefully made (there are
> 35 instances of R2TSN in the draft most of which would be pretty
> straight forward to convert), but in the long run that is probably
> significantly less effort than we will expend explaining to people that
> DataSN and R2TSN form one sequence.

Indeed. If we decide to keep it one sequence, we should do something like
this.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips