Brian E Carpenter <[email protected]> wrote: > Where you want to plug in an ASA (autonomic service agent) is anywhere > you want plug in some intelligence to govern an automatic process. > Intelligence, for example, to figure out what to do if the user side > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > a compromise at /56 and then PD does its thing. But we didn't want > to exclude a scenario where PD isn't available, hence a flag is > included.
To put this is pseudo-(monty)pythonesq:
Customer: Hi, I'd like to buy a parrot.
Store: Would you like a Blue Parrot or a Red Parrot?
Customer: I'd like a Blue Parrot.
Store: I'm sorry, but we don't sell Parrots.
I just don't see the point of the ASA here.
If DHCPv6-PD isn't available, then it's not a compliant ISP connection
(RFC7204) and it's outside of the scope of homenet to begin with.
> About the domain boundary:
>> I don't think that the ISP can trust to have code controlled by end users
>> running in their ACP domain.
> Right. But in ISP-provided CEs this could presumably be fixed, because
> that code would be locked down. In a store-bought CE, isn't this exactly
> where BRSKI will help us? There is certainly an issue for home-made CE
> images, but they will be a tiny minority of users.
No, BRSKI doesn't help the ISP feel safe that the code I am running
on my store-bought CE won't attempt to mess with their network.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
