Sam Hartman wrote: > Those two problems are not sufficient to interest me. If all I got were > solutions to those, I would not be able to meet my customer > requirements.
I'm presuming that they're part of the solution. If so, what *else* is required? > It's going to be a bit before we get back to the problem statement because we > need to focus > on the base specs and because at least within the Moonshot context we > need to flesh out our solution more. I'd like a clear problem statement. From what I've seen of your requirements, you want the ability to have multiple "groups". What you call communities of interest. i.e. a realm is tied to a specific home AAA server. But that realm can exist in different contexts, and have different routing properties. e.g. foo.edu belongs to eduraom, but ALSO has a commercial agreement with a roaming provider. It wants to inject different routes into those two different routing fabrics. If that's true, then the first points you raised are only steps 1 and 2 of the solution. Step 3 would be to have a registrar which would coordinate group membership. I think the confusion for me is that I don't see why additional complexity is needed. Roaming operators already do roaming by realm, in a particular context. e.g. "example.com gets routed through the wireless broadband alliance" For me, it looks like step (3) is widely deployed. That's why I'm interested in talkiing about steps (1) and (2). Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
