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

Jay Daley <jay@daley.org.nz> Wed, 26 June 2019 21:44 UTC

Return-Path: <jay@daley.org.nz>
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 E65B9120370 for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Jun 2019 14:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oJJalja2yn9l for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Jun 2019 14:44:29 -0700 (PDT)
Received: from 412514.vps-10.com (412514.vps-10.com [212.48.70.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B561202B4 for <architecture-discuss@ietf.org>; Wed, 26 Jun 2019 14:44:29 -0700 (PDT)
Received: from wintermute.local (unknown [158.140.230.105]) by 412514.vps-10.com (Postfix) with ESMTPSA id ACBA44E0F98; Thu, 27 Jun 2019 09:44:26 +1200 (NZST)
Authentication-Results: 412514.vps-10.com; spf=pass (sender IP is 158.140.230.105) smtp.mailfrom=jay@daley.org.nz smtp.helo=wintermute.local
Received-SPF: pass (412514.vps-10.com: connection is authenticated)
From: Jay Daley <jay@daley.org.nz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <69EAE468-64DC-40C8-9D49-BEAEA0E7EDF3@daley.org.nz>
Date: Thu, 27 Jun 2019 09:44:22 +1200
Cc: iab@iab.org
To: architecture-discuss@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/bBIUuMeaC-BuZpF175JjIseCFqI>
Subject: [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: Wed, 26 Jun 2019 21:44:32 -0000

I support the principles as documented but feel that there is one more that needs to be added:

* Measurability
The operations of IANA registries must include the collection and publication of sufficient data, in accordance with the other principles of openness and transparency, to allow their performance, both current and historical, to be measured and to assess whether they are  delivering their services in accordance with the other principles and the registry policies.


My reasoning to add this as a specific principle is because any assessment of the performance of an IANA registry requires data.  However, I have too often come across the situation where openness, transparency and even accountability are insufficient to ensure that this happens.  Common excuses include "we don’t collect the data", "the data belongs to our customers not us", "the data is unreliable", "the data we collect doesn’t measure our performance" and so on.  Adding this as an explicit principle ensures that data is collected and that it is fit for purpose and collected under the terms that allow it to be used for this purpose. 


As a background to this comment I should note that I was part of the team that designed the naming functions SLA for PTI and an inaugural member of the Customer Standing Committee within ICANN that assesses and reports on PTI’s delivery of the IANA naming function in accordance with the SLA.

cheers
Jay


-- 
Jay Daley
jay@daley.org.nz
+64 21 678840
skype: jaydaley
twitter: @jay_daley