Re: IETF areas re-organisation steps

Dave Crocker <> Wed, 14 January 2015 15:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B4B91A8820 for <>; Wed, 14 Jan 2015 07:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XwK7QZdYKKA7 for <>; Wed, 14 Jan 2015 07:32:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31F541A8838 for <>; Wed, 14 Jan 2015 07:32:29 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0EFWKaY009244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jan 2015 07:32:23 -0800
Message-ID: <>
Date: Wed, 14 Jan 2015 07:32:06 -0800
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Eggert, Lars" <>, Ted Hardie <>
Subject: Re: IETF areas re-organisation steps
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 14 Jan 2015 07:32:23 -0800 (PST)
Archived-At: <>
Cc: IETF <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Jan 2015 15:32:31 -0000

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.)


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