[art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization

Guntur Wiseno Putra <gsenopu@gmail.com> Sun, 11 August 2019 06:37 UTC

Return-Path: <gsenopu@gmail.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD412084F; Sat, 10 Aug 2019 23:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WyqjnJV69LXV; Sat, 10 Aug 2019 23:36:51 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456FF120895; Sat, 10 Aug 2019 20:06:42 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id f17so11991289otq.4; Sat, 10 Aug 2019 20:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=UVfDQ3ZijbTnsnUDAuywChfm5hTfzvR2+Atc3Kvdx2oCMLGX6+R3rfBOaHtVGzS5BV QW6yt7zF4YRYLQBZ2JCQHAZdUBmbPGx3hQ8JgpQpEr7++deV6+pDRD95SyqUUYAvb6vM VTXv4+XBouhjRmhYqYZ/PljSnUaQzXeKH27aucc76sj8sxvpj9DcA5nAgQ0jW+2mMMqO 27mCdlGnb3xELd4p8ZcT4pDJ6zgOtxZqoERyMTmh4eN55is//iu71SeQQM1lAeOMlVHh xl6EhFzqVaBxpbSAW+cK2n+jyN6udd3WXsu71f7Gefc4NZCJ9ao6xWXsy2gRL21VR/ng XmEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=lD+irMAgXBKqTKRFyI3H6Bx3fmwMf2vp3sXCkaRyVimANZBWkPx63CqWeWLzSqVY2d t+TT71uSrfkI5LjmDueZtJ0A+EOdeYBI1mWLZpd3Yk/L4/NYISPn05S2TRETEEy+nPUn BWr/RQSJ13q2dwRCHgT8+ruWm4cHMjHQ9Gofqct0ZzszcXEdNHWGjug0wIvgtfTw9hLW RoupmfyQPf1YTvNZ2wIpMYfInxJYcsM/vz8oy6q8dcK428hgyG1gF63sCdXf6RFRyS7U 5woDJi2ncHOZq/+Fp797oKydB5xxhfkCzcjx33z8ulj6ryWB+bN2b2XQnLhFq+Y/tcG0 us9w==
X-Gm-Message-State: APjAAAXxwfxc90Is3zhjSaB8AkKoMFc0cDo9JqBsj55Cv6XPisLVEAC+ IxrafHXvfxxYRpn9X3hi8Q36w/iyNvFbKcihBvY=
X-Google-Smtp-Source: APXvYqye9SrId5sA0I4wgPRn+CjjgyC9hbiTzAQJnYE8dKoNllMIH3p+FhlwZK2DsndYS4VMHkgqo4/JDXezgXUqp5U=
X-Received: by 2002:aca:b104:: with SMTP id a4mr10314516oif.90.1565492801328; Sat, 10 Aug 2019 20:06:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 20:06:40 -0700 (PDT)
In-Reply-To: <CAKi_AEuxuiPZ4=KoCcH_rVa1GEhgVBKeC3SOP3h4W1bUi6aq-g@mail.gmail.com>
References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <CAChr6SyYB9mHAx+AQSTVQvb2g5FvAD03KQ_Ta7=RH+6Pt8dKrw@mail.gmail.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> <CAKi_AEuhiAEbHgQ15=KL2af5qL3ei-NQjHd6UCpxqbxoHCfqvQ@mail.gmail.com> <CAKi_AEuxuiPZ4=KoCcH_rVa1GEhgVBKeC3SOP3h4W1bUi6aq-g@mail.gmail.com>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Sun, 11 Aug 2019 10:06:40 +0700
Message-ID: <CAKi_AEt2A3MbJOrxZvkqKtkFT8BSmQ_PpFRor0OpQ6gEbgfNnA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: John C Klensin <john-ietf@jck.com>, "art@ietf.org" <art@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000525b10058fceb259"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/N0faV7elT71qTRh92-cleOtn08Q>
Subject: [art] [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Aug 2019 06:37:48 -0000

Dear architecture-discuss,

An alternative link to the posting on Marcos Nocak'S "Liquid Architecture
in Cyberspace" at public@informationarchitecture@w3.org  I mentioned
earlier is

https://lists.w3.org/Archives/Public/public-informationarchitecture/2019May/0000.html

(which was "403 Forbidden: Request forbidden by administrative rules" the
last time I checked up minutes ago)

Or, if going directly toward the text:

https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf

Thank to Martin Dodge for suggesting Marcos Novak's architecture in
www.cybergeography.org bringing me to Daria Tsoupukiva's lecture providing
the reading...

Regard,
Gubtur Wiseno Putra

Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com>
menulis:

> Dear architecture-discuss,
>
> Such co-presences of which architecture is part of: if we attempt to think
> of its relation with other human experiences on poetry, on poetics, on a
> spirit invoked to make comprehensible a poetic fact, to get toward an
> understanding of cyberspace architecture, of "Liquid Architecture in
> Cyberspace" (Marcos Novak, 1991)
>
> I suggested as a reading to public-informationarchitecture@w3.org at
> which there is the web-address to the Novak's work (posted at 12 May 2019):
>
> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy
> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture
> Regard,
>
> Guntur Wiseno Putra
>
> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
>
>> Dear architecture-discuss,
>> & John,
>>
>> To share what might be inspiring...
>>
>> In order to propose what should be understood as "concept", "percept" &
>> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is
>> Philosophy?") mentioned architecture as the first art as art begins with
>> house: that of which "the most scientific architecture continually produces
>> and unifies planes and sections... it could be defined as "frame" with a
>> connection among various frames oriented differently, applied to other
>> arts...(There is) a composite system consisting of points and
>> counterpoints... (there is) a matter of sensations (percepts and affects)
>> combined... (While) the system still needs a composition plane run
>> "deframing" opening ways from house territory to city-cosmos, the system in
>> which there are cosmic forces to create new affects...".
>>
>> There is "asthetic composition" as the working of sensation which is, so
>> they said, the definition of art...
>>
>> Regard,
>> Guntur Wiseno Putra
>>
>> Pada Selasa, 23 Juli 2019, Adam Roach <adam@nostrum.com> menulis:
>>
>>> John --
>>>
>>> It's going to take a while for me to formulate my thoughts around what
>>> you say below. To make sure I understand the class of constraints you're
>>> concerned about below, can you clarify whether you think they apply to:
>>>
>>>    - Documents like BCP 200, RFC 2804, and BCP 188?
>>>    - Documents like BCP 9 and BCP 92?
>>>    - Documents like BCP 25, BCP 54, and BCP 83?
>>>
>>> You might see an unstated agenda in the categories of documents I list
>>> above, so I'll state it explicitly: in the general case, one person's
>>> important protections against a tragedy of the commons is another person's
>>> annoying impediment to be ignored and defeated. I get that not all of the
>>> above read on protocol design; but they do share the common feature that
>>> they've gone through the IETF consensus process (at least to the degree
>>> that such a process existed at the time of their respective publications).
>>> If we're going to carefully parse out the meanings of some of them as the
>>> will of the community while treating others as light guidelines to be
>>> ignored when they become cumbersome, we're going to need to agree on a
>>> pretty bright line that divides those categories.
>>>
>>> /a
>>>
>>> On 7/23/19 08:37, John C Klensin wrote:
>>>
>>> (copying architecture-discuss because the comment I'm about to
>>> make is an architectural issue and because
>>> draft-nottingham-for-the-users is under discussion there.)
>>>
>>>
>>> A late colleague, much loved by some of us, used to claim (much
>>> more elegantly than I can manage) that one of the reasons the
>>> ARPANET and then the Internet protocols had succeeded and much
>>> of what was seen as competitive alternatives had not, was that
>>> our efforts focused on pragmatic, working protocols and
>>> implementations.
>>>
>>> The other folks had developed a culture of formalisms, models,
>>> and stated design principles.  They then tried to develop
>>> protocols that fit into the boxes and categories of those
>>> formalisms, models, and design principles.    When they
>>> discovered that something didn't fit, they needed to either
>>> invent kludges or other ways of getting square pegs into round
>>> holes, go back and revise models and guidance before moving
>>> forward, or consider and make exceptions (which often required
>>> first figuring out how to make an exception and developing
>>> procedures for that).
>>>
>>> One difficulty is that the above can waste a lot of time.
>>> Another is that it can distort protocol design, if only because
>>> forcing square pegs into round holes tends to be hard on both
>>> the pegs and the holes.
>>>
>>> In many or most fields of application, the nature of engineering
>>> involves seeing and understanding a range of tradeoffs and then
>>> doing design work that reflects a carefully-chosen balance among
>>> them.  Give design elegance absolute priority over structural
>>> issues and buildings and bridges fall down.  IMO, we need to
>>> think, and keep thinking, about systems and tradeoffs.  That, in
>>> turn, means that statements like these that can be interpreted
>>> in absolute terms, even if we mostly agree with them, should be
>>> packaged as general guidelines and not BCPs to which everything
>>> done in the future is required to either conform or to try to
>>> figure out how to appeal to a higher authority.
>>>
>>> I'm not at all convinced that the proposal that was summarized
>>> an ARTAREA yesterday and that is seen as requiring an exception
>>> to BCP 190 is a good idea.  But I think our time would be better
>>> spent, and the Internet more efficiently made better, discussing
>>> the strengths, weaknesses, and alternatives to that idea rather
>>> than debating the reach and appropriateness of BCP 190 under
>>> various circumstances.   Long term and more generally, I think
>>> that suggests seeing BCP 190 not as a particular set of
>>> principles and rules but as an example of something we don't
>>> want to do to ourselves again as a BCP (or as something that
>>> gets enough of an IAB stamp of approval that people will later
>>> argue MUST (or SHOULD) be conformed to.  Again, restated as
>>> general guidance with the assumption that there will be
>>> exceptions and cases not considered, I don't have much of a
>>> problem.    If that shoe fits  draft-nottingham-for-the-users,
>>> so be it.
>>>
>>>    john
>>>
>>> p.s. I don't mean to pick on Mark here.   While these two
>>> documents coming up at the same time was handy, I think the
>>> problem is general and that there are far worse examples
>>> (examples of which he is not an author) than either of them.
>>>
>>> _______________________________________________
>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art
>>>
>>>
>>>