[Ssr2-review] discussion on call today per dropping part of recommendation 24 on alternate roots

[Žarko Kecić]

I agree to delete this part of R24, and as I have proposed during the call, we should rewrite the entire recommendation keeping only significant stuff in. Entire text is confusing and it's not clear what we propose to be measured and what impact on SSR is expected.

Žarko

-----Original Message-----
From: Ssr2-review <ssr2-review-bounces at icann.org> On Behalf Of k claffy
Sent: Wednesday, October 16, 2019 5:13 PM
To: ssr2-review at icann.org
Subject: [Ssr2-review] discussion on call today per dropping part of recommendation 24 on alternate roots




i propose to delete the text about recommending that ICANN measure alternate roots, for the following reason:

-- i think we need to prioritize the tremendous amount of measurement we are recommending icann do of the current ICANN-coordinated ecosystem.  

-- if i received this recommendation, it is not clear to me what i would measure and how, and how i would know whether the results of the measurement are achieving the intended effect.  
the last part applies to SSR3. 

-- alternate roots do and will exist and there is nothing icann can or should do about them except make sure that "icann is not following its own bylaws and its own principles of accountability and transparency" is not a legitimate reason for such roots to grow and proliferate.  our recommendations should focus on these principles in an SSR context.

proposed deletion in between @@@@ below, from https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmijx4/edit#

k




Recommendation 24: (Root Zone Data) -- Rec 24, 25, 30, 31, 32, 33, 34

For each root-zone related service and any gTLD service that ICANN has purview over, including the serving of data sets, e.g., CZDS, ICANN should create or bring into existence a list of statistics and metrics that reflect the health operational status (such as availability and responsiveness) of that service, and publish a directory of these services, data sets, and metrics on a single page on the icann.org web site, such as under the Open Data Initiative ODI initiative. This would address strategic objectives 1 and 2, and strategic goal 2.1, increasing transparency and simplifying PDPs. ICANN should create a single document describing these services, data sets, and metrics, and integrate community feedback via public mechanisms to improve these services, data sets and metrics on a continual basis.  The frequency of publication should be decided be (by default) annual, but may be altered by community consensus.
These metrics shall include:


-- Root Zone Measures (Key Performance Indicators, KPIs): ICANN should create or commission the development of formal KPIs for the DNS Root zone (including DNSSEC, availability, integrity, abuse, etc.), so that its SSR aspects can me concisely and systematically measured and tracked.  KPIs should be produced as summaries over both the previous year and longitudinally (to illustrate any baseline behaviors). Community feedback should be requested regularly, considered, and collated after each report. Where appropriate, feedback should be incorporated into follow-on reports. The data used to measure the results in these reports should be archived and made publicly available, along with any and all methodologies (to foster reproducibility). At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators
over time.   This will address strategic objectives 1, 2, 3, 4, and
5, as well as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1,

@@@@ BEGIN DELETE

--       Root zone KPIs, KPIs for known alternate root zones, deltas
of data about delegated Top-Level Domains (TLDs) in each of these roots.  As justification of this: as the set of delegated TLDs continues to be critical for online services, and there exists the potential for new generic TLDs (gTLDs) to be added in the future, periodic measurements and longitudinal analyses are critical necessities for understanding the SSR of the global DNS.  This addresses strategic objectives 1, 2, 3, 4, and 5, as well as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1.  

@@@@ END DELETE

--       To address strategic objectives 1, 2, 3, 4, and 5, as well
as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1, ICANN should create (or commission the creation of) a framework for assessing and measures that codify the propagation delay of root zone changes to instances.

-       The IANA registries include many needed parameters that are
specified by RFCs in the IETF.  Their availability and integrity are paramount and needs to be clearly illustrated to the community.
At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time.  ICANN should create a set of measures that demonstrate the size, growth, and composition of the IANA registries, and also the global network availability of these registries.  These shall be measured, and archived (per above).

The data in these (and any other measurements) should be archived and made publicly available, along with any and all methodologies (to foster reproducibility). At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time.

_______________________________________________
Ssr2-review mailing list
Ssr2-review at icann.org
https://mm.icann.org/mailman/listinfo/ssr2-review

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.