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

[k claffy]

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.