comments
I agree with Karl that this is a good start. I agree with the general idea of his final comment. But I think we have different cases to consider in a global DNS perspective. (1) we have to work in the ICANN ICP-3 context or all this will not be of use. This means we are to test, prepare, and organise a situation where the DNS has no more a unique root file. This is mandatory in the Multilingual Internet context where various DNS solutions are already in use (stubs, keywords, alias [local keywords]), leading to de facto quasi individual virtual root files. In addition, we do not know yet how the bulk of ML TLDs will be supported (NS, DNAME, or other?) In such a context, and if we consider the current situation, we will most probably have several DNS referents: organisations like the IANA which will intergovern the global namespace through the addition of their root files. This may be politically contentious, procedures may differ, etc. however, it would be advisable that test tools be the same or equivalent, in the best interest of the network stability and of the users. For political reasons it is not possible to gather them in a WG, but it is possible to design and develop open source test tools their members can discuss/adapt. The IANA listed requirements is a good starting points - I am not sure I understand all the Verisign requirements. But it does not covers DNSSEC and non rooted various "user level domains" (ULDs, all what is perceived by users as a self governed top/independent namespace: TLDs, pseudo-TLDs, SLDs, keywords, aliases). (2) there are three types of namespaces: (a) The TLDs which have a contract with a referent (ICANN s/gTLDs), (b) sovereign TLDs which are only referred to, in one or several referent root files (ccTLDs, MLTLDs to come, private/national/corporate TLDs), (c) standalone namespaces of various type and making (keywords, aliases, local systems, possible innovations). The best would be to have a universal test (1) discovering the nature of a namespace, (2) documenting its features, (3) and lacks of consistency. Such a "naming consistency" tool should be designed in a way everyone could run it and verify the QoS of the namespace he/she use. It should also permit to maintain comparative situations in running it from different places. Some may object to the concept of non-IANA TLDs being tested. (1) this will not prevent them from existing (2) it would be advisable to target a universal test tool that can also verify private network consistencies. (3) this should be carried at the same time as the writing of a BCP on the best way to support user virtual roots, at ISP or private networks level, and to consistently organise and support keywords services and alias tables. There are IP and political considerations involved: this leads to think that this will be considered by the IGF . A parallel IETF/IAB technical discussion, guidance, and documentation would be advisable. jfc |