[AFS3-std] AFS-3 XDR discriminated union primitive type I-D

[Tom Keiser]

On Tue, Apr 12, 2011 at 12:02 PM, Matt W. Benjamin <matt@linuxbox.com> wrot=
e:
> Hi All,
>
> I'd like to see us push another step forward on this.
>
> My understanding is that to date, only two substantive issues have been r=
aised with the document as published.
>
> The first is whether the proposed 'afs-union' (and also the hypothetical =
afs-union64) are in the correct namespace. =A0Tom's document refers to Rx a=
s afs3-rx, which appears justified, but was not commented on directly. =A0T=
here appeared to be agreement after discussion that the proposed type eithe=
r should remain afs-union, or alternatively be put in an rx token namespace=
 (rx-union? rx-(some other qualifier)-union?).
>

Hi Matt,

I have a modification (undergoing SNA-internal peer review) to the
document that renames the union type to "rx-union".  However, I must
agree with Jeff Altman that this is potentially concerning, i.e.,
it--to some degree--creates a layering violation (in that it tightly
couples AFS-3 to Rx).  On the other hand, I'm quite reticent to
propose updating RFC 4506 to the NFSv4 working group, as that is
likely to require considerable time and effort.  Additionally, IMHO,
this is merely a coupling at the namespace level: nothing precludes us
from adding rx-union XDR routines to any arbitrary RPC framework.

> Second, Tom, your response to Simon's comments of March 7 (included below=
) indicates there will be a revision simplifying the union type, but asking=
 for further input on the need for very large unions, on which there was no=
 follow up. =A0I have the sense that silence indicates that at least no one=
 has -immediate- use for the afs-union64 type, but perhaps you yourself do?
>

I raised this issue mainly to ascertain whether anyone else could
foresee a use case in the near-term (since it would be easier to
specify both primitives in one I-D).  I've not heard of any immediate
need, so I'm dropping the afs-union64 issue.

Cheers,

-Tom