... We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity."
What else does the IETF need to do here?
issue an rfc. iab is not a representative body, and their opinions are not "refereed."
On 23.09 14:34, Paul Vixie wrote:
What else does the IETF need to do here?
issue an rfc. iab is not a representative body, and their opinions are not "refereed."
brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ... Daniel
On 23.09 14:34, Paul Vixie wrote:
What else does the IETF need to do here?
issue an rfc. iab is not a representative body, and their opinions are not "refereed."
brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ...
Daniel
you missed a step... approve(iesg, wildcard-clarify);
On 23.09 08:43, bmanning@karoshi.com wrote:
brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ...
you missed a step...
approve(iesg, wildcard-clarify);
I *said* "wait(unspec);" didn't I? ;-( Note: Concurrent processes run faster if they have no interdependencies. end
-----BEGIN PGP SIGNED MESSAGE----- Paul Vixie wrote:
We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity."
What else does the IETF need to do here?
issue an rfc. iab is not a representative body, and their opinions are not "refereed."
I wonder btw why Verisign didn't catch the "typo's" in their own domains if they think it is that important: 8<--------------------- ; <<>> DiG 9.2.3rc2 <<>> wwww.verisign.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31401 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;wwww.verisign.com. IN A ;; AUTHORITY SECTION: verisign.com. 3600 IN SOA localhost.verisign.net. vshostmaster.verisign.com. 2003091501 10800 3600 604800 3600 ;; Query time: 165 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Sep 23 16:51:56 2003 ;; MSG SIZE rcvd: 106 - ----------------------->8 no mistyping wwww there :) BTW, that SOA record doesn't exist... 8<--------------------- ; <<>> DiG 9.2.3rc2 <<>> localhost.verisign.net. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;localhost.verisign.net. IN A ;; AUTHORITY SECTION: verisign.net. 3570 IN SOA bay-w1-inf5.verisign.net. vshostmaster.verisign.com. 2003091501 10800 3600 604800 3600 ;; Query time: 32 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Sep 23 16:55:48 2003 ;; MSG SIZE rcvd: 113 - ----------------------->8 Hmmm, suddenly another SOA on the same zone, this SOA does exist though. Odd DNS software they are running over there :) And apparently they can return NXDOMAINS after all. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP3BgwSmqKFIzPnwjEQK18wCfc95MR1wwV6vxDYtjtRLiuUuOLQkAoLzL +ksSp4pgzPqouqxTgDIn1VTd =DNLO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Paul Vixie <paul@vix.com> wrote:-
We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity."
What else does the IETF need to do here?
issue an rfc. iab is not a representative body, and their opinions are not "refereed."
Yes indeed, but one has to ask the question "What about ICANN's recommendations?" and what they might have to do to have them implemented. As an outsider to the politics of ICANN, registries, registrars and the like, it boggles my mind that Verisign, a company issued with a contract by ICANN to run a gTLD, should be able to make technical changes which cause significant breakage (and hence cost the Internet community to fix/workaround), and should then be quite so demonstrably unwilling to accept ICANN's polite request. It seems to me that there must be something seriously broken in the procedures or contracts that a situation such as this could occur. The consensus technical view seems to be that the wildcard introduction has been a destabilising influence and yet ICANN, who are charged with the responsibility of ensuring the stability of the Internet, seem powerless to do anything about it. It's all most bizarre! Best wishes, Matthew -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAgUBP3CPCwKwLwcHEv69AQGUKwP/dXTWek8Zh2fjGqjLjjhKJSY+y2FPYObI 0Q8o1IgCumuGxPlARDcy4JxZAzGa6NmU5bLyLSfLtJwZoSDeMCyvu4zVDUy5kfMN As0KrXVrkgEl8eRh1mZrQGdkf3SQIrhYhugAfX5LRBxZwMn3lcFMAhw1qUKJ+km5 IKtSQztc/sM= =kB7Y -----END PGP SIGNATURE-----
participants (5)
-
bmanning＠karoshi.com -
Daniel Karrenberg -
Jeroen Massar -
matthew-l＠itconsult.co.uk -
Paul Vixie