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

John C Klensin <john-ietf@jck.com> Tue, 23 July 2019 12:37 UTC

Return-Path: <john-ietf@jck.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 DA22B1202BD; Tue, 23 Jul 2019 05:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 t7nBTPqFZFus; Tue, 23 Jul 2019 05:37:18 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268FD1202E4; Tue, 23 Jul 2019 05:37:18 -0700 (PDT)
Received: from localhost ([::1] helo=JcK-T100) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hpu2f-0003FK-1p; Tue, 23 Jul 2019 08:37:17 -0400
Date: Tue, 23 Jul 2019 08:37:16 -0400
From: John C Klensin <john-ietf@jck.com>
To: art@ietf.org
cc: architecture-discuss@ietf.org
Message-ID: <77F8C1C2AAB5AE251285436F@[172.20.2.211]>
In-Reply-To: <CAChr6Sza8u8oyCsDUDJzNbRFqMjeoR5zLz5YmoUUMTrXKUgK6w@mail.gmail.com>
References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <CAChr6SyYB9mHAx+AQSTVQvb2g5FvAD03KQ_Ta7=RH+6Pt8dKrw@mail.gmail.com> <CAChr6Sza8u8oyCsDUDJzNbRFqMjeoR5zLz5YmoUUMTrXKUgK6w@mail.gmail.c om>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/Ef09SVAnIMfGfkHSbEni9iCYRas>
Subject: [art] 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: Tue, 23 Jul 2019 12:37:26 -0000

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