On 30/03/2017 09:16, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> 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.
No, it's not really Pythonesque but negotiation is allowed to fail. > I just don't see the point of the ASA here. There's already a thing called an HNCP agent. Why couldn't it be enhanced to negotiate with an upstream ASA for resources? > 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. No disagreement; the idea was simply to ensure that the GRASP objective can communicate that PD is or isn't available. If PD is required in a particular scenario then that parameter will always be set True. > > 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. Yes, I see that. (Unless of course we get into much more complex validation and authorization stuff, which seems unlikely to fly.) Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
