[AFS3-std] Last Call: afs3-rxgk-04, afs3-rxgk-afs-02

[Benjamin Kaduk]

On Fri, 26 Apr 2013, Benjamin Kaduk wrote:

> On Thu, 25 Apr 2013, Simon Wilkinson wrote:
>
>> Same question here - RXGK_Data has no limits.
>
> But what would the limit be?
> I suppose I can mention my commit message for when I went and put in length 
> restrictions:
> %%%%%%%%%%%%%%
>    Supply bounds for variable-length arrays
>
>    Define constants and use them.
>
>    There is no limit for the RXGK_Data typedef at this time, though that
>    is perhaps the most important case to consider.  Such a limit should
>    probably be merged in with a prospective limit on the generic OpenAFS
>    rx_opaque type.
>
>    The authenticator limit implicitly limits the appdata and call_numbers
>    fields, so separate limits are not needed there.
> %%%%%%%%%%%%%%
>
> It is tempting to say that we need not talk about a global limit for this 
> document and can move such discussion to the thread Andrew started 
> ("Unlimited array lengths").  I suppose I can look if there is literature on 
> the size of GSS negotiation tokens for guidance.

A couple of data points: the RPCSEC_GSS spec (used for NFS) specifies an 
opaque gss_token<> with no limit, and my examination of the FreeBSD and 
linux NFS kernel sources did not find particular limits on most variable 
length arrays.  I don't think there's strong precedent for any particular 
limit.

After reflection, I think that if we are to say anything about the limit 
for the general RXGK_Data type (and similar), leaving flexibility for the 
application as in Jeff's suggestion is the best option.  This would 
involve some customization of RPC-L for each application, but that doesn't 
seem like a big issue.

I do feel like a generic solution (e.g., in rxgen, but still 
application-specific) will be appropriate, and would supercede anything 
specific here.

-Ben