On 1/14/2015 2:01 AM, Eggert, Lars wrote: > FWIW, this is very close to how I break down the architecture in my head, and I agree with Ted that if we are opening the door to restructure the areas, we might as well be a bit more radical. This could be interesting... As a list, the wording style is creative and maybe fun, but I'm not clear how to apply each of these bullets in practical terms. So let's pursue this a bit deeper, for better understanding and possibly to facilitate its application: >> The bit that works on how to determine what path flows use to get from one part of the network to another >> The bit that works on how network elements behave How does this differ from the one before? Besides 'what path flows use', what other aspects of 'behave' are intended to be contained in this? >> The bit that works on how network operators work. They work highly variable hours, often with wakeup emergencies in the middle of the night. Oh? That's not what this bullet means? Seriously, what is the practical scope of this? There's probably an existing description somewhere that can be pointed to? >> The bit that works to protect the networks or flows from attackers This is probably meant to cover basic object encryption that is independent of networks and flows, but its phrasing might only mean channel-based protection, especially since the IETF often focuses on TLS to the exclusion of object-based methods. Please clarify. >> The bit that works on node configuration and bootstrapping Should this include application initialization, too? Might be useful to aggregate that set of issues into the same place. By the way, as we use our concern for pervasive monitoring and compromised infrastructure, we might want to make it easier to have most configuration info come from someone other than the local access provider. >> The bit that works on how to run the network on different kinds of links This sounds quite interesting, but I don't understand it. Please clarify what sorts of issues there are here, beyond different link-level device drivers. >> The bit that works on how the flows behave on the network to each other Second reference to flows, with maybe bullet two implying a third. I don't understand why this is separated from the first (and maybe second.) Please clarify. >> The bit that works on how applications create flows and what those flows' exchanges should be. This is the only reference to applications and it's only in reference to the interface to a flows mechanism. That's can't possibly be the only applications-related IETF work. (And of course, it isn't.) d/ ps. Ted's note to Jari, on Boxing Day (12/26) raises a number of substantive concerns about what I will call the incompleteness of the IESG's proposal. He offers some very basic questions that strike me as not just reasonable, but essential. For any proposal at re-organization, those questions need good answers and good community understanding and agreement on those answers. -- Dave Crocker Brandenburg InternetWorking bbiw.net