Re: IETF areas re-organisation steps

[Dave Crocker <[e-mail]>]

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