Re: I-D ACTION:draft-ietf-multi6-app-refer-00.txt

Just two points after a quick read:

In section 3 you refer to centrally assigned ULAs. They
are a *long* way behind locally assigned ULAs in the
publication process, and still quite speculative. Also,
why not discuss locally assigned ULAs? Since they have a
birthday-paradox type of risk of ambiguity, they could
be "interesting" if used in referrals, and will likely
never have reverse DNS entries. (But that's another WG's
problem.)

In section 4 you say

>    ...it also
>    requires a mechanism by which the application can pass that
>    information to the protocol stack so that the multi6 protocol layer
>    has all the alternate locators available when establishing
>    communication.  Thus we need to study the implications of a
>    setpeerlocators() type of API.

If we use HBAs, wouldn't that simply mean passing a CGA Parameter
Data Structure as the (opaque) referral object? But of course you
can only pass that to a peer that understands it... How do you
find out if the peer is multi6-capable?

    Brian