[ga] JCB's post

[Jefsey Morfin <jefsey@wanadoo.fr>]

Dear JCB,
I am afraid you totally misses all the points here. What is IMHO a
positive thing: I will explain why in the second part.

    For you may be to understand. Let assume you drive your car and
    the rules of the road are sligtly altered: people having the same car
    as yours are not bound from now on to stop at red lights when you
    cross their road. I do not know what is your car, but I suppose there
    are chances that there are less than .5% of the cars of the same
    make and same color as yours, so why would you bother.

    I suppose you would however be unhappy. Interesting unhappiness:
    you decide to go by the rules of the road as long as they do not
    change... but you become unhappy with them.

    I am sure you see the flaws in my reasoning. Because I am talking
    in a superficial way of an issue I did not really learned about and I did
    not discussed with others seriously.

My point is simply this: non-legacy TLDs are a part of the more general
matter; the iCANN's approach/management of the Inclusive Name Space
(i.e. the whole part of the Name Space that is concerned by the DNS). This
policy (which affects all the TLDs) is to be understood, controled and advised
as a whole by the DNSO according to its charter. To be able to do that,
Danny Younger is right, we need a WG-Inclusive Name Space Management.
But we have first to have a self education, a non-fighting agreement on some
issues, and to come with a documented proposition to the BoD and to the NC.

Your mail as many others demonstrates that need. I am sure that in a few
weeks - if you participate to such an SIG ML - you (all of us) will have 
far more
relevant, structured and documented propositions to support your/our positions
(even it the stay the same: may be you are right, may be I am. Let work on
it and try to see if non consensus is possible).

Cheers.
Jefsey


PS. If I may recall you: iCANN must work by consensus. The is obviously
        non consensus on the matter, so any action by the iCANN on this
        matter is a de facto power abuse. Working together to reduce the
       disagreement is the only way to have the iCANN legally and efficiently
       go ahead. What I am sure is what you want.




On 22:24 14/04/01, John Charles Broomfield said:

>So, if I understand you correctly, what you're saying is that the ICANN
>action of adding their own ".biz" to their own root-zone (the one which you
>guys download from rs.internic.net), actually messes up the way that you
>later add to to it.
>
>Interesting concept that you decide to use the USG authoritative as long as
>it doesn't change, but if it DOES change, then you scream about it.
>
>Of course, one must understand that the amount of individuals that this
>actually affects (ie the ones that resolve through some method that actually
>adds things to the generic vanilla USG/ICANN root) is rather minimal (what
>was the last good count on it? less than .5% of the 'net?), and to take it a
>step further, this would then only REALLY affect those people who actually
>use a domain name under ".biz" which is visible through those alternative
>servers. So, it's *probably* only a fraction of that .5% (who knows, maybe
>100 individuals in all???). And of those that it DOES actually affect, it's
>*probably* only people who were playing around on a technical basis, and not
>actually on an operational basis (I defy ANYONE to show me someone that will
>really be affected by the introduction of ".biz" into the USG/ICANN roots,
>apart from some company selling non-ICANN .biz names and finding that it
>actually sheds light on what they are REALLY doing, ie selling air).
>
>Now, if you actually do think that there is a customer base out there who
>actually uses the non-ICANN ".biz" on a daily basis, then what is your
>problem with the ICANN one, as your CURRENT user base will continue to use
>their old one without a hitch!
>
>You can't have it both ways:
>-either you consider ICANN as authoritative and you decide to add to
>  whatever ICANN throws at you (so continue adding to the ICANN one, and
>  understand that as ICANN is authoritative, then *your* additions are flaky
>  to say the least).
>-or your consider YOURSELF to be authoritative and say to hell with ICANN,
>  and play in your own sandbox with whatever names you want.
>
>Of course, you've probably realized that considering yourself authoritative
>is a bit of a non-starter in each case where ICANN has its version of what
>you want to add, so you know that ICANN is authoritative. Given that,
>instead of bowing to ICANN (which throws your private ideas into disarray),
>you try to do a 50% stand and somehow convince the rest of the world that
>you are just as trustworthy as ICANN, so your own TLDs should be taken into
>account etc...
>
>However, seeing that ICANN doesn't consider you as such (and they shouldn't
>really, because every morning a new set of kids discovering BIND invents
>their own playground to play in, so considerinng you above the bunch somehow
>gives you an unmerited privilege), that only leaves you the 
>yell-kick-and-scream tactic.
>
>At the base of it, there can only be ONE authoritative root-zone. You say
>that the ICANN one is done without co-operation. What you mean is that YOU
>didn't get to have a disproportionate amount of say in it, but there has
>been a hell of a lot of political pushing & pulling (which out there is
>called cooperation) to get it to the current state. Then again, there are
>people who live in the USA who don't recognize the USA Government as
>legitimate... (but they don't generally go ranting around trying to get the
>rest of the country to believe that THEY are legitimate instead.)
>
>Yours, John Broomfield.
>
> > > I don't understand this.
> > > How does the Neustar/ICANN .biz change the situation for
> > > users/ISPs who chose to "enhance" their settings and point to
> > > the alternate roots? Those people will continue seeing the
> > > AtlanticRoot .biz, and would not even know that USG has added .biz.
> >
> > Yes and no, you have to understand the way the Inclusive Root system works,
> > currently.
> > It all starts with the USG root zone file, as a kernel. It is fetched from
> > http://rs.internic.net and then the new TLD refernces are added. These
> > additional TLDs can be anything an individual wants. but, the Inclusive 
> Root
> > operators use a validated and filtered list of new TLD references. MHSC
> > starts with the ORSC root-zone, which is filtered manually by Richard
> > Sexton. MHSC's root zone is not strictly ORSC because we add our own 
> private
> > TLDs, which are not in the ORSC list (maybe a moot point, at this time
> > <sigh>).
> >
> > Currently, everything is "peaches" because the kernel zone file is
> > effectively static and all the new TLDs are being added to it. There is a
> > vetting process and a list of policies that govern which TLDs get added and
> > which ones don't. There are many TLD claimants that are NOT in the ORSC
> > root, nor are they in the MHSC root. Yes, this sort of places Sexton in
> > Postel's position WRT ORSC (for the record, MHSC uses its own "services"
> > files as well).
> >
> > Where this becomes a problem is when ICANN deliberately adds a TLD in
> > conflict with one of the existing vetted Inclusive Root TLDs, like BIZ. No
> > longer, can we simply copy the existing kernel. According to Inclusive Root
> > policies, the new TLD would not qualify because it is in-conflict and
> > doesn't pass the FCFS bar. From a policy perspective, this opens a 
> great big
> > ICANN o' wurms. One that many of us would rather leave sealed. One of the
> > reasons the Inclusive Root System works well is that EVERYONE agrees on the
> > content of the kernel. They ALL get it from the USG. Regardless of which
> > root-zone publisher, the kernel remains the same.
> >
> > Unlike ICANN, the Inclusive Root operators practice "First Come, First
> > Served" (FCFS) with almost religious zeal. Mainly, because it is a "first
> > principle" that almost anyone can agree on (except ICANN, of course). It is
> > almost the only thing that all the various root-zone operators CAN 
> agree on.
> > Even the ICANN has a hard time making a case against FCFS, as a primary
> > policy. Instead, what ICANN does, is to define whom is "First". This is a
> > lot like Bill Clinton's weasel-words regarding the meaning of "is". It
> > barely saved his butt, however, no one was really convinced and everyone
> > knew what the real score was. The same applies to ICANN's use of FCFS.
> >
> > What all of the above means is that, if ICANN adds the NeuStar BIZ, 
> then the
> > Inclusive Root Zone operators would have to, by their own rulz, 
> specifically
> > remove the NueStar entries prior to incorporating the USG root zone kernel.
> > Not all of them will do that reliably. This introduces entropy into the
> > Inclusive Root system. Unlike cryptographic randomness, entropy is NOT good
> > for production systems.
> >
> > > The decision would not "destroy" the business: the business
> > > will collapse if registrants will massively register in ICANN's
> > > .biz and not in AR's .biz, while it will stay healthy if things
> > > happen the other way around. It is true that USG should not
> > > destroy a business, but should also not be obliged to rescue a
> > > business that goes belly up due to competition.
> >
> > You are missing a connector here. If it can be shown that adding the 
> NeuStar
> > BIZ TLD will forseeably have the effect that you mention here (and that is
> > very difficult to dispute) then we can establish a causal relationship
> > between the addition of the TLD and the effect on ARNI's BIZ. Ergo, the
> > simple addition of the NeuStar BIZ TLD, in the DOC root zone, would
> > destablize ARNI's BIZ registry. Since DOC is a branch of the USG and 
> ARNI is
> > a US company engaged in a lawful business, the USG would be in violation of
> > its own Constitution. I might point out, before anyone else does, that the
> > USG is already in violation of various other parts of its own Constitution
> > [The US has been in a continuous State of Emergency since 1952, with 
> various
> > executive over-rides on parts of the US Constitution being applicable
> > (Korean War, Viet Nam, Cold War, War on Drugs, etc, old argument, we need
> > not go there)].
> >
> > [IANAL - I Am Not A Lawyer. Before taking action on anything I say, you are
> > encouraged to seek legal advice. ]
> >
> > > If you want to argue that this is a bully attitude from ICANN, that 
> may be
> >
> > > true, but OTOH there has been no bid by AR for .biz (contrary
> > > to IOD's bet for .web), so I don't see what could ICANN have done. 
> Reserve
> >
> > > it for future use, maybe?
> >
> > Actually, the ICANN isn't the issue. USG/DOC/NTIA is. That the ICANN places
> > them in this position isn't good for ICANN. It could back-fire. IF DOC
> > doesn't add BIZ, regardless of the reasons, ICANN status is much reduced.
> > The first rule of leadership command is to NEVER give an order that
> > can't/won't be obeyed. If DOC does add the TLD and it results in the 
> turmoil
> > that is likely to ensue, then DOC has the easy way out of disassociating
> > itself from the ICANN (once DOC recovers the fumble). What ICANN did, in
> > MDR, was a high-risk move with a very narrow margin of success, without
> > properly appreciating the downside risks involved. They had a glimmer,
> > because of WEB, but various factions succeeded in installing blinders wrt
> > BIZ. In the side-room discussions, everyone was aware of ARNI's BIZ. Some
> > arrogant idiots were even looking forward to the conflict, not realizing
> > what everyone loses thereby.
> >
> > --
> > IANAL - I Am Not A Lawyer. Before taking action on anything I say, you are
> > encouraged to seek legal advice.
> > --
> > ROELAND M.J. MEYER
> > Managing Director
> > Morgan Hill Software Company, Inc.
> > TEL: +001 925 373 3954
> > FAX: +001 925 373 9781
> > http://www.mhsc.com
> > mailto: rmeyer@mhsc.com
> >
> >
> > --
> > This message was passed to you via the ga@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
>
>--
>This message was passed to you via the ga@dnso.org list.
>Send mail to majordomo@dnso.org to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html