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
- [arch-d] draft-iab-rfc7500-bis-00 - new principle… Jay Daley
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Geoff Huston
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Jay Daley
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Jay Daley
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Stephen Farrell
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Brian E Carpenter
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… John C Klensin
- Re: [arch-d] draft-iab-rfc7500-bis-00 - new princ… Jay Daley