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

[Jay Daley <[e-mail]>]

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.

cheers
Jay

> On 27/06/2019, at 11:31 AM, Brian E Carpenter <[e-mail]> wrote:
> 
> Jay,
> 
> An interesting topic no doubt, but as I understand it this draft is narrowly
> scoped to the changes required by the creation of IETF LLC and the closing
> of the IAOC. So other changes should really be left for future work.
> 
> Also, the actual details of how the IETF-IANA performance is measured are
> in the formal agreement between the IETF and ICANN. The latest version:
> https://www.ietf.org/documents/224/2018ICANN-IETFMoUSupplementalAgreement.pdf
> and there are performance reports to be found if you search for them.
> 
> Regards
>   Brian
> 
> On 27-Jun-19 11:15, Jay Daley wrote:
>> 
>> 
>>> On 27/06/2019, at 11:02 AM, Geoff Huston <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> [phone]
>>>> skype: jaydaley
>>>> twitter: @jay_daley
>>>> 
>>>> _______________________________________________
>>>> Architecture-discuss mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>> 
>> 
>> -- 
>> Jay Daley
>> [e-mail] <mailto:[e-mail]>
>> [phone]
>> skype: jaydaley
>> twitter: @jay_daley
>> 
>> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
> 

-- 
Jay Daley
[e-mail]
[phone]
skype: jaydaley
twitter: @jay_daley