Subject: [nfsv4] typos, corrections, and channel negotiation fixes to NFSv4.1 documents

From: "Mike Eisler" <[email-masked]>
Date: Sun, 5 Apr 2009 14:00:58 -0700 (PDT)

I have collected the typos and other errors that various people have
reported and made edits. The results are in:
  http://eisler.com/nfsv41/

Most of these were simple fixes to typos. Some are minor re-wording.

However in http://linux-nfs.org/pipermail/nfsv4/2009-March/010161.html
(another email list, not [email-masked]) there was a discussion about
whether the NFS server can/should be allowed to change certain
parameters for the backchannel.

I propose that generally the server can lower any fore channel and
backchannel parameter in the reply to CREATE_SESSION, and generally
cannot raise any parameter, with following
exceptions:

- ca_maxoperations - the server can set this to any value it wants for the
fore channel. It cannot change the value the client wants for the
backchannel.

- ca_maxrequests. Ditto.

The diffs in the above link show this.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Benny Halevy <[email-masked]>
Date: Mon, 06 Apr 2009 00:08:54 +0300

> fore channel. It cannot change the value the client wants for the

Why can't the server lower it for the backchannel?
It seems like this could help the client save resources.

> - ca_maxrequests. Ditto.

Ditto.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Sun, 5 Apr 2009 15:50:26 -0700 (PDT)

> It seems like this could help the client save resources.

As in deleting a few pointers from an array?

> Ditto.

The server can't really predict how many slots it will need on the
backchannel since it cannot predict how many layouts, delegations,
etc. the client will acquire.

The client is free to detect that the server doesn't need more slots,
and take them away. It is also free to add more slots.

In hindsight, given the dynamic slot table in the session's channels,
allowing slot and ops counts to be negotiated was
a mistake. I'm not proposing we fix that mistake ... no .x file changes.

I was hoping this would not be controversial.
I'm already getting complaints from the co-chair. So I'm
happy to:

- leave it as it was in -29.  The problem is
  that CREATE_SESSION like "The replier should reply" is being interpreted
  as: "for the backchannel the client should request".
  We can muddle through with
  text that is incomprehensible I suppose. Every vendor comes to
  connectathons and bake-a-thons so we'll make everything good
  there. There's no way that can't fail. :-)

  Seriously though, there is room for wide interpretation of the current
  text. We can end up to slot tables on both channels of zero
  length. Once the tables go tozero, they cannot be expanded,
  because there's no slot to send SEQUENCE to CB_SEQUENCE too.
  Simply cleaning it up doesn't suffice; a decision to
  needs to be explicitly made about that the server can do, in
  a way that does not break clients.

- go with a consistent policy that the server cannot raise any value,
  and can lower any value, regardless of channel.
  If the client wants a slot table of zero entries on the fore channel
  on the session, and zero length COMPOUND requests, so be it. Ditto
  the server for the backchannel. The difference between this and the above
  is meaningless.

- as above except that the server can raise ca_maxoperations and
  ca_maxrequests on the fore channel. Well, at least we get a fore
  channel to work. Pity about the back channel.

- as proposed, the client and server decide their slot table and
  max ops sizes, period. A bad server can ruin the fore channel,
  and a bad client can ruin the backchannel, but the converses
  cannot happen.

I believe my proposal is the least risk.

---

From: Spencer Shepler <[email-masked]>
Date: Sun, 5 Apr 2009 19:07:20 -0500

On Apr 5, 2009, at 5:50 PM, Mike Eisler wrote:

>>> - ca_maxoperations - the server can set this to any value it wants  
>>> for
>>> the

To be clear, my comments were two-fold.  The first is to express
that it is unfortunate that we have changes to make at this point.
I am realistic enough to know that they will occur and the
optimistic side of me was hoping that we could get through
without last minute modifications.  If there is support of
Mike's suggested changes, that is fine with me.

The second reason I commented is the more important one.
I would prefer that implementation/interpretation discussions
happen on this alias such that we can build knowledge
and consensus once.

So, please, bring questions, concerns, etc. to this alias
so that the NFSv4 community can work through the issues
and we have one place initially that the discussion is
captured and then we can work the issues into the appropriate
documents.  Again, I do realize that not all discussions will
happen where I would like them to.

Spencer

---

From: Benny Halevy <[email-masked]>
Date: Mon, 06 Apr 2009 03:19:36 +0300

> happen where I would like them to.

I agree completely.  In fact I intended to Cc this alias
but my email client out smarted me when auto-completing
"nfsv4" to "[email-masked]" rather than "[email-masked]".

Benny

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

---

From: Benny Halevy <[email-masked]>
Date: Mon, 06 Apr 2009 03:23:27 +0300

> and take them away. It is also free to add more slots.

Fair enough.

> a mistake. I'm not proposing we fix that mistake ... no .x file changes.

Yeah, not at this stage.

> I believe my proposal is the least risk.

I'm OK with it.
I was just trying to understand the reason behind your proposal.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 7 Apr 2009 14:53:43 -0700 (PDT)

http://eisler.com/nfsv41/ has changes for PAv2:

- I introduced some typos to the fixed to CREATE_SESSION
- One experienced NFS implementer had trouble understanding the
  handing of the highest_slot and target highest_slot.

I plan on proposing PAv3 today or tomorrow to address a
security hole in the SSV.