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

[Toerless Eckert <[e-mail]>]

Thanks for your insight, Bob

I don't think we do disagree too much except for the benefit of regular
frequency of having these "open" or "dispatch" style meeting. But
as i think i pointed out in other emails, i can think of a lot more
architectural aspects to be in scope than the whole "overall Internet
architecture".

The main issue really is that i think you need to keep an effort like
this running at maybe low flame for a while before possible contributors
will find opportunities to do something. Even if it is more documenting
uncontentuous BCPs or informational text around architecture topics.

Of course, you can not only have soapbox discussions, but it would
really be a lot of fun to have some amount of soapbox microphone lines
and then punish that by asking for it to be written down, and actually
tracking whether it was and rejecting further soapboxing until it
does get written down. Or any other strategies to actually foster
useful output. Catch the people where they are (bitching) and
redirect to something productive ;-)

Cheers
    Toerless

On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote:
> 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
> > > [e-mail]
> > > 
> > > Software longa, hardware brevis
> > > 
> > 
> > 
> > 
> > > _______________________________________________
> > > Architecture-discuss mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
[e-mail]