--On Saturday, February 12, 2011 04:42:04 PM -0500 Jason Edgecombe
<[email protected]> wrote:
On 02/12/2011 03:28 PM, Andrew Deason wrote:
On Sat, 12 Feb 2011 09:15:59 -0500
Jason Edgecombe<[email protected]> wrote:
I got a little confused. Was the IPvN address conversation put on
hold because the encoding needs to be worked out first? If so, I'm
assuming that the IPvN address discussion will be revisited when the
encoding is resolved. Is that correct?
How are they different conversations? Discussing how we encode IPvN
addresses on the wire is always what we were trying to solve. The latest
discussions suggest putting them in a new primitive type (an 'extensible
union' or whatever you want to call it). As far as I can tell, there are
no more loose ends with the design of such a structure, and a draft
could be written now.
I'd write it myself if I didn't think Derrick was going to do it (and if
I were better that writing these kinds of things).
We switched from "what to store" (address+port?) to "how to store it"
(encoding and decoding).
Actually, not. We started with "how to store it", because Derrick's ubik
update draft proposed a wire protocol based on struct sockaddr_storage,
which clearly can't work. Interestingly, his next proposal was one that
represented only addresses, whereas struct sockaddr also includes ports.
I'm not sure whether it was Derrick's original intent to include ports, nor
am I sure it was his intent to drop them in the next iteration.
The remainder of the discussion has been almost entirely about
representation, though the what-to-store question has come up briefly once
or twice. I think we mostly have consensus that a new type should be about
addresses, and not something more complete, but I could be misreading -- I
have a fairly strong opinion on that particular question. I do not think
we have discussed the question of whether Ubik's UpdateInterfaceAddr()
needs ports.
To be honest, I remain unconvinced that an IPv6-aware version of this RPC
continues to be the best way to insure that all servers have compatible
configuration. However, it _is_ necessary for Ubik servers to be able to
discover the actual addresses at which their peers are reachable, and for
that purpose, an analogous-but-IPv6-capable RPC is needed, and it certainly
does need port information.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
