Re: [arch-d] draft-iab-rfc7500-bis-00

> On 27/06/2019, at 11:02 AM, Geoff Huston <gih@apnic.net> wrote:
> 
> OK, I’ll bite.
> 
> What _exactly_ do you mean by "the performance of an IANA registry”?

Performance in this context is the measurement of processes and services provided by the IANA registry.  This is then assessed against expectations set in policies.

For example,

- Availability of the well known locations for protocol identifiers.  This could be measured by recording each outage. 

- Responsiveness of publication.  This could be measured by recording how long it takes from the publication of an RFC that includes a new protocol identifier for it to be registered and published.

cheers
Jay

> 
> 
>> On 27 Jun 2019, at 7:44 am, Jay Daley <jay@daley.org.nz> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 

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

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