Re: [arch-d] on the nature of architecture discussion

Bob Briscoe <ietf@bobbriscoe.net> Mon, 06 April 2020 13:30 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707773A1DA6 for <architecture-discuss@ietfa.amsl.com>; Mon, 6 Apr 2020 06:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4SHZWPvR9Aa for <architecture-discuss@ietfa.amsl.com>; Mon, 6 Apr 2020 06:29:46 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E035D3A10B6 for <architecture-discuss@ietf.org>; Mon, 6 Apr 2020 06:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=b10srLvwGUWDkBzvWE+0AxZbsdbfMm1GYZ3brwyxqb8=; b=toSpHPs3gqSbN3gYJzVpj8kbQF fV8DotFEwZqN7b4NXxnfsIZ2WsFk+Y+t3ewPE/ihLiKWj2jQzpcUPvs5MpwJF6i2MFfY3ikP4WiXd oCRNSpOkqvoiZy8yMqbV+6Q8zKgqaKOi+oRb65w/PB/zKt0kaJ1eN2MRqUkadcE7lXRt9fDDrX2Uc 53sgyhl65i0PrJDkJZSzQffCvC8WPm8/rOPX7eVa7Vl1uZzjZHTlxuJSSOZGStnoemhYuYhTGwWeL o2tggz3Jvn/2LczPTPoiRia42B0M8FrAHx0UhDK3OsTU8O31j6y5c0A5T7SVwIW3kEb7DFUT3sWOq 8lGYBC5w==;
Received: from [31.185.135.141] (port=33188 helo=[192.168.0.11]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1jLRkp-00CJJ4-FE; Mon, 06 Apr 2020 13:25:31 +0000
To: Toerless Eckert <tte@cs.fau.de>, Melinda Shore <melinda.shore@nomountain.net>
Cc: architecture-discuss@ietf.org
References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <efbf8fd0-4673-3a93-2add-6bbc6ff0dca9@cs.tcd.ie> <a5046b41-b44e-d292-e0da-da6ec6d599ad@cs.tcd.ie> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <fe14a164-cdb2-78eb-3071-6a84d28ab878@bobbriscoe.net>
Date: Mon, 06 Apr 2020 14:25:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/RN-BIlxMifLlB4mR6u19ISc8iY0>
Subject: Re: [arch-d] on the nature of architecture discussion
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2020 13:30:46 -0000

Toerless,

I helped with a series of 'Re-Arch' research workshops from 2008 to 
2010. The name was about "re-architecting" the Internet (whatever that 
means), but the accepted papers included articulation of insights about 
the existing architecture. I was also involved in various activities 
before that to promote research investigation into the Internet's 
architecture. So, based on that experience, here's my 2 penny's worth.

You don't want to have "arch-dispatch" sessions too often. Good 
architectural ideas don't come up that often, so if you create too much 
space to talk about them, the vacuum will get filled with waffle. Once a 
year is probably enough. But then, if you detect waffle is starting to 
fill a vacuum, it's best to back off the timer to biennial. Of course, 
if some new activity spins out of this (as it sometimes should from an 
arch-dispatch activity), that takes on a separate existence that is more 
frequent than the annual cycle of dispatch sessions.

You certainly don't want to do this from mic lines. It's too easy for 
"random-ietf-bigot" to have opinions about architecture that don't add 
anything (other than for those collecting lists of opinions). 
Contributors need to have had to do some work, like writing an accepted 
paper, to even get into the room.

It needs to be framed in a context of actionable outcomes. I mean, 
something like arch-dispatch would be a suitable context, 'cos it gives 
out the "actionable-only" message. That doesn't preclude "vague 
thoughts", but only as long as they have the potential to lead to some 
change that will impact on real life once they firm-up.

So, IAB might be a more appropriate context than IRTF, but you want an 
environment that will attract researchers and thinkers. So the 
"political officers" need to be in the background managing the process 
rather than holding the floor.

The architecture of such a valuable artefact as the Internet can become 
highly political. Huge businesses have been built on the Internet's 
current architecture, with a vested interest for it not to change. One 
person's architectural improvement is destruction of someone else's 
business (selling hacks to work round architectural problems is big 
business). And one progression of changes destroys someone else's idea 
of how they thought changes would progress. So altho the discussion will 
often seem academic, the structure in which ideas are taken forward has 
to be resilient against the wars it might start. That part is much 
easier said than done.

Cheers


Bob

On 03/04/2020 02:05, Toerless Eckert wrote:
> On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote:
>> On 4/2/20 11:34 AM, Toerless Eckert wrote:
>>> Was it only presentations or also associated drafts ? Was the
>>> material asked to be make available sufficiently long ago to
>>> allow quality updates be prior review ?
>> Neither, really.  It largely consisted of heated discussions at
>> the mike lines.  While there were presentations, for the most
>> part they were not architectural in nature (with a few notable
>> exceptions).
> Ok, remembering some bits now.
> That was fun, but yes, not what i was thinking of.
>
>> My sense, from several decades of involvement in the IETF in
>> various capacities, is that 1) it would take years to get
>> agreement on a diagram of the current internet architecture
>> and what you'd end up would be aspirational rather than
>> descriptive;
> I think we can and are doing descriptive. Most of stackevo
> mentioned by you below was descriptive. So are IMHO
> many other documents/RFC i would consider to be architectural.
>
> I can think of aspirational as a good and even necessar thing.
>
>> 2) architectural discussions in the past have
>> had minimal impact on actual protocol design;
> That is a very broad statement. We should first have an
> unserstanding about what we mean with architecture before
> i should even ask you to give me example evidence of this.
>
> My architecture interests for example are probably a lot lower
> inside the machine room of the Internet than e.g. the
> Internet BGP peering architecure. But all of it is valid
> architecture topics to me.
>
> For example, i would consider CBOR an example of an
> architcure concept (presentation layer) brought into
> IETF and protocols.
>
> One example architecture area of interest for me is the problem that we
> are not well enough taking the architecture of routers in to
> account for our protocols, or better yet propose to evolve
> architecture of both routers and protocols to be better fits in the
> future.
>
> I am betting neither of these topics are what you would
> have considered to be architecture in your statement... ??
>
>> and 3) complexity
>> always wins in the end (the history and output of the NSIS
>> working group might be a particularly illustrative example
>> of the latter).
>>
>> Right now, there is nothing stopping anybody from publishing
>> drafts and contributing to (or, indeed, leading) architectural
>> discussions in IETF working groups.  I'm not sure what
>> inferences we should make from the fact that for the most part
>> that's not happening now.
> If architecture can be associated directly with protocols
> of an IETF WG, then yes, it could and should happen
> in that WG, but i think there are more cases where even
> this does not happen. E.g.: I have seen ADs eliminate architecture
> from charters because it does not produce implementable protocols.
>
> But the more fundamental issue is that architecture mostly
> needs to predate protocol development, like research mostly
> needs to predate architecture and protocols. I can not
> see a logic that argues we must have an IRTF, but we cannot
> have an IATF (Internet Architecture Task Force). The
> whole construct of IAB for architecture is weird to me.
>
>> I'm skeptical about the actual value of what you're proposing
>> but as I said, there's nothing stopping you (or anybody else)
>> from starting up something informally, which would give us all
>> a better sense of the actual interest level and what the likely
>> output would be.
> Oh, i think there is a lot of sport in trying to discourage work
> that is not officially sponsored by the IETF/IAB authorities
> at least from my imited experience.
>
> We need to be darn careful with every single word we
> write about a side meeting. Make sure it is called "non official"
> every time you mention it, having people seemingly "borrow"
> sign up sheets for examination what could be wrong with them,
> ending up with concerns of using the same color (!) as "official" IETF
> meeting sign up sheets. Dismissive comments about even doing
> a side-meeting, Not being allowed to use IETF tooling
> like webex, jabber, wiki, etherpad, and so on.  Because using
> IETF tools would mean "endorsement of the activity" *sigh*.
>
> This is sad in general, but at a time when it is legally crucial
> to make sure all communications is easily recognizeable as
> public and published because of the US Govt. export regulations
> (see EAR 734.7) it is outright dangerous to make it so difficult
> for inofficial side-meetings to use or emulate the
> public/published nature of official IETF meetings.
>
>> Also, note that there have been IAB programs like stackevo to
>> deal with these questions.
> Last RFC published in 2016. Concluded in 2019.
> Followup to architecture-discuss according to closing mail.
>
> Cheers
>      Toerless
>> Melinda
>>
>>
>> -- 
>> Melinda Shore
>> melinda.shore@nomountain.net
>>
>> Software longa, hardware brevis
>>
>
>
>
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/