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

Joe Touch <> Mon, 09 September 2019 04:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 060E6120052; Sun, 8 Sep 2019 21:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QWFNli9CXT1M; Sun, 8 Sep 2019 21:11:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 096B1120047; Sun, 8 Sep 2019 21:11:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lqzHp+yMo3V4oX79FwsFDncIWqrXRLqi1JoTqV+gKRQ=; b=J+GwpgmjhXvToLzuiis+/vP/R SU4B1yxFJ9oxxoT0ZE4rpXI3WUfKPF7jpavZTarB2155btI8vQrRJ9JYHPxFjvyu2Y2WZegSV+3cF /+iZwbe2zaUZMutF9iId7pptp5OfzukT5w9j/X8tUPpFYz0jn2L5FfevFQo23xtbgkXva5gG+gegY Z+Ges06YiBdqIgzBInG11Ea0NhkWp4ZfjNe2ErQhLCVtgoqaQ3tkL28LuuXmGnsPD6tAq6dTdDY3F okc2+FBdxEMu3JR44cxVLsZsownD0/mh776xQhlMzc+ClJ9iYpFT74W5m5gtyvA1s6cc6zYmO6vES DIvY/CdGQ==;
Received: from ([]:49359 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1i7B1Z-0015lD-Ie; Mon, 09 Sep 2019 00:11:38 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_AA843D39-17BB-4F8E-AEC3-AC547A641F9A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sun, 8 Sep 2019 21:11:32 -0700
Cc: Fred Baker <>, Joel Halpern <>, "" <>, "" <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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 04:11:43 -0000

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

>>> 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?

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

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