RSSAC Meeting, Singapore
- Introduction
- Background/Charter
- Members
- Issues/Tasks
- Future schedule
- Open meeting planning
Initial reasons for RSSAC
- Root Server System issues have been addressed
- in the Green Paper and White Paper process
- in the formation of ICANN.
- Root Server System Advisory Committee (RSSAC) mandated
- in ICANN JPA-MoU with the US Government
- Changes in the root server system have been discussed inside and outside of the US government for over two years. As part of the Green Paper and White Paper process, it was agreed that the entire system would be reviewed as part of the formation of ICANN to assess its current state and possible areas where improvement might be needed.
- Consequently, a specific provision for a Root Server System Advisory Committee (RSSAC) was included in the bylaws from the beginning.
- The passing of Jon Postel left some policy issues and some day-to-day operational concerns without clear direction. It is important to note that he set up a reliable system that has continued to function without him, but these issues need to be addressed in a way that protects both the short term and long term operational stability of the Net.
- March 2, 1999 10:00-15:00
- 15 participants
- Root server operators group
- IETF/IAB
- IEPG
- RIRs
- IANA staff
- ICANN CEO
- To write technical procedures for operation of the primary root server including procedures that permit modifications, additions or deletions to the root zone file.
- To make the management of the root server system more robust and
secure:
- Operational requirements of root name servers, including host hardware capacities, operating system and name server software versions, network connectivity, and physical environment.
- Examination of the security aspects of the root name server system and review of the number, location, and distribution of root name servers considering the total system performance, robustness, and reliability.
- Development of operational procedures for the root server system, including formalization of contractual relationships under which root servers throughout the world are operated.
- To design, develop, and test a plan for addressing the operational
issues raised by possible expansion of the
number of gTLDs. The designed process should consider and take into
account the following:
- New gTLDs
- IPv6 deployment
- Security issues
- Future Relationship with other groups
- IETF related WG for large scale DNS operations (large/many zones)
- RFC2010 revision
- ICANN SOs - ASO/DNSO policy and operations decisions will need coordination with root nameserver operation
- Y2K problems
- do the root servers have a Y2K problem? It does not seem so but further investigation is required.
- What formal statement/report/certification will need to be made on this?
- Risk Management
- The ICANN Board is responsible for appointing the initial chairman of the RSSAC, which it did at its meeting of 1/17/99 by appointing Jun Murai.
- It is anticipated that the chairman will nominate an initial slate of members for the RSSAC.
- It is not required that the committee have a specific number of members, nor that the full complement of members be appointed immediately.
- It has been the group consensus so far that it needs to include: Root nameserver operators, DNS, and Topology area technical experts.
- The second meeting of RSSAC IETF/Minneapolis (March 15-19), Tuesday, March 16.
- Expected initial output draft after the second meeting
- preliminary list of milestones tbd in Minneapolis
- initial draft(s) for internal review around March 31, 1999(?)
- Mailing list for committee's work to be established
- Introduction/background
- Work Items
- Members
- Hearing requirements
- Discussions
- Announcement of the 2nd meeting
The Chair made sure interested observers at the open portion of the meeting had the background and mission of the committee explained. Some questions were taken from a couple of observers.
Adjourned approx. 15:00.