Skip to main content

RSSAC Meeting, Singapore

DNS Root Server System Advisory Committee
SUNTEC Convention Center
  • 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 bylaws
    • in ICANN JPA-MoU with the US Government
  • Jon Postel left.
  • Additional background
    • 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.
    Meeting Summary of RSSAC
    • March 2, 1999 10:00-15:00
    • 15 participants
      • Root server operators group
      • IETF/IAB
      • IEPG
      • RIRs
      • IANA staff
      • ICANN CEO
    Work Items
    • 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
    Other Issues discussed
    • 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
    Open part of this meeting
    • 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.

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."