Subject: [nfsv4] channel attribute negotiation

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 9 Oct 2010 10:52:20 -0400

I noticed a couple small typos as I was reading the discussion of
channel attribute negotiation in 5661 section 18.36.3:

	- The heading of the dicussion should be
	  "csa_fore_chan_attrs, csa_back_chan_attrs:"
	  not
	  "csa_fore_chan_attrs, csa_fore_chan_attrs:"
	- "with more operations than ca_maxoperations" should be "with
	  more operations than the negotiatiated maximum".

Some clarification in the case of ca_maxoperations might be useful: is
the client expted to send a hopeful value (hey, let me send you
thousands of ops!) or the minimum value that it needs to function (e.g.
number of operations it requires to send its open compound)?  The linux
client currently does the latter.

The latter seems the more important number to communicate, so perhaps we
should advise clients to send their required minimum, and servers to
decrease the client-proivded number only with the understanding that
this may prevent the client from continuing.

I suppose it's not a terribly important question until we expect clients
to be capable of optimization or slection of optional features based on
the number of ops available.

--b.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 11 Oct 2010 06:18:12 -0700

> 	  more operations than the negotiatiated maximum".

Please report these as errata to ensure that RFC5661-bis corrects these.

> this may prevent the client from continuing.

Sure but in a client insists it needs one million ops per request, this is
a meaningless distinction.

What we get when the session is created is an unambiguous agreement about
what can be supported on each channel. I'm open to ideas about how we
could do better.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 11 Oct 2010 11:15:55 -0400

> Please report these as errata to ensure that RFC5661-bis corrects these.

OK, done.

> a meaningless distinction.

Yeah, to make the question interesting you'd have to imagine a client
that, say, needed 8 ops per compound to function, but could take
advantage of a few optimizations if it got 16.  And a server
implementation which cared much how many it gave up.

> what can be supported on each channel. I'm open to ideas about how we

Fair enough.  Thinking about it some more, there may be a little
ambiguity here, but probably nothing worth worrying about.

--b.