Root Zone Management Changes Process Overview

 
HOW CHANGES TO ROOT
ZONE MANAGEMENT ARE
REQUESTED
 
David Conrad
ICANN CTO, 
but speaking in a 
personal capacity
 
TL;DR
 
In the past
No one was quite sure, but defaulted to NTIA
 
Now
No one is quite sure, but probably the RZERC
 
BEFORE THE TRANSITION
 
Nothing clearly defined
.
For example, signing the root
1.
Many years of technical community saying “Hey! Let’s sign the root!”
2.
<crickets>
3.
ICANN Board and other bodies saying “Hey! Let’s sign the root!”
4.
<rustling>
5.
Kaminsky attack
6.
<panic>
7.
NTIA says “ICANN and Verisign, give us proposals to sign the root.”
8.
ICANN and Verisign provide proposals
9.
NTIA uses some internal process, chooses Verisign’s proposal
10.
Root (eventually) gets signed
 
STEWARDSHIP OF IANA FUNCTIONS
CONTRACT TRANSITION
 
NTIA goes away
“The Multi-Stakeholder Community”
via the “Empowered Community”
single membership replaces NTIA’s
oversight role
New entities created:
Public Technical Identifiers (PTI) –
wholly-owned (by ICANN) affiliate
company to which ICANN outsources
IANA Functions
PTI Board: 2 ICANN staff appointees, 2
community appointees, PTI president
Customer Standing Committee (CSC)
Root Zone Evolution Review
Committee (RZERC)
Myriad of new IANA Functions review
committees
 
ROOT ZONE EVOLUTION REVIEW
COMMITTEE
 
RZERC provides advice to the ICANN Board on changes to the root zone
management systems
NOT
 on how root servers are operated
Process by which this is done being defined (I think)
ICANN Board makes decisions with input from RZERC (among others)
 
“ICANN”?
 
Which 
ICANN?
The Community
The Board
The Organization
The IANA Functions Operator
 
ICANN-the-Organization does what
ICANN-the-Community or ICANN-the-
Board tells it to
ICANN-the-IANA Function Operator
does what ICANN-the-organization
(via contract) or ICANN-the-
Community (via CSC or RZERC) tells
it to
 
HOW TO GO ABOUT REQUESTING
NEW FEATURES?
 
I don’t think anyone knows for sure, but a few options...
 
Option 1: “Shame on IANA”
IANA Staff’s freedom to implement enhancements is tightly constrained
Option 2: get the IETF/IAB or other body to make a statement
Might work, might not (see the IAB statement on the RPKI root)
Option 3: go through ICANN’s Board
Will probably (should?) get bounced to RZERC for advice
Option 4: go through the RZERC
Process not yet set, but envisioned to provide advice on root system evolution
Slide Note
Embed
Share

Understanding how changes to root zone management are requested, the transition from NTIA oversight, and the role of the Root Zone Evolution Review Committee (RZERC) in advising the ICANN Board on root zone management changes.

  • Root Zone Management
  • ICANN
  • RZERC
  • NTIA Transition
  • Internet Governance

Uploaded on Sep 22, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. HOW CHANGES TO ROOT ZONE MANAGEMENT ARE REQUESTED David Conrad ICANN CTO, but speaking in a personal capacity

  2. TL;DR In the past No one was quite sure, but defaulted to NTIA Now No one is quite sure, but probably the RZERC

  3. BEFORE THE TRANSITION Nothing clearly defined. For example, signing the root 1. Many years of technical community saying Hey! Let s sign the root! 2. <crickets> 3. ICANN Board and other bodies saying Hey! Let s sign the root! 4. <rustling> 5. Kaminsky attack 6. <panic> 7. NTIA says ICANN and Verisign, give us proposals to sign the root. 8. ICANN and Verisign provide proposals 9. NTIA uses some internal process, chooses Verisign s proposal 10. Root (eventually) gets signed

  4. STEWARDSHIP OF IANA FUNCTIONS CONTRACT TRANSITION NTIA goes away The Multi-Stakeholder Community via the Empowered Community single membership replaces NTIA s oversight role New entities created: Public Technical Identifiers (PTI) wholly-owned (by ICANN) affiliate company to which ICANN outsources IANA Functions PTI Board: 2 ICANN staff appointees, 2 community appointees, PTI president Customer Standing Committee (CSC) Root Zone Evolution Review Committee (RZERC) Myriad of new IANA Functions review committees

  5. ROOT ZONE EVOLUTION REVIEW COMMITTEE RZERC provides advice to the ICANN Board on changes to the root zone management systems NOT on how root servers are operated Process by which this is done being defined (I think) ICANN Board makes decisions with input from RZERC (among others) SSAC: Russ Mundy IETF: Jim Reid RZM (Verisign): Duane Wessels RSSAC: Brad Verd GNSO RySG: Howard Eland ICANN Board: Suzanne Woolf ASO: Carlos Martinez ccNSO: Katrina Sataki IFO (PTI): Kim Davies

  6. ICANN? Which ICANN? The Community The Board The Organization The IANA Functions Operator ICANN-the-Organization does what ICANN-the-Community or ICANN-the- Board tells it to ICANN-the-IANA Function Operator does what ICANN-the-organization (via contract) or ICANN-the- Community (via CSC or RZERC) tells it to

  7. HOW TO GO ABOUT REQUESTING NEW FEATURES? I don t think anyone knows for sure, but a few options... Option 1: Shame on IANA IANA Staff s freedom to implement enhancements is tightly constrained Option 2: get the IETF/IAB or other body to make a statement Might work, might not (see the IAB statement on the RPKI root) Option 3: go through ICANN s Board Will probably (should?) get bounced to RZERC for advice Option 4: go through the RZERC Process not yet set, but envisioned to provide advice on root system evolution

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#