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

[Mary Barnes <[e-mail]>]

So, that predates my tenure on the IAB by about 6 years, so we probably had
rolled over a lot of the IAB at that time by then (it looks like Dave
Thaler would have been the only one left from that era).   It would have
been more clear had the last paragraph been included as part of the list
description:

And, maybe it should be added now.  Right now this is the list description,
which says nothing specific to the IAB:
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.

Regards,
Mary.

On Mon, Apr 20, 2020 at 4:11 PM Brian E Carpenter <
[e-mail]> 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...".
>
>    Brian
>
> -------- Forwarded Message --------
> Subject: New architecture-discuss mailing list forum
> Date: Mon, 17 Oct 2005 16:00:54 -0400
> From: Leslie Daigle <[e-mail]>
> To: IETF Announcement list <[e-mail]>
> CC: [e-mail], [e-mail], [e-mail]
>
> A new mailing list has been created to provide a forum for general
> discussion of Internet architectural issues:
>
>    [e-mail]
>    https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
> 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
> [e-mail] .
>
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>