Re: [arch-d] draft-iab-rfc7500-bis-00 - new principle of measureability

John C Klensin <john-ietf@jck.com> Thu, 27 June 2019 23:35 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DFD12004E; Thu, 27 Jun 2019 16:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 GSX_fvJcDjkb; Thu, 27 Jun 2019 16:35:54 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 7512312003F; Thu, 27 Jun 2019 16:35:54 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hgdvj-000BWG-Dn; Thu, 27 Jun 2019 19:35:51 -0400
Date: Thu, 27 Jun 2019 19:35:45 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jay Daley <jay@daley.org.nz>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, iab@iab.org, architecture-discuss@ietf.org
Message-ID: <75035F4D01FBF3E9EAA058C0@PSB>
In-Reply-To: <5C724256-C116-4029-9251-41F00360F35D@daley.org.nz>
References: <69EAE468-64DC-40C8-9D49-BEAEA0E7EDF3@daley.org.nz> <E7428B2B-2E90-4962-B5D1-75DD2E4ADD62@apnic.net> <6CB8D3FA-B4D2-4A49-9E0E-DE2FCA28F02B@daley.org.nz> <c29f4e13-a70c-0db3-7b3c-fa853627de6d@gmail.com> <5C724256-C116-4029-9251-41F00360F35D@daley.org.nz>
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: 198.252.137.10
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/architecture-discuss/ijfHJEB1ZKtcxieJC7cokMiz6s4>
Subject: Re: [arch-d] draft-iab-rfc7500-bis-00 - new principle of measureability
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 23:35:57 -0000


--On Thursday, June 27, 2019 12:08 +1200 Jay Daley
<jay@daley.org.nz> wrote:

> Thanks Brian
> 
> I was trying to keep this strictly at the principle level and
> a gap I see in the proposed principles, rather than get into
> any details of how performance expectations are set or
> measured.

Jay,

Please take this as a comment about the principle and not about
this particular I-D -- I'd be very opposed to altering the
document beyond the current scope of changes even if there were
agreement on your proposed principle, which, at least IMO, there
isn't.

There is a long and unfortunate history about how efforts to
quantify and measure complex administrative procedures (or
complex procedures with significant administrate components)
tend to work out.   There are inevitably some things that are
easy to quantify and measure.  Using IANA as an example,
consider registration lag (time between the arrival of a
registration request and its appearance in the relevant
registry), registrations completed per month, and so on.  Other
things are much harder to measure.  For example, requests
sometime come along that ask IANA to reorganize a registry.
While one could count the number or frequency of such requests,
that would ultimately measure the behavior of the body making
the requests -- the only thing it measures about IANA is their
ability to read minds and forecast the future, neither of which
should be anything we try to write into a contract (I hope for
obvious reasons).  But what they happens in practice is that the
things that are easy to quantify and measure get redefined as
being _the_ performance criteria and the other things tend to
get submerged and lost.  

That can be pathological because it may reward bad behavior and
discourage good behavior.   For example, we have "IANA
Considerations" sections in documents so IANA can review what
they are being asked to do before the IETF finalizes the
request.   Obviously, we don't want them to take any longer to
make those evaluations than necessary.  But it is far more
important that the make them with great care and as much thought
and dialogue as needed.  If they are encouraged (or forced) to
race through things by being evaluated based on throughput and
don't spot important issues as a result, they lose, the IETF
loses, and the users of the resulting registries and database
lose most of all.

So I suggest that trying to enshrine "let's find things to
measure and take those measurements" as a principle -- and it is
where "include the collection and publication of sufficient data
...to allow their performance ...to be measured and to assess
whether they are delivering their services" has a long history
of taking us and others -- is, by itself, a bad idea.

Now those concerns about misuse of quantitative data and
effective discarding of qualitative information can be mitigated
by deep understanding of issues, careful design, implementation,
and oversight so I'm not arguing against data collection under
the right set of circumstances.  But, unless whatever data
collection and measurement plans are developed considers the
issues, risks, and controls --things that generally goes far
beyond (and are orthogonal to) openness and transparency -- they
are often more of a problem than an advantage.

If you want to write an Internet-Draft that proposes what should
be measured in the IANA case _and_ that provides a context for
proper consideration of the qualitative factors and protection
against rewarding them for rushing through things rather than
doing them carefully and with due consideration, I, for one,
would be very interested in seeing it.  Probably so would the
IANA staff as well as the IAB.  But the "principle of
measurability" as proposed above is, independent of anything
else that has been said in this thread, just not a good idea.

best,
    john