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

Guntur Wiseno Putra <gsenopu@gmail.com> Sun, 11 August 2019 04:48 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 2615912086B; Sat, 10 Aug 2019 21:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[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 uUvxX_4t5xWg; Sat, 10 Aug 2019 21:47:21 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 1DE78120963; Sat, 10 Aug 2019 18:47:03 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id f17so11677400otq.4; Sat, 10 Aug 2019 18:47:03 -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=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=YgfNP5QYQiq+q8COAsWTLu6MAv2b+XVFujOdWrmUb4IeBoT4kGUuevXvSBlYVZLud9 Vc8/QBkzo2Rzyo1AQYiDhEgazuO9XKOOn+6RmU00Drkkq5bpdczmq6Sz7b0zSQPWt69i TKIIM9T7XnqOnyrjHOhHQmk+x6VHrV8H2emXyMsrGL7b4htaRJVOXY2b/n1vdymDf5Z4 /gT0z7fRR7opoC6+nZPdhutsnSPh4qEpd6gSbkCG57bbpcYIAdbzcytcyn9qzrXkewGY 6ojqiKEo50t5JHkjodV6H5q6Y3U30jZwxXBf1DuZmszWF7RxTAYiMW4OLQMNhRv2SUma pdaA==
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=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=aQpKSvl5IPJGehg358It+gwaqq0KMGFpWiYKA+UNHqOP1duqgXf2UAJyeN84ENkWgW aVfa3n80aDNUh72vl8s5R1c/PqxikryhoERwAX50jcOQMUuyf1aF9XkcNjNGs75o2aWv 14jg97Cn+iAWZBBNCBv+oQh7gkxuObqhNduGg9uQvKsYbvfisF94jrbXXMTj/BZn8egn cDEOU60xzBvdSIZB16Xov0N/rLGnB9AS2DbJK2bxdZsgF026oBb6RJWtM3bQYGDOLk// y+zSGpiJQZ1s1TyETdyFM1y9ASp33CGLzEK1BfEKezN2Z9mmz8U8Hf8PDDwDaXONB2po mXnA==
X-Gm-Message-State: APjAAAWM/BDn8dc8VFTJf/TXnX1BnKw08vuR+EULp9LiuIKBNo/te7lb 3+qRYxaMsN+ltZJO6/JWkjRW0hhrR/hqWTSTUUw=
X-Google-Smtp-Source: APXvYqyMz+5iIeR6Vkv6+ZMq4pcs1F+N0ggZFr6AgsL7J3JS5vE9r3r6dr8RmbiojHzzYQ7T7UEHVqo+iQC5F4Y1pZI=
X-Received: by 2002:a54:4703:: with SMTP id k3mr10379358oik.143.1565488021266; Sat, 10 Aug 2019 18:47:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 18:47:00 -0700 (PDT)
In-Reply-To: <CAKi_AEuhiAEbHgQ15=KL2af5qL3ei-NQjHd6UCpxqbxoHCfqvQ@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>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Sun, 11 Aug 2019 08:47:00 +0700
Message-ID: <CAKi_AEuxuiPZ4=KoCcH_rVa1GEhgVBKeC3SOP3h4W1bUi6aq-g@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="0000000000006865d9058fcd95e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/JEFCchdmJFOjHgiAQl5have0wNg>
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 04:48:16 -0000

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-9fQDq0Hy9JP0ZyT5em5Tg9gBMJh0Aiw@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
>>
>>
>>