Being clear on the motivation for taking on the development and eventual deployment of DELEG is important to carry this work forward. I'll start with some pedantic observations about the abstract:
#Abstract # # A delegation in the Domain Name System (DNS) is a mechanism that # enables efficient and distributed management of the DNS namespace. "enables highly scalable distributed management of the DNS namespace." Rationale: The term "efficient" is rather vague especially in a context like this one where there is no metric for efficiency. The most endearing, if you will, facet of the DNS protocol design is its ability to scale to massive size and that deserves to be called out explicitly in any effort that has as grand a scale as DELEG. # It involves delegating authority over subdomains to specific DNS # servers via NS records, allowing for a hierarchical structure and Replace servers with nameservers (and be consistent, when covering "server", use "nameserver" (or "name server"). Replace "NS records" with "NS resource records". In general, use "resource records" to refer to the DNS data structure and "records" to the generic idea of grouped data. Replace the word "and" with "by" - the hierarchy enables distribution # distributing the responsibility for maintaining DNS records. # # An NS record contains the hostname of the nameserver for the An NS resource record contains only the hostname of the nameserver for the # delegated namespace. Any facilities of that nameserver must be delegated subdomain. The network address of the nameserver must be determined from other records, but other necessary information, such as service port number, assumed according to the defined protocol and thus hard coded. As a result of this is that the DNS protocol definition lacks the necessary flexibility to adapt to changing network environments. Any advanced capabilities of that nameserver must be # discovered through other mechanisms. This document proposes a new # extensible DNS record type, DELEG, which contains additional DNS resource record type, DELEG, to co-exist and ultimately replace the NS resource record, containing the necessary # information about the delegated namespace and the capabilities of information about the delegated subdomain and its # authoritative nameservers for the delegated namespace. authoritative nameservers for the purposes of increasing the flexibility of the DNS protocol. -------- Putting together my suggested abstract: A delegation in the Domain Name System (DNS) is a mechanism that enables highly scalable distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS name servers via NS resource records allowing for a hierarchical structure by distributing the responsibility for maintaining DNS records. An NS resource record contains only the hostname of the nameserver for the delegated subdomain. The network address of the nameserver must be determined from other resource records, but other necessary information, such as service port number, assumed according to the defined protocol and thus hard coded. As a result of this is that the DNS protocol lacks the necessary flexibility to adapt to changing network environments. Any advanced capabilities of that nameserver must be discovered through other mechanisms. This document proposes a new DNS resource record type, DELEG, to co-exist and ultimately replace the NS resource record, containing the necessary information about the delegated subdomain and its authoritative nameservers for the purposes of increasing the flexibility of the DNS protocol. ------ I think it is important to include "scalability" as it is a key factor in the DNS, and that the crucial need is "flexibility" in the protocol's definition. The first shapes DELEG, the latter is ultimately the reason for DELEG, and these ought to be in the abstract. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
