Re: [arch-d] Updates on IAB mailing lists

Bob Hinden <> Wed, 29 April 2020 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB2E13A127A for <>; Wed, 29 Apr 2020 08:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 F8R0aEUDFIbU for <>; Wed, 29 Apr 2020 08:10:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B4E73A1277 for <>; Wed, 29 Apr 2020 08:10:57 -0700 (PDT)
Received: by with SMTP id g12so2421432wmh.3 for <>; Wed, 29 Apr 2020 08:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5pV5Kz2eTf1H8KJGEulb6ixYu4nIdB3TPQWjJJQVnys=; b=kKAVwP9ClDuZnXM/zF3gPEi4GB6aqddT8YyYh+IeERM+AGfyRzFc87dy3MvNflQHBR YIQPynlbLBY9JKBVgQkLiIRWsdoYxA98uM6kbBdwXFtrwgaZ2I2m/Wz0npbS4Co92FYi Sfjzle5dptWU0vCFAWpmKQvOLl3G+IUvlLTIGlZO0VfIaZLHuiAQfPgFekfE3PP2CzzZ 0niOu7xn2vBAE2WGNj/fBu5x2WZ0cP2hw0TgGgtb8bRSclQFiy9n2zhexAMZ+l+BkwuU bs0kFZdIGyz9kthi1VfCANDf0GziqhaekNdZLUfVj/S6rA/qd0AYjSlYDNXwzKVTbofb 9Trw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5pV5Kz2eTf1H8KJGEulb6ixYu4nIdB3TPQWjJJQVnys=; b=l03BNyTET37w21bZK9+0m+11bFXA+AF3bhKAWgh+t59EMPMjj+BE4Y/zNPK5XAlRQf gWeydlDEf0pliwa6Mt7NpmT9Z3ONISZ9OzgS1WEEXc/bODHBX74/L5j00kjRIxgIJ4Sq 1Spo3yzuQsoRu+KFbVyZ2H/fwvMjihRVd+b+xC0SzGSykeSTiqJYu3OgOJq4BK0nvxmn TFz3A0Bs67HNuB4vAMo3MZ9bVFej77hHhrp1eZFZQHXUiAFf0Q1cbXaPVJuZNZRLliEH c8rKjrNYYOiZ56xf8KubM69XGGdKeUrZM8ZKeG1fXRdoQEpcF9VQURtDm+wOeJn6j7vu HYUA==
X-Gm-Message-State: AGi0PuZhUbXKzP24pmU0Acqlxqh1i/K1hl/EM2RAJEWdONQcUh7Gpo52 ufzFR1vYwBCOEyf4ckKtc+M=
X-Google-Smtp-Source: APiQypJi0OnZ2gfomaT2l9iAFmX19jaBiIcSZ1BOluW2UQG/Fk+qeUqLQgWHPgIPcx08qYqOMme9tA==
X-Received: by 2002:a1c:384:: with SMTP id 126mr3813507wmd.58.1588173055826; Wed, 29 Apr 2020 08:10:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u188sm8473163wmg.37.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 08:10:54 -0700 (PDT)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_F83108D0-803E-4F28-9873-48596AD0F9D7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Wed, 29 Apr 2020 08:10:46 -0700
In-Reply-To: <>
Cc: Bob Hinden <>,
To: Brian Carpenter <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <>
Subject: Re: [arch-d] Updates on IAB mailing lists
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Apr 2020 15:11:00 -0000


> On Apr 20, 2020, at 2:10 PM, Brian E Carpenter <> wrote:
> On 21-Apr-20 07:34, Mary Barnes wrote:
>> Just to be clear, my point is that architecture-discuss was not intended to be an IAB discussion list any more than IETF discussion list is scoped to IESG discussion.
> Not quite accurate - see below. Especially "This is an IAB-sponsored activity…".

I agree.

I think it is fine and correct for the Internet Architecture Board (IAB) to have a public mailing list to allow discussion of the Internet Architecture.   That is, I would think, why we have the IAB.


>   Brian
> -------- Forwarded Message --------
> Subject: New architecture-discuss mailing list forum
> Date: Mon, 17 Oct 2005 16:00:54 -0400
> From: Leslie Daigle <>
> To: IETF Announcement list <>
> CC:,,
> A new mailing list has been created to provide a forum for general
> discussion of Internet architectural issues:
> The architecture-discuss list serves as a technical discussion forum for
> all members of the IETF community that are interested in larger
> architectural issues. It is meant to be an open discussion forum for
> all long and/or wide range architectural concerns related to the
> Internet Architecture. In particular, it may be used to discuss and
> bring forth different points of view on controversial architectural
> questions. Discussions that drill down and dwell on specifics of
> individual protocols or technologies are to be discouraged, redirected
> to appropriate other fora, or re-cast to discussions of broader
> implications for Internet architecture.
> This is an IAB-sponsored activity, but IAB members will be
> participating as individuals and not representatives of the IAB. As
> such, postings to list must not be considered as IAB opinion, and must
> not be quoted as such. Indeed, it is expected that IAB members will
> disagree with each other, at least occasionally, just like the any
> part of this community.  :-)  Note that questions asking for an official
> IAB opinion, issues requiring immediate action (by anyone), issues
> related to the way the IETF operates, do not belong on this list.
> Issues pertaining to IAB business should still be directed to
> .
> Leslie Daigle,
> for the IAB.
> ------------------------
> [Some examples of potential topics for discussion, provided by Pekka Nikkander]
> 1. Mobility and multi-homing
> The IETF currently hosts a bunch of working groups focusing on  various aspects
> of mobility and multi homing.  At the Internet Area,  there are five WGs and a
> couple of almost-WGs charted for standards  track work: MIP4, MIP6, NEMO, SHIM6,
> MONAMI6, and NETLMM.  In  addition to those, there are experimental approaches,
> such as HIP,  and optimisations, such as MIPSHOP and MOBOPTS.  Outside of the
> Internet area, MOBIKE is focusing on mobility and multi-homing for  IPsec and
> SCTP and DCCP folks have had their mobility and multi- homing discussions.  The
> wider research community is full of various  proposals, including overlay
> approaches (such as i3) and underlay  approaches (such as using MPLS tunnels to
> implement host routes).
> Given this multitude of work and even partially overlapping standards  track
> solutions, what would be the right way or right ways forward?   Could we design
> a way towards converging solutions?  How do we ensure  robustness of solutions
> if we attempt to deploy multiple solutions at  the same time; for example, SHIM6
> + Mobile IPv6 + SHIM6?  How do more  unified solutions, like using CGA-based
> mobility with SHIM6 contrast  to this?  What about using HIP with routable IP
> addresses instead of  Host Identity Tags (HITs) as Upper Layer Identifiers?
> Going a little  bit furthermore, what are the architectural impacts of doing
> mobility  and multi-homing at the IP layer vs. other layers?
> 2. IP virtualisation
> In the recent discussion w.r.t. tunnelling at the Internet Area list,  a clear
> need for virtualisation came up.  While tunnelling with clear
> implementation-level virtualisation boundaries is clearly one viable  way to
> implement virtual IP networks on the top of the "real" IP  infrastructure, this
> issue seems to warrant some deeper digging.   Tunnelling has well known
> drawbacks, and we may want to ask what  would be the alternatives.  In order to
> understand alternatives, if  any, we need to understand better the requirements
> behind IP  virtualisation, or what people *really* want to achieve with it.  Is
> it merely ease of configuration, or reduced operational costs?  If  so, could
> there be other architectural ways of achieving the same  ease or perhaps even
> larger capital and operational savings?  Some  people have been promoting adding
> "realms" as a first class service  to the base IP.  Would that provide an
> alternative solution?
> While the mobility and multi-homing discussion seems to more circle  around
> evaluating existing proposals and trying to navigate towards  more unified
> solutions, here we seem to lack genuine alternatives and  deep understanding of
> the real problem domain.
> 3. Overall open architectural issues
> Some IAB members have been collecting open architectural issues for a  while,
> with the intention of bringing up an up to date collection of  information at a
> later date, probably in a form of a WikiPedia-like  web site.  This work is
> going on, and we'd like to get as much  information as possible from the wider
> community.  Hence, suggestions  on what are the more pressing longer-term open
> issues are very  welcome.  To given an idea of the current issues so far
> identified,  here is a partial list.  The list doesn't say much without
> explanation, but it may give an idea of the type of issues we are  looking at.
> End-to-end connectivity
> =======================
> The original value of the Internet, the ability to connect to any  host with
> any protocol, has eroded away during the last decade. While  it is impossible to
> get back to the original mode of operation,  largely due to security reasons,
> some form of better-than-today end- to-end connectivity would be very valuable.
> o Living with NATs, filters, and firewalls
> o Introducing identity realms or domains
> o Evolving the application interface (API)
> End-user experience
> ===================
> o Transparent security
> o Zero Configuration and Service Discovery
> Balancing Accessibility, Security, and Privacy
> ==============================================
> o System for plausible sender identity for received packets
> o Secure self-configuration
> o Integrating security across the stack
> o Dealing with bad traffic
> _______________________________________________
> IETF-Announce mailing list
> _______________________________________________
> Architecture-discuss mailing list