[AFS3-std] Re: XCB union decoding & IPvN address Conversation

[Jeffrey Hutzelman]

--On Saturday, February 12, 2011 04:42:04 PM -0500 Jason Edgecombe 
<jason@rampaginggeek.com> wrote:

> On 02/12/2011 03:28 PM, Andrew Deason wrote:
>> On Sat, 12 Feb 2011 09:15:59 -0500
>> Jason Edgecombe<jason@rampaginggeek.com>  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