The New gTLD Progam in CLASS IN is no more a swindle
The ICANN procedures are cute. They are not that easy to understand, follow and eventually comply with. However, they, from time to time, ultimately permit some transparency in order to show that it was possible not to pay ICANN for something small when you can get "samething" big for free (but without the ICANN legaleses). In the New gTLD Program case, I made an effort to try to save ICANN millions. You will find it at the URL http://forum.icann.org/lists/new-gtld-applicant-support-handbook/msg00013.ht.... I hope this demonstrate enough that ICANN and the US Governments are not crooks: - they only did not "underline" the full truth, as every good sales, at it results from the small prints - however, and I am the proof, they made nothing to prevent the truth from being published before the gTLD candidates send their requests and checks. The truth is that: 1. there is no technical difference between gTLDs and IDNgTLDs except non contractual foreign software application (punycode family of alogithms) TLD registrant cannot control. 2. ICANN uses a "de facto" situation to register TLDs that can be "de jure" (RFCs) replicated in 65,535 other DNS top level registries. 3. TLDs may use protected IRNs (International Root Names) by WIPO or ISO. The use of a string as a TLD does not protect it as an IRN. 4. ICANN stays at the IETF Internet end to end layers under the ignorance of the US Government. This is obsolete: IETF RFCs have already transparently made inteligent users to scale to fringe to fringe Internet+. http://iutf.org/wiki/Internet%2B_architectural_Framework. This makes clear that the ICANN Pew gTLD Program brings to its gTLD registrants is a very worked-out screen of paper to sign and an entry in the DNS CLASS "IN" (ICANN/NTIA) every of us can replicate, - in full right: in 255 other CLASSes - at least in test: in 65.375 other ones. If this was plainly stated in the Agreement, this would be perfectly honnest. As it is not, Courts may have to decide. However, in favor of ICANN: 1. my mail was published by ICANN within the Pew gTLD Program dedicated part, on a public forumeveryone could read. 2. RFC are publicly published and TLD would be Managers should know them to correctly operates the service they plan to sell. After several RFCs over the last 29 years of DNS operations, RFC 5395 states anew: "DNS CLASSes have been little used but constitute another dimension of the DNS distributed database. In particular, there is no necessary relationship between the name space or root servers for one data CLASS and those for another data CLASS. The same DNS NAME can have completely different meanings in different CLASSes. The label types are the same, and the null label is usable only as root in every CLASS. As global networking and DNS have evolved, the IN, or Internet, CLASS has dominated DNS use. [] The current CLASS assignments [] are as follows: This simply means that for each ".abcd" top-zone IDNgTLD paid K$ 185++ to ICANN, there can be 65,535 other ".abcd" top-zones in the DNS. Some will be immediatel because the IUTF is going to accept a few CLASSes for family protection, customer documentation, testing of third party applications, etc. jfc
On Wed, Jan 11, 2012 at 04:32:48PM +0100, JFC Morfin wrote:
This simply means that for each ".abcd" top-zone IDNgTLD paid K$ 185++ to ICANN, there can be 65,535 other ".abcd" top-zones in the DNS. Some will be immediatel because the IUTF is going to accept a few CLASSes for family protection, customer documentation, testing of third party applications, etc.
You only need to register the CLASS according to RFC6195 Section 3.2. Then you need to distribute an additional "root hint" file pointing to your new root servers (similar to http://www.internic.net/domain/named.root) As you can see, they only claim to be responsible for ./IN. Then you can start selling domains from your new root. Please allow me to add a professional advice. If you try to convince the browser manufacturers to ask for your class instead of IN, you might have a real market. -- Lutz Donnerhacke Maintainer of the TLD bofh. bofh. IN SOA jengate.thur.de. hostmaster.bofh. ( 2012011100 ; serial 28800 ; refresh (8 hours) 3600 ; retry (1 hour) 3600000 ; expire (5 weeks 6 days 16 hours) 57600 ; minimum (16 hours) ) bofh. IN RRSIG SOA 5 1 86400 20120120091622 ( 20120111101001 43652 bofh. l4M6OZon8M83st3nK49Jwg5QpMsoqMB9ZJGc8/SKocDh I4Mw/cjAXmkcXNe6aQPpEE+z93Jxh+d21wDSAvB/Chw2 c3MnSNRHGCn2+AZBsXEeHr9X7y0UDmdpZqBY2rNaLhFY mOblQQmy3PKHrgRiA84UoOEWeJeGLExjST15oqY= )
Hi, Two questions on this. - wouldn't he be looking for support of these new Classes in addition to Class IN, not instead? - doesn't this break because DNS Alias records pay no attention to Class and therefore aliased names would collide despite being in different classes? avri On 11 Jan 2012, at 11:47, Lutz Donnerhacke wrote:
On Wed, Jan 11, 2012 at 04:32:48PM +0100, JFC Morfin wrote:
This simply means that for each ".abcd" top-zone IDNgTLD paid K$ 185++ to ICANN, there can be 65,535 other ".abcd" top-zones in the DNS. Some will be immediatel because the IUTF is going to accept a few CLASSes for family protection, customer documentation, testing of third party applications, etc.
You only need to register the CLASS according to RFC6195 Section 3.2.
Then you need to distribute an additional "root hint" file pointing to your new root servers (similar to http://www.internic.net/domain/named.root) As you can see, they only claim to be responsible for ./IN.
Then you can start selling domains from your new root.
Please allow me to add a professional advice. If you try to convince the browser manufacturers to ask for your class instead of IN, you might have a real market.
-- Lutz Donnerhacke Maintainer of the TLD bofh.
bofh. IN SOA jengate.thur.de. hostmaster.bofh. ( 2012011100 ; serial 28800 ; refresh (8 hours) 3600 ; retry (1 hour) 3600000 ; expire (5 weeks 6 days 16 hours) 57600 ; minimum (16 hours) ) bofh. IN RRSIG SOA 5 1 86400 20120120091622 ( 20120111101001 43652 bofh. l4M6OZon8M83st3nK49Jwg5QpMsoqMB9ZJGc8/SKocDh I4Mw/cjAXmkcXNe6aQPpEE+z93Jxh+d21wDSAvB/Chw2 c3MnSNRHGCn2+AZBsXEeHr9X7y0UDmdpZqBY2rNaLhFY mOblQQmy3PKHrgRiA84UoOEWeJeGLExjST15oqY= ) _______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
On Wed, Jan 11, 2012 at 12:07:20PM -0500, Avri Doria wrote:
- wouldn't he be looking for support of these new Classes in addition to Class IN, not instead?
Then he has to change the basic assumption of RFC 1034 first: The database for any class is organized, delegated, and maintained separately from all other classes. Since, by convention, the name spaces are the same for all classes, the separate classes can be thought of as an array of parallel namespace trees. [...] Within a class, "cuts" in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region. Note that the "cuts" in the name space may be in different places for different classes, the name servers may be different, etc.
- doesn't this break because DNS Alias records pay no attention to Class and therefore aliased names would collide despite being in different classes?
CNAME processing is defined within a the same class as the queried class. In this way it's class independent, simply it's part of the algorithm, not part of the retured data. Same goes for NS, DS, etc. Because the databases are requried to be separate, a CNAME in one class can't influence an other one.
At 18:07 11/01/2012, Avri Doria wrote:
Hi, Two questions on this.
Hi! Avri, I will try to collect the questions raised and answer to produce and maintain an IUTF FAQ.
- wouldn't he be looking for support of these new Classes in addition to Class IN, not instead?
This is something the user is to decide in the way he/she config the ML-DNS. A class is like a language: a way to describe the network topology which is built by the addresses. There may be conflicts and overlaps. For exemple, let take the CLASS "FM" for families. Existing registries could have a filtered version of their "IN" CLASS registry pn their "FM" CLASS IRN (International Root Name) server.
- doesn't this break because DNS Alias records pay no attention to Class and therefore aliased names would collide despite being in different classes?
Lutz has addressed this. The IUTF basic principle is that what is a "MUST" decided by the IETF is a "IS" for the IUTF, something it is totally unable to change. CLASSes are of the essence of the IDNS for 40 years (even before the Internet). IDNS also initially included a reroute capacity as in the MX case, which might be of interest in the Web 2.0. Some other ideas may emerge. However, they can only come in addition, not as alternatives, and be operated in subsidiarity. This means also that not a single bit is to be changed in the underlaying protocols. Best jfc
On 11 Jan 2012, at 11:47, Lutz Donnerhacke wrote:
On Wed, Jan 11, 2012 at 04:32:48PM +0100, JFC Morfin wrote:
This simply means that for each ".abcd" top-zone IDNgTLD paid K$ 185++ to ICANN, there can be 65,535 other ".abcd" top-zones in the DNS. Some will be immediatel because the IUTF is going to accept a few CLASSes for family protection, customer documentation, testing of third party applications, etc.
You only need to register the CLASS according to RFC6195 Section 3.2.
Then you need to distribute an additional "root hint" file pointing to your new root servers (similar to http://www.internic.net/domain/named.root) As you can see, they only claim to be responsible for ./IN.
Then you can start selling domains from your new root.
Please allow me to add a professional advice. If you try to convince the browser manufacturers to ask for your class instead of IN, you might have a real market.
-- Lutz Donnerhacke Maintainer of the TLD bofh.
Lutz, I will try to collect the questions raised and answer to produce and maintain an IUTF FAQ. At 17:47 11/01/2012, Lutz Donnerhacke wrote:
You only need to register the CLASS according to RFC6195 Section 3.2.
Correct. However, this calls for an agreement between the different parties involved as the IDNS belongs to everyone. Compatibility is of the essence, as a use need, not as an engineering need. Therefore use (IUTF) must have its say as much as engineering (IETF) and possibly Govs if the ICANN/GAC was acknowledged by the IGF.
Then you need to distribute an additional "root hint" file pointing to your new root servers (similar to http://www.internic.net/domain/named.root) As you can see, they only claim to be responsible for ./IN.
Then you can start selling domains from your new root.
The target is not to start selling. It is to document properly the way the entire IDNS is to work to the benefit of the whole digital ecosystem (WDE) users. Once this documentation is clear, stable and accepted there will certainly be profit and non-profit registries and operators. However, the IUTF has identified the necessity for IDN (International digital names) to be life-long for URI stability for exemple, TM protection, personnal identity right, etc. IDNs are not specially related to the Internet. Therefore the registry job in this context is different, and most probably legal. The, DNS and ML-DNS services will call for operators to support zones and most probably new services. Also, the development of IPv6 (as a young protocol) will most probably lead to new development. In particular I would support the notion of "environment conversion", this would mean to consider that by default the Internet+ is non-profit. However, if a commercial (declared as such) host is involved, it may change the environment to for-profit, with new rules applying. This is a notion to certainly look at within the neutrality context.
Please allow me to add a professional advice. If you try to convince the browser manufacturers to ask for your class instead of IN, you might have a real market.
The IUTF role is purely architectural. It is to document the way the Internet+ works should work for users to more adequately benefit from it. The difficulty with current application manufacturers is that they believe that when the user uses their application, the application is the center of the world. And they want to be smarter than the user, guiding him/her with their ideas. Actually, what the Internet+ means is that the center of the world is the user: he/she/it decides of the context in which the application operates. Building that network context is not the job of the appcation but of the IUI. The browsers are to be transparent as every other application. They have no responsibility in determining the language, the CLASS, the script, the encryption, etc. This belongs to the Presentation layer and is the job of the single preDNS function in the ML-DNS [ML-DNS is actually a smart front-end of the Internet DNS]. So the issue is the architecture of the ML-DNS as the *single* smart interface between UTF-8 transparent CLASSless applications and the ASCII/CLASS context. With possibly its own multiclass root system. The matter is a matter of power and size. The architecture must be able to scale, i.e. to support millions of TLDs. This is not going to be done with the RSS and 96% of erroneous requests. The requests must be locally addressed, so the root is to be local and only list the IRN (International Root Names) the user is interested in, hinting the Root Name Servers by the operator he favors. Best. jfc
By any chance are you a relative of Jeffrey Williams ? -J On Jan 11, 2012, at 9:32 AM, JFC Morfin <jefsey@jefsey.com> wrote:
The ICANN procedures are cute. They are not that easy to understand, follow and eventually comply with. However, they, from time to time, ultimately permit some transparency in order to show that it was possible not to pay ICANN for something small when you can get "samething" big for free (but without the ICANN legaleses).
In the New gTLD Program case, I made an effort to try to save ICANN millions. You will find it at the URL http://forum.icann.org/lists/new-gtld-applicant-support-handbook/msg00013.ht....
I hope this demonstrate enough that ICANN and the US Governments are not crooks: - they only did not "underline" the full truth, as every good sales, at it results from the small prints - however, and I am the proof, they made nothing to prevent the truth from being published before the gTLD candidates send their requests and checks.
The truth is that:
1. there is no technical difference between gTLDs and IDNgTLDs except non contractual foreign software application (punycode family of alogithms) TLD registrant cannot control.
2. ICANN uses a "de facto" situation to register TLDs that can be "de jure" (RFCs) replicated in 65,535 other DNS top level registries.
3. TLDs may use protected IRNs (International Root Names) by WIPO or ISO. The use of a string as a TLD does not protect it as an IRN.
4. ICANN stays at the IETF Internet end to end layers under the ignorance of the US Government. This is obsolete: IETF RFCs have already transparently made inteligent users to scale to fringe to fringe Internet+. http://iutf.org/wiki/Internet%2B_architectural_Framework.
This makes clear that the ICANN Pew gTLD Program brings to its gTLD registrants is a very worked-out screen of paper to sign and an entry in the DNS CLASS "IN" (ICANN/NTIA) every of us can replicate, - in full right: in 255 other CLASSes - at least in test: in 65.375 other ones.
If this was plainly stated in the Agreement, this would be perfectly honnest. As it is not, Courts may have to decide.
However, in favor of ICANN:
1. my mail was published by ICANN within the Pew gTLD Program dedicated part, on a public forumeveryone could read.
2. RFC are publicly published and TLD would be Managers should know them to correctly operates the service they plan to sell. After several RFCs over the last 29 years of DNS operations, RFC 5395 states anew: "DNS CLASSes have been little used but constitute another dimension of the DNS distributed database. In particular, there is no necessary relationship between the name space or root servers for one data CLASS and those for another data CLASS. The same DNS NAME can have completely different meanings in different CLASSes. The label types are the same, and the null label is usable only as root in every CLASS. As global networking and DNS have evolved, the IN, or Internet, CLASS has dominated DNS use. [] The current CLASS assignments [] are as follows:
This simply means that for each ".abcd" top-zone IDNgTLD paid K$ 185++ to ICANN, there can be 65,535 other ".abcd" top-zones in the DNS. Some will be immediatel because the IUTF is going to accept a few CLASSes for family protection, customer documentation, testing of third party applications, etc.
jfc
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/at-large
At-Large Official Site: http://atlarge.icann.org
participants (4)
-
Avri Doria -
JFC Morfin -
Jorge Amodio -
Lutz Donnerhacke