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

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jul 2019 08:37:16 -0400

(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.

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 11:30:59 -0400

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:
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Wed, 24 Jul 2019 21:03:57 +0700

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 <[email-masked]> 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
>    - 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?
>
> 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
>
> art mailing [email-masked]://www.ietf.org/mailman/listinfo/art
>
>
>