Re: Revised Draft

[Dave Crocker <dcrocker@imc.org>]

Chris,

	A thoughtful and diligent job.  You will not be surprised, I
suspect, at our points of disagreement, but I certainly laud your efforts
at specificity and balance.  (I don't believe in true objectivity, since
the fairest of people still has massive biases.)

	Since you did not fully mark what text was from the IAHC draft,
versus what text were changes you are suggesting, I may well have missed
some points.  Efforts like these are best done as "delete this par", "add
this par after/before par xyz" and "modify par xyz to read ...".  In other
words, I, too, wish that you had offered the suggested changes are straight
deltas to the IAHC draft, but otherwise think that your document is a fine
effort.

d/


At 2:46 PM -0800 12/23/96, Christopher Ambler wrote:
>2.2   International
>  The only other International TLD to be considered is
>the .arpa TLD, which is used for reverse mapping
>(in-addr.arpa). The operation of the .int and .arpa
>TLDs will be defined and implemented by CORE (see
>below), with the acknowledgement that the existing
>registrar, NSI, currently operates .arpa and .int.

	It seems highly unlikely that .arpa belongs in this category, in
spite of its having an 'international agency' tone.  The service provided
under .arpa crosses the entire dns and should not, I believe, be contrained
under one of the dns constituencies.  Besides... this is an issue WE don't
have to deal with just now.  It's not a problem and there is no damage done
by defering consideration of its disposition.  Let's solve only the
problems we have to.  There's enough of them to keep us busy!

>3.2  Sharing and Exclusive Use
>  First, the existing registrar, NSI, is not in a position
>to be mandated to share the existing gTLDs (com/net/org).
>This barrier may be removed by the voluntary cooperation of
>NSI. Until such cooperation is given, or their current
...
>  Second, while there are many technical solutions for
>implementing such a shared system, none have been suggested,
>tested, or approved. It shall be the first responsibility
>of CORE to select and/or develop, test, and approve such
>a system.

	We have an interesting choice.  We can use the existing NSI
exclusivity as an excuse for creating other, exclusive registries, hoping
that one day they all will participate in sharing, or we can require that
all new registries be shared now, hoping that one day NSI will join in.  In
the former case, it's not clear to me what the incentives are, to motivate
change amongst the monopolies.  In the latter case, there is a single
exception to the goal and a reasonable basis for hoping that its existing
agreement will change (either quickly or when it runs out) and that it will
want to participate in the "brotherhood of registries".  (Interesting
linguistic challenge, here, in seeking to achive gender-neutral language.
Somehow, siblinghood doesn't cut it and I can't think of a better term.)
The latter path, therefore, seems to me much stronger for achieving full
sharing.

	On the matter of technical sharing, there is strong consensus that
off the shelf technologies, sufficient to the task, exist today.  They are
all proprietary, so the only real question is which one to use and that
decision should be left to those who must achieve the sharing, since the
task is strictly mechanical and does not involve interesting policy
matters.  So yes, this choice must be made immediately by CORE but no, it
need not take long.  In particular this issue need not cause a delay in
sharing.


>3.3  Which gTLDs to Create
>  The decision of which gTLDs to create is a business aspect
>of running a registration service, and is outside the scope
>of the IAHC. As such, registrars will be solely responsible
>for the selection of the initial gTLDs, with no registrar
>selecting more than 3 gTLDs. Once the initial formation of

	I would very much like to subscribe to this suggested approach.  My
own entrepreneurial juices rebel at the kinds of strictures in the current
IAHC proposal.  But those strictures are necessary AT THIS TIME.  I've made
a number of attempts at explaining the concern for problems with unbounded
scaling processes but the point is not being universally heard.  It appears
that the need for ensuring on-going safe operation of this critical
resource is simply not well understood by some and no amount of explaining
the issue is helping.

	The bottom line is that requirements for operations safety with the
DNS require limiting initial, new allocations both of gTLDs and of
registrars.  Given those requirements, allocation mechanisms are required
for both.

	Over time, it is fully expected that these restrictions will be
removed and that there will be no, or little, limitation to the
introduction of new gTLDs or addition of new registrars.  "Over time"
pertains to learning how to handle both such changes and coming to believe
that unbounded growth can be safe.  Such learning has not yet taken place
and it would be entirely irresponsible to assume that it would result in
stable operation at this time.

>4.3  Objective Criteria for Registrar Selection

	An interesting and reasonable list.  Some questions, of course...

>1.  Documentation of sufficient connectivity to the Internet to support
>the
>    operation of a registrar. This connectivity shall have, as a
>minimum,
>
>    a.  Full multi-homed connectivity, with each leg of that
>    b.  Route advertisement via BGP4 for the connectivity must be

	Why does the registrar need such connectivity?  perhaps you mean
the repository needs it?  remembering that it is not part of the real-time
DNS, why does it need such intense connectivity?

	Further, if one is seeking reliability and performance,
distributing copies and connectivity to multiple parts of the Internet
would seem essential to me.

	Let me suggest that the task in this section should be to state the
service and performance requirements -- i.e., what problems you are trying
to solve or prevent -- and leave the specific details for later.

>2.  Documentation of the operation of at least two nameservers for the
>    gTLDs in question (total, not two per gTLD). These nameservers

	Again, please distinguish registrars from repositories.  Further,
you are requiring that one of them (presumably the repository) operate a
DNS server.  This is probably quite reasonable, since it somehow needs to
be able to make the actual DNS data available...

	As to the details of software, it is not always a good idea to
constantly upgrade to the most recent version of software.  Tends to hurt
stability.

>4.  A written offer, which may or may not be called by CORE, to operate
>    a root domain server as part of the general Internet infrastructure.

	My own belief is that current conflict of interest concerns dictate
separating operation of a root server from operation of any other part of
the DNS.

>5.1  Council of Registrars (CORE)
>The Board of trustees for CORE will ensure that gTLDs are
>administered and operated in a public and open manner which
>balances the commercial interests of registries with the
>public policy interests of the Internet domain name space..
>The Board shall comprise:  One member from each registrar,
>and the full membership of the IAHC as comprised at the
>time. The policy for appointment to the IAHC shall remain
>as it is, with members being appointed by the different
>Internet operation groups.

	Some current participants in the IAHC are constrained from
participating in operational activities.

d/


(read the last line, please)
----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segré Place                                             dcrocker@imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also:  IAHC member, expressing strictly (or loosely) personal opinions