Re: proposed text for charter

[Thomas Narten <narten@us.ibm.com>]

Hi  Jari.

> >what does "as long as the IP Address are available" mean? Is this
> >trying to say anything other than "if packets can still be sent from A
> >to B (using whatever addresses happen to work) referrals will also
> >work"? Or is there some other subtle restriction here?
> >  
> >
> Yes. The "addresses are available" part has to do with what
> has been envisioned as the solution in MULTI6. If you use
> real IP addresses as your ULIDs then we minimize changes
> to applications and make it possible to have referrals.


What is a "real address"? A globally unique, PA address?

> However, the drawback of this approach is that if one such address
> (set) is stored and later retrieved by an application, that address
> still has to work (or one address from the set) or otherwise you
> can't continue, because you have no way of asking the peer what his
> new address is.

I assume that the fundmantal aspect is that the ULID has to be
mappable into the address used in the (eventual) outer IPv6 header. So
"real address" must have to do with assumptions about how that mapping
can be made to work (e.g., one of the addresses in the original set
can still be used for connectivity with the peer)?

> (Note that the value of this item in the charter may also not
> be immediately obvious. Why are we saying that referrals
> work without application changes? Isn't that a detail?

I don't think this is a detail. Ensuring that referrals work is a key
aspect of "transparent to higher layers", IMO.

> The answer is that this particular choice of requirement
> happens to dictate to some extent what kind of solution
> is needed. For instance, if this were not a requirement
> then identifiers would probably look more like HITs than
> HBAs/CGAs. Of course the choice of the particular requirement
> set is a tradeoff -- some NAT/IPv4 things would probably be
> easier if this were not a requirement.)

Yes, thanks.

Thomas