Re: [nfsv4] channel attribute negotiation

On Sat, October 9, 2010 7:52 am, J. Bruce Fields wrote:
> 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".

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

> 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.

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.
>
> 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.
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>

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