Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Brian E Carpenter <> Mon, 09 September 2019 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FE10120048; Mon, 9 Sep 2019 13:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ah2W2_y0ldtt; Mon, 9 Sep 2019 13:40:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DC77120020; Mon, 9 Sep 2019 13:40:51 -0700 (PDT)
Received: by with SMTP id u17so8505701pgi.6; Mon, 09 Sep 2019 13:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=svfQ7HzkgP4B6UmFmV8pZXEtOn+P+bd+5mbd7e7zoBg=; b=TMDd1Rg10waCECenT3I/Tx39b2+tNNwdoGeHMJ7lV6VaGQOwxcABY0Jj9Btdx5K71M IVd5ed/WLl0pAsgHZExvu5RzyxOYK3ZHX8oHXTLoSu+12F9IqCW1GpGxIo+oavp9bfxt B8r3PjfG8EgL3wxo3SkO3DY4XfI5vbQsGoTmJGIRS9gPAJvsljTena8KFDIVs1eEJiB4 cNfuaVsYzLDJsN3Mh+qFVNQgWQ6fJ9ybKqSa30jyCc+rOa3Oi4+U3G3wSXul8BacIeQY x7a2T4oWAjtMimloYKHnEYTL7PPY2Bu8bU0gM3X1AKwCk/hk0uWbBuDY0N0ntPA42FTj rdCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=svfQ7HzkgP4B6UmFmV8pZXEtOn+P+bd+5mbd7e7zoBg=; b=JoXzUdLyIQxtSIIJ//dzLRGXwSo2RmlPsLcYYPKgd0DqOQKA2wF4bYc9iOuMdQHAnO bW2z3EnhMVrvuQmtkWQDWvBPE6Arc5W4GZR3Q5AWo9gPM3kkc4l/XCRu6EGhsUYbasG6 zkVb8AlCxPefmGipaO4Qw8qFuhL3S1yiKuFNg/oTcPIVPR6Fc8eRZoEtj1LZJ0P164GP WIPBD3Fy/m8UlHkcu98fU/ZvVH8CbJ/H5U+iuOBIQ6S4SGnu0KuvcG2BWj7b4Ocf6coP I0t/wepJ139FT+uJttryQoAbsHj+K14L56/2PN4A4M1fCHI0330QZ0Ogag5ORyEMVnst Lr1w==
X-Gm-Message-State: APjAAAUeEYbxMn3SvMXWL+5BRr8j4D0yR9Vmqr36pyqb1UizsuI9pEpx BCCdIaxmgZdyrmIjGxI5Q8DS6oTV
X-Google-Smtp-Source: APXvYqyzLTETibpbE6uyFYfyARBVItpnZompiZQLiH5qtfzKZAgiCCHId4YyMO8F5i6VkeC/whYluQ==
X-Received: by 2002:a62:e508:: with SMTP id n8mr9927957pff.199.1568061650356; Mon, 09 Sep 2019 13:40:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u10sm4586438pfm.71.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Sep 2019 13:40:49 -0700 (PDT)
To: Joe Touch <>
Cc: Fred Baker <>, Joel Halpern <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 10 Sep 2019 08:40:47 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Sep 2019 20:40:54 -0000

On 09-Sep-19 16:11, Joe Touch wrote:
>> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter < <>> wrote:
>> On 09-Sep-19 12:15, Joe Touch wrote:
>>>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter < <> <>> wrote:
>>>>>> Wouldn't that require the middle box to become an architectural element?
>>>>> Yes, but not just “an” (one):
>>>>> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX)
>>>>>  *
>>>> I'll take the liberty of pointing out that we've known for many years that
>>>> there are multiple types of middleboxes and they have multiple facets:
>>> Facets are just properties. That doc makes no attempt to describe them as architectural roles.
>> Agreed. My point is that the issue has been lying on the IETF table for many years, and we've collectively chosen to ignore it.
> By “we”, I’m not sure who you mean. There have been plenty of us complaining about this gap for a very long time in the IETF.

Yes, but the IAB hasn't really taken up the issue and we haven't ever had a WG that seriously tackled it, IMHO.

>>>> So far, we haven't added them to any formal architectural description of
>>>> the Internet, probably because we don't have one.
>>> RFC1122, RFC1123, RFC1812 as standards.
>>> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.
>> "you" = the IAB in 1996; I was only the document editor.
> Fair point, but presumably you were on the IAB at the time?

Yes indeed. But although it's almost my most-cited RFC, I don't deserve sole credit or sole blame.

>> But IMHO those RFCs are not architectural as such. They describe functions of nodes, not how the nodes work together as a system.
> An architecture is (IMO) the behavior of a system that is the consequence of the behavior of its components and the ways in which they interact.
> Arguably, those RFCs - adding 791 and 3819, and a few others, do exactly that. In a nutshell: routers relay; subnets (as links) interconnect), and hosts source, sink, and do the rest (including reliability), all based on globally-unique addresses in that can be aggregated by bit prefix. No, there’s no “roadmap” doc that provides the top-level description, but the rest is definitely there in those and other docs.

Yes, we agree about that. It's the roadmap that is missing.

> IMO, the issue is that middleboxes can’t simply be added to that list consistently - they aren’t a third thing that can be peers to routers or hosts. There is a way to describe them that’s consistent, though - but only if they are different elements when viewed from different points in the network (as I described in the tech report).

I can't disagree.

> Joe