Re: CORE Show Stopper

[Jeff Williams <jwkckid1@ix.netcom.com>]

Kent and all,

Kent Crispin wrote:
> 
> On Sun, Nov 30, 1997 at 07:02:30PM +0000, Jim Dixon wrote:
> > On Sun, 30 Nov 1997, Kent Crispin wrote:
> >
> > > > > This issue has been known for a *long* time, and registrar collusion
> > > > > is one of the central design concerns of the CORE registry design...
> > > >
> > > > It was?  I recall no discussion at all of this issue in Munich, New
> > > > York, or on the RFP team's email list.  It was certainly not a central
> > > > design concept.
> > >
> > > Then you weren't paying attention. I certainly made the point several
> > > times in New York that one of the reasons for avoiding secret
> > > components of the shared registry protocol was to avoid collusion -- I
> >
> > I will repeat: I don't recall the idea being discussed, and I was one
> > of the few people taking careful notes.
> 
> Maybe you should take a class or something, then...

  now this is somewhat condecending Kent, and totaly not necessary.
> 
> [...]
> 
> > I don't think that we should get too far into this.  The technical
> > specification section began life as the notes that I took in Munich.
> > Dave C wordsmithed these a bit into the technical specs produced in
> > New York.
> 
> Actually, no offense to you or Dave, but that stuff was no more than a
> hint of what was needed.  I threw out most of it, and (I guess it's
> safe to admit this now) used a lot of stuff from
> 
>         draft-iahc-stldsup-crispin-02.txt
> 
> (on the IAHC web site, if it is still up) -- "Simple Protocol Supporting
> Shared TLDomain Registrars".
> 
> > > The particular features of the design that were explicitly concerned
> > > with the possibility of collusion were things like:
> > >
> > > 1) the basic notion of a shared registrary
> > > 2) the use of digital signatures on all transactions and replies,
> > > thus giving every registrar a complete non-repudiatable record of all
> > > transactions with CORE.
> >
> > Transactions with CORE generate charges.  The primary purpose of
> > digital signatures is to provide proof that the registrars actually
> > placed the orders concerned.
> 
> That's one purpose.  But you are vastly underinformed: There was a
> long, long discussion about the value of digital signatures on the PAB
> list, which you did not participate in, and there was a lot of
> discussion about a year ago on the IAHC list, and in other places.

  Very true and accurate statment here at least.
> 
> > > 3) the insistance on complete openness of the transaction logs for
> > > the CORE database.
> > >
> > > Anti-collusion definitely WAS a central design concept.
> >
> > People were very concerned about CORE being impartial between
> > registrars.  This did indeed come up again and again.  There was
> > indeed concern about collusion, but not collusion between registrars.
> > People were concerned about someone at CORE rigging the process
> > to some particular registrar's benefit.  This is a much more serious
> > threat than registrar-registrar collusion, particularly <ahem> to the
> > registrars who are paying for the development of the CORE software.
> 
> In fact, collusion between registrars and collusion between registrars
> and CORE share many characteristics, and can be combatted in similar
> ways -- the fundamental defense against collusion is an open process.

  It certianly can.  And a very good suggestion had been made by Paul
right here on this list that should at least be given some
consideration.
I am glad Paul made such a suggestion openly on this list.  We can now 
see in the days or weeks to come if indeed Pauls suggestion will
be heard.  
> 
> > >                                                         As I said, I
> > > wrote the technical specs, and anti-collusion was something I was very
> > > conscious of while I was doing it.  Anti-collusion has been a concern
> > > of mine (and others) for a long time before you were ever on the
> > > scene.
> >
> > There were many people involved in producing the technical specs.
> 
> Agreed -- it goes back a long time before New York or Munich, or even
> Nominet, and I have been involved through most of it.  You, on the
> other hand, simply don't have the history or the background to speak
> authoritatively about it.  I know that sounds condescending, Jim, and
> I honestly don't mean it that way.  It's just a cold fact.  This stuff
> has been going on a long time before you were ever on the scene, and
> there has been a lot of intelligent discussion interspersed in the
> flames.

  Yes there has been alot of discussion, with little or any conclusion,
mandated by the internet community as a whole or even a meaningful
attempt
to solicit the Internet community.  Only those in POC/PAB/CORE have had
any real input of meaning.  This is a travisity that will haunt
the gTLD-MoU in the future, if nothing else.
> 
> > >        It may be something you haven't thought much about, but it's
> > > generally bad practice to generalize your own lack of thought to
> > > others.
> >
> > Sure.  Equally, Kent, when you fail to see the large problem and
> > concentrate on the small, it is understandable but bad practice.
> 
> I believe I understand all the points you have ever mentioned.
> Sometimes I agree, sometimes I disagree.  Here, for your amusement, is
> one of my comments on the original IAHC draft, before you waltzed in
> -- I like to think it was influential in the addition of PAB in the
> second draft:
> 
>     I have several times commented on the need for "oversight" of
>     CORE.  here are a few words of clarification and motivation for my
>     concern.
> 
>     Through the means of the MoU, we are embarking on a governance
>     scheme that is essentially private, as opposed to public.  A MoU
>     is a contract only between the signatories -- embedding words like
>     "the DNS must be managed as a public trust" in the document does
>     not change this fact, and publishing the text of the MoU does
>     *not* give the public legal standing.

    But it could.  It is evidently not in the best intrests of
CORE/PAB/POC
   to do so however.  
> 
>     It is one thing to give lip service to "public trust", and quite
>     another to implement it.  To implement it, you must actually *give
>     some control to the public*.

     Exactly, ahd this has not been done.
> 
>     This does not mean that the mass of the great unwashed can track
>     mud over our nice clean floor -- in the political arena, public
>     oversight is always managed through indirect representation.  But
>     the public has the power, through some elective process, to "throw
>     the scoundrels out" and completely change things if they so
>     desire.

    And I agree with this compleatly.  But again it is not embodied
  within the MoU.  Why?  When will it be?
> 
>     With the MoU process, there is no way for this to happen.
>     Fundamentally, therefore, despite the lip service, there is no
>     public accountability.

    There is not public accountability is true.  But there have been
   several sugestions to impliment that accountability posted on this
   very list.  Yet it has been ignored.  Shame really.
> 
>     OK, we're engineers, and the "public" doesn't know how to run an
>     internet, so why should we give them any accountability?
> 
>     Besides the ethical and moral reasons, there is a very simple and
>     important reason why we must.  If we don't, the public will take
>     control anyway.  We all operate under the laws of some State.  If
>     we cannot clearly show that our governance processes are
>     publically accountable, then laws will be passed to make them so.

    Eventualy this will come to pass if or unless a more open process
  for public participation, especially Internet community open
participation
  is not agreed upon.
> 
>     Therefore I suggest that a public oversight body be defined,
>     elected from a wide constituency, that under extreme circumstances
>     actually have the power to modify or dissolve any MoU.  All MoU's
>     should be written to support this.

    Agreed.  But this one is not.
> 
>     Registrar's that are not comfortable with public oversight need
>     not apply.

    Well they have.  
> 
> --
> Kent Crispin                            "No reason to get excited",
> kent@songbird.com                       the thief he kindly spoke...
> PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
> http://songbird.com/kent/pgp_key.html
> 

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@ix.netcom.com

Wisdom:   "One who knows others is wise,
           one who knows himself is enlightened."
           Lao Tzu