Re: iSCSI: invalid key value

[Luben Tuikov <luben@splentec.com>]

I agree with Paul.

But wouldn't a straightforward implementation
suggest the answer...?

Separate the value in tokens with comma as
the delimiter and then get the union of ``your''
tokens for that key's value(s) and the ones you
extracted the from other end.

Then you select the one most favourable to you,
and either suggest it to the sender or
``state'' it to the sender -- that that's 
what you'll use.

Thus,
 "CRC32C,none" UNION "$#CRC32C,none" = "none".

So, nothing needs to be added to iSCSI regarding
this matter.

-- 
-l


"LEMAY,KEVIN (A-Roseville,ex1)" wrote:
> 
> I think that your interpretation is more extendable and probably better in
> the long run. The point is, that it is an interpretation and an area that
> the iSCSI spec does not address.
> 
> We need to have Julian add language to the spec to clarify the operation. I
> understand what you are trying to accomplish.
> 
> But, on the other hand, I am not changing my code until the spec is changed
> to say what the correct behavior is....
> 
> Kevin Lemay
> Agilent Technologies
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, January 25, 2002 9:05 AM
> To: LEMAY,KEVIN (A-Roseville,ex1)
> Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com
> Subject: Re: iSCSI: invalid key value
> 
> "LEMAY,KEVIN (A-Roseville,ex1)" wrote:
> >
> > This is an area that is open to interpretation in the spec.
> >
> > My interpretation is:
> >
> > Any parameter defined in appendix D can only have the values represented
> in
> > the appendix. To offer any thing not defined in the spec for these well
> > defined parameters is a format error. The first option offered is an
> invalid
> > one, thus a format error has occurred.
> 
> This makes the iSCSI draft non-extensible through other drafts.
> There are a lot of value-added things that can be done, either
> by other drafts/RFCs adding new methods to iSCSI, or through
> vendor-specific methods.  The iSCSI revision number has little
> to do with text keys; it is primarily a PDU format version
> number.  If we have to change the base iSCSI spec and version
> every thing a new authentication method is made available,
> for example, we will be turning out too many big RFCs.  Better
> to have a good, extensible "base" iSCSI protocol, and add
> new authentication or digest methods through separate RFCs.
> 
> Otherwise, we would have done better to keep the login exchange
> as a set of binary keys and values, instead of text.
> 
> >
> > If newer options are added to the spec, then they would be defined for
> that
> > revision and see no problem. The values offered must be consistent with
> the
> > version number sent in the login request. If new key values are added to a
> > spec and the initiator supports a range of versions. Only key pairs and
> > values common to the requests versions should be offered. If this is not
> > true, then the spec needs to be updated to make it clear that not
> understood
> > key values should be passed over and only rejected if no valid option
> > exists.
> 
> I disagree.  This makes it too difficult to add new methods to
> the iSCSI protocol.  A new PDU format revision should not be
> necessary to add an authentication method.
> 
> > The spec is clear on the behavior when a format error occurs. A target
> > should reject the login and close the connection.
> >
> > On further review, NotUnderStood is not the correct response. The correct
> > response would be: "DataDigest=Reject"
> 
> This response should be sent only if NONE of the offered methods
> are supported.  If any method offered is recognized and supported,
> that method will be returned by the target.
> 
> --
> Mark
> 
> > Kevin Lemay
> > Agilent Technologies
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Friday, January 25, 2002 8:28 AM
> > To: kevin_lemay@agilent.com
> > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com
> > Subject: Re: iSCSI: invalid key value
> >
> > Kevin-
> >
> > How can this be rejected, if at least one of the values
> > is understood and supported?  One of the original reasons
> > to negotiate digest methods, authentication methods, and
> > such is so newer methods can be added to iSCSI as they
> > become available.  If I have an initiator that sends:
> >
> > DataDigest=LatestGreatestDigest,CRC32C,none
> >
> > and a target that supports CRC32C, it should pick CRC32C,
> > rather than sending back a notunderstood.  This way, the
> > initiator can say what it wants, and the target can pick
> > from the set of methods it supports.
> >
> > If we let the target reject these, we will degenerate
> > iSCSI login into a "try this, nope, try that, nope, then
> > let's try this" sort of negotiation:
> >
> > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none
> >
> > T->I reject
> >
> > I->T DataDigest=NextBestThing,CRC32C,none
> >
> > T->I reject
> >
> > I->T DataDigest=CRC32C,none
> >
> > T->I DataDigest=CRC32C
> >
> > The initiator had to guess at which value the target didn't
> > like, then keep trying to log in with different sets of
> > methods until they were reduced to the subset known by the
> > target.  This would default the purpose of having a relatively
> > simple negotiation for these things.
> >
> > Steve is right, the only good way to do this is to accept
> > the value that's understood, even if it's "none", rejecting
> > only if none of the values are understood.  If the initiator
> > didn't want "none", it shouldn't have offered.
> >
> > BTW, if "CRC32C" is corrupted into "#$C32C", we will have
> > much worse problems than text key corruption, and trying
> > to get around it this way will not work.
> >
> > --
> > Mark
> >
> > kevin_lemay@agilent.com wrote:
> > >
> > > I disagree,
> > >
> > > This is an initiator error and the login should be rejected as such.
> > > NotUnderStood should be returned in the key with the login rejected.
> > >
> > > Kevin Lemay
> > > Agilent Technologies
> > >
> > > -----Original Message-----
> > > From: Steve Senum [mailto:ssenum@cisco.com]
> > > Sent: Friday, January 25, 2002 7:57 AM
> > > To: ietf-ips
> > > Cc: Eddy Quicksall
> > > Subject: Re: iSCSI: invalid key value
> > >
> > > Eddy,
> > >
> > > If someone sends me "DataDigest=#$C32C,none".
> > > I will respond "DataDigest=none".
> > >
> > > I think responding with "DataDigest=NotUnderstoood"
> > > or one of the other special responses would be wrong,
> > > as there is nothing wrong with the key ("DataDigest").
> > >
> > > Since I support "none", and can't tell "#$C32C"
> > > is really "CRC32C", I believe "DataDigest=none"
> > > is the only correct response.
> > >
> > > Steve Senum
> > >
> > > -----------------------------------------
> > > Subject: iSCSI: invalid key value
> > >    Date: Fri, 25 Jan 2002 10:17:12 -0500
> > >    From: Eddy Quicksall <Eddy_Quicksall@ivivity.com>
> > >      To: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
> > >
> > > If a key has a value that is not valid, do you know how I respond?
> > >
> > >
> > >
> > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none.
> > >
> > >
> > >
> > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not
> > > understood?
> > >
> > >
> > >
> > > If I say DataDigest=Reject, that would mean I don't support the key for
> > the
> > > current initiator.
> > >
> > >
> > >
> > > If I say DataDigest=Irrelevant, that would mean the digest is not
> relevant
> > > for
> > > the current negotiation.
> > >
> > >
> > >
> > > If I say DataDigest=none, that would mean I don't support CRC32C when in
> > > reality
> > > I do. It could be that, since there is no digest in login,
> > > the 1st two letters got changed.
> > >
> > >
> > >
> > > If I treat it as a protocol error and send a response with status ==
> 0200
> > or
> > > 0201, then the initiator does not know why.
> > >
> > >
> > >
> > > Eddy
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.