[ncdnhc-discuss] Re: About Alternative Naming Scheme: (was before Re: [ncdnhc-discuss] Re: Why is "Marketing ccTLDs as generics"on NC Agenda?)

[Jefsey Morfin]

Dear Vany, Jonathan and als.
I understand there are two different concerns in Vany's point. Naming plan 
management and NCDNHC membership.

1. the naming plan management.

Remarks and Vany's responses shows she is fully aware there are three 
places for the "root+"  information to be located: USG or inclusive root 
servers, ISPs, user system. ICANN position is that the best location is the 
USG root server what is reasonable if ICP-3 is modified as per Jun Murai's 
Sept 10th proposition. New.net position in the meanwhile is ISP. My own 
position is user system. These three positions are IMHO (as a root 
operator) exactly the same. I suppose that ICANN and mine will prevail.

The real problem Vany is rising is TLD squatting which is an important 
problem to protect the liberty of the users and TM owners. We addressed 
that problem in a consistent way with IANA, ICP-1, RFCs and ccTLDs in the 
"Root and TLD Best Practices" ( 
http://boroon.com/pdf_e/rcdc-05-E-RTBP-RootTLDBestPractices.pdf  ). I would 
be glad to review it further with everyone interested.

2. the adhesion to the NCDNHC of organizations using non universally 
accessible TLDs.

I disagree with any discrimination. People are free to manage their 
presence on the Internet the way they want. All the more than security and 
political issues are going to quickly develop the three approaches above in 
their entire diversity.

Jefsey



On 15:33 05/10/01, Jonathan Weinberg said:
>Vany --
>
>         The detailed technical information about how an ISP administrator 
> running Unix can resolve new.net names is found in 
> <http://www.new.net/help_isp_info.tp>.  For easy reference, here is a 
> portion of that page.
>
> >>>>>>>
>ISP Network Administrators:
>ISP's who would like to provide their users with immediate access to 
>New.net's™ domain names may do so by making one simple change to your systems.
>On each recursive nameserver that is serving clients, you may implement 
>any one of the options described below, assuming that you are using BIND 
>on a Unix box (if you are not, then please email us for further 
>information at: isp at New.net). Each of the following methods is roughly 
>equivalent, with each having a minor advantage or disadvantage over the 
>others. It is entirely up to you which you 'd like to pursue.
>After you've activated your network for New.net domains, we'll give your 
>service free promotional placement on our site. All you have to do is 
>email your logo to us and once we've verified that you've made the 
>necessary changes, we'll post your logo.
>First, please note that "BIND config directory" refers to the directory 
>listed in an options statement such as "/var/named" here:
>options {
>directory "/var/named/";
>}
>Here are four options you can choose from:
>
>1. Our preferred solution is that you use a list of stub zones to 
>supplement the ICANN roots with New.net domain extensions.
>For this option, do the following:
>Download ftp://ftp.New.net/domain/bind/root-stubs.conf into your BIND 
>config directory.
>Append the following line to your /etc/named.conf:
>include "root-stubs.conf";
>Reload the BIND configuration with the command "ndc reload".
>The list of stubs is expected to change up to once per month. You may wish 
>to set up a process to mirror root-stubs.conf weekly from New.net and 
>reload your nameserver if you use this method.
>2.Replacing the root.cache file with one that lists our new root servers.
>In /etc/named.conf, find the filename for ".".
>zone "." {
>type hint;
>file "named.root";
>};
>This file will be in the BIND config directory. In this case, it would be 
>"/var/named/named.root". Download 
>ftp://ftp.New.net/domain/bind/named.cache and overwrite the contents of 
>that file with it.
>Your server will grab a new list of root servers from those listed in the 
>hints file every time it starts up, and will use those for all queries.
>3. Alternatively, you may slave the root zone, ".", from a master DNS server.
>Download ftp://ftp.New.net/domain/bind/root-slave.conf into your BIND 
>config directory.
>In /etc/named.conf, find the section listing hints for ".", the root zone.
>They will look something like:
>zone "." {
>type hint;
>file "named.root";
>};
>Delete that section, and insert in its place:
>include "root-slave.conf";
>Reload the BIND configuration with the command "ndc reload".
>This will slave a copy of the root zone from a New.net master nameserver. 
>Your server will remain in sync with ours automatically.
>4. Fourth, if you have a mechanism already in place to publish 
>authoritative zones to all of your servers, you can use it to also publish ".".
>You will need to daily or weekly grab a copy of 
>ftp://ftp.New.net/domain/root.zone and publish it to your nameservers with 
>the zone name of ".".
>The root zone is nothing special as far as BIND is concerned. If your 
>nameservers know the information contained within it, they will not need 
>to query our servers for that.
>Please note, if your company does not have a mechanism for change control 
>publication, then you should not be considering this option. But if you do 
>have such a mechanism, then the method is to simply publish to root zone 
>information gathered from our ftp location , and publish as you would for 
>any other zone that you are authoritative for.
>We highly recommend that you check our ftp for updates regularly, and in 
>any event at least twice each week.
> >>>>>>>
>         I did read the email you sent articulating your concerns to the 
> NC; indeed, it was reading that message that prompted my comment, 
> yesterday, that "the questions you raise about [new.net] (relating, among 
> other things, to the possibility of conflicts and the fact that the names 
> do not universally resolve) apply no more strongly to them than to any 
> other alternate root."
>
>Jon
>
>
>At 11:16 PM 10/4/2001 -0400, Nilda Vany Martinez Grajales wrote:
>>Hi Jonathan and Dave:
>>
>>The information I described in my previus e-mail I took it from New.net
>>home page, except for the masquerading part.
>>The ISP has to upgrade their networks.  What they call upgrade their
>>networks is simply add some lines to the a file named resolv.conf if the
>>ISP is using linux.
>>If the ISP provided of an internet user still doesn't resolv new.net
>>domain names, then they have to install a software or provided by
>>new.net.
>>Again, New.net (and also other companies that are doing the same as
>>New.net), are not Alternate Roots...because the Root they are using
>>actual DNS structure in order to offer TLDs.
>>That New.net could be an innciative for expanding the domain name
>>space...maybe yes (maybe not)...but never an alternate root.
>>If you have read the answer I gave to Bill, the item 8 of the NC
>>teleconference agenda will become in "TLDs not created by ICAAN:  An
>>attempt to expand the domain name space or creates confusion".
>>Did you read the e-mail I sent today about the concerns I raised in the
>>NC two moths ago?
>>http://www.icann-ncc.org/pipermail/discuss/2001-October/000342.html
>>
>>Best Regards
>>Vany
>>
>>
>>
>>
>>Jonathan Weinberg wrote:
>> >
>> > At 12:26 PM 10/4/2001 -0700, Vany Martinez wrote:
>> > >Jonathan:
>> > >I have never asked to talk about Alternate Roots.
>> > >Again this was another confusion from who draft the
>> > >agenda.
>> > >Let call with proper names the things:
>> > >1.  An Alternate Root involves a server independent
>> > >from the actual roots that is resolving TLDs (.TRAVEL,
>> > >.GAME, .KIDS, etc, for example) different than the
>> > >ones created by ICANN, without using any technology of
>> > >masquerading an existent domain name within the actual
>> > >existent TLDs (.COM, .ORG, etc...).
>> > >2. The subject I am addressing is not Alternate Roots.
>> > >The subject I am addresing is the launching of
>> > >services as New.net and other Companies that uses and
>> > >masquerades actual domain names inside TLDs as .ORG,
>> > >COM, etc...in order to provide domain names inside
>> > >TLDs as .TRAVEL, .GAME, .KIDS, etc... If New.net want
>> > >to call themselves an Alternate Root, then is a bad
>> > >definition because they are functioning under the
>> > >actual Roots, maquerading existent domain names as we
>> > >know them to provide new TLDs, etc...And, such TLDs
>> > >are not resolved by everybody...only those who has the
>> > >software they download or the ISP has upgraded their
>> > >networks by adding some lines to their DNS
>> > >configuration, are the ones that are able to resolve
>> > >such domain names.
>> > [snip]
>> >
>> >          Actually, I think this misdescribes new.net.  Yes, they offer
>> > users a plugin that maps aaa.bbb to aaa.bbb.new.net.
>> > But it doesn't appear
>> > that the ISPs who partner with them are using that technique; rather,
>> > they're simply pointing to a set of new.net alternate root servers.  See
>> > <http://www.new.net/help_isp_info.tp>, which indicates that an ISP can
>> > resolve new.net names by (among other things) replacing its root.cache 
>> file
>> > with one that points to the new.net root servers.  So they are using 
>> *both*
>> > of the two technologies you describe above.  And fwiw I think the 
>> questions
>> > you raise about them (relating, among other things, to the possibility of
>> > conflicts and the fact that the names do not universally resolve) apply no
>> > more strongly to them than to any other alternate root.
>> >
>> > Jon
>> >
>> > _______________________________________________
>> > Discuss mailing list
>> > Discuss at icann-ncc.org
>> > http://www.icann-ncc.org/mailman/listinfo/discuss
>>_______________________________________________
>>Discuss mailing list
>>Discuss at icann-ncc.org
>>http://www.icann-ncc.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss at icann-ncc.org
>http://www.icann-ncc.org/mailman/listinfo/discuss