Subject: RE: [nfsv4] Re: [issue3] Sessions -- Optional or mandatory

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 12 Apr 2006 06:18:45 -0400

RENEW is a possible addition to the mandatory-to-not-
implement list, although this interacts with the issue 
about the role of implicit renewal.

-----Original Message-----
From: Talpey, Thomas 
Sent: Tuesday, April 11, 2006 10:38 AM
To: [email-masked]
Subject: [nfsv4] Re: [issue3] Sessions -- Optional or mandatory

At 03:29 PM 4/6/2006, Lisa Week \"NFSv4.1 Issue Tracker\" wrote:
>(See minutes at: 
>http://www1.ietf.org/mail-archive/web/nfsv4/current/msg02907.html)
>
>Tom to provide draft text for what is meant when we say Sessions are required. 
>Official adoption will be the acceptance of the text.

Here's my proposal for text and requirements to add to the Draft.
This is not complete but covers the basics, whilst I prepare to put
my spec hat on more tightly. :-) Comments welcome.

-----

In the introduction:

"The Session is a mandatory attribute of any NFSv4.1 client/server
association. Before any file handling operations may be requested of
an NFSv4.1 server, a client MUST successfully create a server-assigned
clientid and sessionid, which MUST then provide the sessionid on each
subsequent operation. The server MUST use the sessionid (and its
associated clientid) to provide required protocol semantics, and MAY use
them to support enhanced operation such as resource management,
idempotent at-most-once recovery semantics, multiple trunked connections,
etc.

-----

In the text:

"For the purposes of satisfying the mandatory Session requirement
of NFSv4.1, the following operations MUST be implemented by both
the client and server:

	CREATESESSION

	CREATECLIENTID

	DESTROYSESSION

	SEQUENCE

The client SHOULD specify appropriate values for the session
parameters, including the persistence, size and number of requests.
The client MUST obey sequence and slot rules for all requests it
sends in each request on the resulting session.

The server SHOULD support a best-effort to satisfy the session
parameters requested by the client, including the persistence,
size and number of requests. The server MUST reply with its
granted values, and MUST implement the sequence, slot and
replay persistence semantics indicated in its response.

The following operations MUST be supported by all NFSv4.1
servers:

	BIND_BACKCHANNEL

	CB_SEQUENCE

The following operations MAY be supported by NFSv4.1 clients,
and MUST be supported by NFSv4.1 wishing to use any semantics
requiring a backchannel, e.g. delegations, directory delegations,
or pNFS:

	BIND_BACKCHANNEL

	CB_SEQUENCE 

	CB_RECALLCREDIT

Finally, the following operations MUST NOT be implemented or required
by both NFSv4.1 clients and servers:

	SETCLIENTID

	SETCLIENTID_CONFIRM

	OPEN_CONFIRM

And the cb_client4 and clientaddr4, etc. are also not used.

-----

A related comment is that the text currently in CB_RECALLCREDIT is
RDMA-specific, but shouldn't be. The goal of the operation is so the
server can rebalance its per-client session resources, without taking
drastic action such as closing the connection. This is not transport
specific, though it may have transport ramifications.

I am thinking we may want to change the name to CB_MAXSLOT or
CB_RECALLSLOT, perhaps...

Tom.

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

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

---

From: Benny Halevy <[email-masked]>
Date: Wed, 12 Apr 2006 14:29:33 +0200

> about the role of implicit renewal.

Hmm, with pNFS the client may not send anything else to the 
MDS but RENEW until LAYOUTCOMMIT or LAYOUTRETURN.

Benny