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

Wed Oct 16 15:15:10 UTC 2019

Dear all, 

Apologies for missing today’s call. 
I agree with KC. We need to cut considerable amounts of material and this is one that I believe can go. 

Many thanks
Laurin 

> On Oct 16, 2019, at 11:13, k claffy <kc at caida.org> wrote:
> 
> 
> 
> 
> 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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmijx4%2Fedit%23&data=02%7C01%7Claurin.weissinger%40yale.edu%7C58252f7ee3ae4323fa3308d7524b67f7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637068356152044773&sdata=9GLSRohM6k%2FmS3HQ4Nev9Cm0eYoFxyMe8JhquAjD%2FzU%3D&reserved=0
> 
> 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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fssr2-review&data=02%7C01%7Claurin.weissinger%40yale.edu%7C58252f7ee3ae4323fa3308d7524b67f7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637068356152044773&sdata=mR5u3vpelnOyRvh8DLuCwUXvpYuoLjQpbwpx8Vgc7xo%3D&reserved=0
> 
> _______________________________________________
> 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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Claurin.weissinger%40yale.edu%7C58252f7ee3ae4323fa3308d7524b67f7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637068356152044773&sdata=8W%2Fc3CIRTw%2B6n9xBzVrS1KF0TfYHHrMwrl5X7gDLi20%3D&reserved=0) and the website Terms of Service (https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Claurin.weissinger%40yale.edu%7C58252f7ee3ae4323fa3308d7524b67f7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637068356152044773&sdata=xnD0SZO2AgbV3%2BbNBQOpuyQWA7pQGy9c4P3606lCzOU%3D&reserved=0). 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.