RE: iSCSI: All text keys MUST be supported?

["Eddy Quicksall" <EQuicksall@mediaone.net>]

Ok, but it would be more general if we could go with 2.9.3 because it would
let us use defaults when new keys are invented but not yet supported.

Actually, if keys are "OPTIONAL to implement" then one would send
<key>=reject if not implemented. So, that would mean that the key could also
be not recognized and one could send <key>=reject (contradicting the
"REQUIRED to recognize).

Given that, why say they are "REQUIRED to recognize"?

Eddy


-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:marjorie_krueger@hp.com]
Sent: Wednesday, June 13, 2001 1:09 PM
To: 'Eddy Quicksall'; julian_satran@il.ibm.com; ips@ece.cmu.edu
Subject: RE: iSCSI: All text keys MUST be supported?


I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize
and answer all text keys specified in the iSCSI protocol document.  Some
features negotiated with these text commands are OPTIONAL to implement."

Julian, is that your intention?  Would you make the wording more explicit?

The further text is implicitly refering to 'proprietary' text keys a vendor
may dream up.

Marj

> -----Original Message-----
> From: Eddy Quicksall [mailto:EQuicksall@mediaone.net]
> Sent: Tuesday, June 12, 2001 10:20 AM
> To: julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject: iSCSI: All text keys MUST be supported?
>
>
>
> Section "2.8.3 Text" says:
>
>     All of these keys, except for the X- extension format,
>     MUST be supported by iSCSI initiators and targets.
>
> But it further says:
>
>    Any other key not understood by the target may be ignored without
>    affecting basic function. If the Text Response does not
> contain a key
>    that was requested, the initiator must assume that the key was not
>    understood by the target or, whenever appropriate, that
> the response
>    was "none".
>
> These two statements seem contradictory (I don't think the
> 2nd is talking
> about only the X keys). I vote for removing the 1st paragraph above
> and going with the 2nd. That way we would not have to insist
> that every
> key be supported ... the requester would just take the default if the
> receiver did not support the key.
>
> Actually, section "2.9.3 Text Response Data"  says:
>
>    If the Text Response does not contain a key that
>    was requested, the initiator must assume that the key was not
>    understood by the target or that the answer is <key>=none.
>
> This seems to backup the 2nd paragraph above.
>
>
>
> Eddy@Quicksall.com
>