Subject: Re: [nfsv4] Issue with SETCLIENTID ?

From: Spencer Shepler <[email-masked]>
Date: Fri, 9 Apr 2004 19:29:58 -0500

On Mar 4, 2004, at 2:07 PM, Fredric Isaman wrote:

> Assuming I am reading the RFC correctly, I see a problem with 
> SETCLIENTID.
>
> Using the RFC's notation, if a client sends
>
> SETCLIENTID{v,x,k} = {c,s}
> SETCLIENTIDCONFIRM{c,s}
> SETCLIENTID{v,x,l} = {c,t}
> client crashes and loses {c,t} values
>
> Now confirmed and unconfirmed lists on the server are such that a
> SETCLIENTID{u,x,l} with u!=v will not meet ANY condition in the
> implementation on page 210 of RFC 3530.  (The CITI server handles
> this by returning NFS4ERR_INVAL.)

I didn't see a response to this so....

It is covered later in the same section at the bottom of page 212.
In this paragraph:

    o  The server has previously recorded a confirmed { u, x, c, l, s }
       record such that v != u, l may or may not equal k, and recorded an
       unconfirmed { w, x, d, m, t } record such that c != d, t != s, m
       may or may not equal k, m may or may not equal l, and k may or may
       not equal l. Whether w == v or w != v makes no difference.  The
       server simply removes the unconfirmed { w, x, d, m, t } record and
       replaces it with an unconfirmed { v, x, e, k, r } record, such
       that e != d, e != c, r != t, r != s.

       The server returns { e, r }.

       The server awaits confirmation of { e, k } via
       SETCLIENTID_CONFIRM { e, r }.

---
So the unconfirmed record is removed and a new response is provided
to the client and it needs to confirm it.

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Fredric Isaman <[email-masked]>
Date: Mon, 12 Apr 2004 10:13:44 -0400 (EDT)

The problem I was pointing out is that it is NOT covered by the quoted
passage, because of the explicit c!=d condition.  I agree that the most
reasonable response is to allow the possibility that c==d.

		Fred

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Apr 2004 14:22:19 -0500

> reasonable response is to allow the possibility that c==d.

So let's recap, the values v,x,k are supplied by the client and the c,s 
values
are returned by the server.  It is not possible for the crashed
client to choose values for c/d and therefore, this should not be an 
issue for the client.
The way I interpret the quoted text previously supplied is that the 
server should
take care in not returning the same value for SETCLIENTID4resok.clientid
for the 3rd SETCLIENTID in this scenario as it did for the 2nd response.

If the server were to return the same values, then the client or server 
may get
confused about what has been confirmed up receipt of 
SETCLIENTID_CONFIRM.

---

From: Fredric Isaman <[email-masked]>
Date: Mon, 12 Apr 2004 16:02:06 -0400 (EDT)

> client to choose values for c/d and therefore, this should not be an

But there IS a situation where the client can 'choose' the c/d value. The
second bulleted section that starts with "The server checks if it has
recorded a confirmed record for { v, x, c, l, s }, where l may or may not
equal k." allows the client to 'choose' a value equal to the one already
confirmed.

The following sequence sets up a situation where the server's confirmed
and unconfirmed lists almost match with the fourth bulleted section,
except for the c!=d condition contained in it.

SETCLIENTID{u,x,l} = {c,s}
SETCLIENTIDCONFIRM{c,s}
SETCLIENTID{u,x,k} = {c,t}  <- here the client in effect 'chose' c
now the server has a confirmed {u,x,c,l,s} and an unconfirmed {u,x,c,k,t}

SETCLIENTID{v,x,k}

Here I agree that the {v,x,k} supplied by the client should be handled
according to the fourth bulleted section which was quoted, and I agree
with your interpretation of the text.  My point is that the text as
given does not allow this case to be used because of the c!=d condition.

	Fred

> server should take care in not returning the same value for
> SETCLIENTID4resok.clientid for the 3rd SETCLIENTID in this scenario as
> it did for the 2nd response.
>
> If the server were to return the same values, then the client or
> server may get confused about what has been confirmed up receipt of
> SETCLIENTID_CONFIRM.
>
>

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Apr 2004 15:21:58 -0500

> given does not allow this case to be used because of the c!=d 

Sorry for missing the subtlety of the scenario.  Yes, the text is wrong
and an appropriate errata should be constructed for it.

Spencer