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

[Benjamin Kaduk]

On Mon, 29 Apr 2013, Andrew Deason wrote:

> On Fri, 26 Apr 2013 14:43:09 -0400 (EDT)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>>>>>>       typedef opaque RXGK_Data<>;
>>>>> [ ... ]
>>>>>>           RXGK_Data token;
> [...]
>>>> If we were to explicitly limit the size of a token (or a generic
>>>> RXGK_Data, I suppose), what would such a limit be?  If we start
>>>> talking about X.509 identities, maybe 16k is too small?
>>>
>>> Some care is called for here.  We've had issues in the past with
>>> limits on token sizes, so we should try to avoid setting one that is
>>> too small.
>>>
>>> I think perhaps the right thing here might be to say that the limit
>>> is implementation-defined (or subject to local policy), but MUST NOT
>>> be less than a certain value.
>>
>> I could see doing something like that.
>
> So, does this mean each rxgk-using application gets its own slightly
> different RPC-L? To make it easier, of course at least define a constant
> for all of these and just have the application define it. Unless we're
> talking about just not putting limits in the RPC-L, and having the XDR
> decoder enforce these limits a different way.

The RPC-L in OpenAFS will differ from that in the document regardless, as 
we will use the afs_[u]intNN types instead of int/hyper/etc.
It does not seem a big deal to also change an array limit.

> I would say just use a limit of 100M or something and forget about it,
> but if this can somehow work well with specifying this per-application,
> then sure.

The above notwithstanding, I don't really see a problem with just using 
100M, either.

-Ben