ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] ICANN not a Governing Body


Jefsey I urge caution here,

The definition of Governing is really a very tough issue and we have to
be straight
on it.  We grappled with this, and to my understanding there was no
consensus,
within the WG-Review.

In one context we simply mean guidance, in another we mean a dictator. 
Also the
term leaves pejorative feelings.  Here, the Republicans don't like
government and
the Democrats do.  But that is not true at all they both love
government, that is
what they do after all, but not really.  Think of that particular word,
governess
or that device they place on vehicles and engines called a governor. 
Remember just
a little bit ago, the term governor was like a respectful greeting to a
man who
governed his estate, no matter how small, I think Dickens made great use
of the
term to delineate social classification.

My point is that if we stick ICANN into or out of a classification then
we cause
problems that are not necessary.  When I write policy, and this is a
secret, when I
do not want to make it too specific I use the term Government.  If my
children did
not have their wonderful mother I would be a dictator, but alas I am
only an
advisory body to her governance, but nevertheless I help govern and so
does ICANN.

I hope this clarifies and does not cause derisiveness gov.

ICANN makes major contributions to the policy and governance of the
Internet. Most
assuredly someone or something must, or we have anarchy.  Which is why
we must
welcome Mr. Corliss, we must embrace these alternative netstyle guys, or
we start
walking a bad road to no "Governance". (as in no self restraint &
embattlement).

The APA applies when the U.S. "gov" lets someone else practice control
over a U.S. resource.  From running the Colorado on a boat through the
grand canyon, to cattle graizing leases, to Satellites and Super
Computers this is how we do it.  Therefor technically we may be correct
in saying it is not a governing body, but that is all we get - a
technical distinction, like some lawyer might make. Nothing helpful to
understanding.

IMHO Sincerely,

Jefsey Morfin wrote:

> Dear Patrick,
>
> On 15:26 01/04/01, Patrick Corliss said:
> >Hi Jefsey
> >ll start by changing the subject heading to align with the thread, if I may.
>
> I will revert the subject to something appropriate: as I never considered and
> will never consider the iCANN as a governing body. My whole attitude is
> based upon the fact that iCANN is not a governing bidy and those trying to
> make it a governing body through (among others) :
> - relations with USG and GAC
> - TLD model
> - UDRP standardization
> - letter to givernements
> - Plan B
> - .org review
> - .biz take away
> etc.. etc...
> are hurting deeply the Internet, the iCANN interests and the network stability.
>
> >On Sunday, April 01, 2001 10:19 AM (AEST), Jefsey Morfin wrote:
> >Subject: Re: ITU and BIND configs (Re: [ga] GA position on Verisign contract)
> >On 14:10 29/03/01, Harald Tveit Alvestrand said:
> > > >as new.net has demonstrated, they WILL conflict, unless one has a
> > > >governing body that ensures they don't. And if so - what is the
> > improvement?
> > > New.net is obviously a wrong example since they are not at root level. I am
> > > surprised that the Chirman of the IEFT may use such a ploy to support his
> > > point. Either your point is good and please use relevant example, or your
> > > point is not and please do not try to confuse the issues.
> >I think you are a little unfair to Harald here.  New.Net is a perfectly valid
> >example as it does use a root zone and has got 18 colliders.  But even if it
> >didn't, or was otherwise a poor example, Harald's substantive point
> >remains and
> >must be addressed.  I've tackled it one way already - this is a different
> >approach.
>
> 1.  As you know New.net is not using a root. This is why it it is not a good
>      example. China could be one. Embarassing but good example.
> 2. If you read my response to Harald I further on say that his point is
> relevant
>      (if  the example is not) and I addressed it.
>
> Now you take other Harlad's points from another threat. These points were well
> taken and relevant. They just forgot the "date rule". The whole inclusive
> system
> relies on the date of first use in the network. If someone breaks the rule he
> is commonly considered as the bad guy. BTW that rule is universal and is
> the basis for IP. As long as we are among civilized people, this rule is
> enough.
> There may be conflicts but people may solve them based upon that rule.
>
> Now when that rule is denied by a leading participant like iCANN in the
> ".biz" take away case we have a true problem.
>
> But the problem is not with the people Harald is questionning. The problem
> is with the pople Harald is supporting. So I suppose Harald may help with
> a response (I do not pull his leg here: there are some existing solutions
> within the iCANN in case of iCANN unfair behaviour. These solutions have
> published rules which may be used in courts. Today that kind of action
> by iCANN lead to inquiries by the Senate and Congress and - to some
> extents - to comments by several GAC Members and EU).
>
> >Harald's point is:  When there are no enforceable rules (such as you might
> >have
> >in a tightly controlled centraised system) how can you stop people setting
> >up a
> >new root zone which collides with all the others.   Money talks, bulldust
> >walks.
> >
> >Unless and until the alternate root people, or their supporters, can develop a
> >workable and effective solution to that problem then it will continue to be
> >raised.  And that's fair.  In fact it is the core question to be addressed.
> >
> >Off the top of my head I can see several possible real-world approaches which,
> >alone or in combination, could provide a result (if not a solution):
> >
> >(1)    Technical.  If you look at Alternic's TLD finder (say for ".com" or
> >".web") who you will see that it queries multiple roots:
> >http://www.alternic.org/tldfinder.html
> >
> >This shows that it would be possible to write a browser which will produce a
> >list of all domain names held by conflicting TLDs in whatever root they
> >reside.
> >If I had some VC that's exactly what I would do.
>
> I am afraid not. Such a system is based upon a list of RSCs. If the one
> offering the system does not list all the different roots (would iCANN list
> all the roots alternic is ???) results are differents.
>
> >There are no doubt other technical solutions including overlaying a directory
> >over the DNS as is done by Realnames.  I'm sure that will end up being the
> >solution for multilingual domains.  And I would not discount your comments
> >(which I haven't studied) on BIND software solutions.
>
> I am sorry you did not. I am not commenting a technical solution.
>
> I just state and remind everyine that if we add  (as Jeff Williams says) 36
> lines
> of code into the named program code the whole philosophy of the Internet is
> changed, the USG claims are irrelevant, the iCANN is deeply to be reviewed,
> Plan B must be deeply modified and the Protocol is actually meaningless on
> a few key elements.
>
> A few other lines added elesewhere would the same way kill the IP
> strategy and UDRPs.
>
> Again, the constitution of the Internet is writen in the source code.
> And bytes are carried by machines and lines not by laws and contracts.
> Forgeting that is the real problem of the Staff.
>
> Any paperwork you do to curb technical innovations will never stand,
> all themore if that innovation provides some good financial returns.
>
> Jefsey
>
> --
> 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



<<< Chronological Index >>>    <<< Thread Index >>>