Subject: Re: IAB comments on Green Paper

From: [email-masked] (Noel Chiappa)
Date: Tue, 24 Feb 98 10:45:05 -0500

<I've packaged short replies to a number of messages together...>

    From: Gordon Cook <[email-masked]> 

    the only way the green paper's ... would be derailed was for the internet
    TECHNICAL community.... yes the IETF..... to stand on its hind legs and
    make it very clear in well reasoned comments *WHY* it wouldn't work. ...
    it won't do for only the IAB to say so. Rather that the more who complain
    the better. And by complain i don't mean say its stupid, but give a well
    reasoned explication of *WHY* it's unworkable. If every member of the
    IAB, IESG and every chair of ever working group files a comment, he will
    have to listen.

This emphasizes something I've been thinking about since Brian's comment,
which is that telling the IETF (who really are a large share of the technical
community that builds and runs the net) to "bug off" will not work *iff* the
community is united. The technical people who run the network do have a lot
of influence, but only if they are united. It's a "hang together, or hang
separately" situation.

    From: Robert Shaw <[email-masked]>

    The only long-term possible solution is to completely break the economic
    interests that people see in gTLD 'ownership'. ... The GP authors have
    not understood this at all ... It also means that, up-front, all CORE
    registrars know that they do not have any 'ownership' rights in gTLDs.
    That way we avoid claims like this from NSI:

       "It is not our intention to share .com or the others [domains] we
       register.. Those would obviously [be] assets that we've developed"

    ... if a registry jacked up the prices it charged to registrars after
    millions of customers were locked into their domain names. ... the
    authors of the Green Paper .. has reintroduced the issue of gTLD
    ownership which the IAHC and gTLD-MoU argued must be removed.

This is an *extremely* important point, and one that has to get fixed or the
GP solution is *simply unacceptable*. Once you've bought "zippo.foo", and a
hundred thousand web pages around the world have links to it (not to mention
17 million web bookmark folders), you don't want the only "free-market"
solution to overcharging for it to be switching to "zippo.bar". Sorry, not
too useful.

The registries (as opposed to the registrars) have to be run to non-profit
groups which don't view the contents of those registries as "assets we've
developed". Those databases are public utilities, *not* private property.

This aspect *has* to get fixed - and I hope Gordon Cook is right, that
concerted comment will produce changes.

    From: "Donald E. Eastlake 3rd" <[email-masked]>

    why in the world not just wash your hands of it and throw away any
    "right" to control the unGhodly mess of gTLD decisions

In general, this all sounds like a great idea to me. Splitting off the gTLD
stuff to a whole separate organization is fine with me (provided control of
technical issues like technical standards for top-level servers, etc is
retained elsewhere, and some other issues <see above> are dealt with). But I
do have one minor quibble:

    and address block decisions? ... To say that each province of China gets
    a /17 or a /16? ... And on the address side? Well, it should control IPv4
    uni-cast addresses and Autonomous System numbers.

I think this is a bad idea. Address allocations *must* have as their *first*
constraint making the routing scalable. This is very different from gTLD's,
where it's technically irrelevant whether we have 3, 17, or 69, and what they
are. I think it's a very bad idea to let a bunch of trademark lawyers try and
hand out addresses.

    even with no vote, I just can't see it proceeding without some
    non-binding technical consultation from the IAB or IETF community.

Have you talked to the phone people who are trying to make local number
portability work, recently? Policy got put in front of technical feasibility
there, and I don't think the technical guys had much influence on the
decision.

	Noel

---

From: "Dick St.Peters" <[email-masked]>
Date: Tue, 24 Feb 1998 15:26:00 -0500

If "registries" and "registrars" are to be separated, could someone
please articulate the essence of how a registrar will differ from
an ISP filing a registration for a client under the current system?

The InterNIC is obviously a registry; it's not one that fits everyones
ideal of how a registry should be run/financed/organized, but it is a
registry nonetheless.

I take money from clients to arrange to have their domains registered
at this registry (and do other things for them, like DNS).

What exactly would a registrar do for my clients that I don't?

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY, 1-800-910-6671 (voice)
Saratoga/Albany/Amsterdam/BlueMountain/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
	  First Internet service based in the 518 area code

---

From: [email-masked]
Date: Tue, 24 Feb 1998 16:37:39 -0500

>What exactly would a registrar do for my clients that I don't?

There is little difference.  My interpretation is that
the new definition of a registry will be similar to NSI's
current "channel partner" program.  

Those that become official registrars will be entitled 
to discounts or other special consideration on a 
non-discriminatory basis.  

Another way to look at it is that the registry is
the wholesaler, while the registrar is the retailer.

Regards,

Jay Fenello
President, Iperdome, Inc.  
404-250-3242  http://www.iperdome.com

---

From: Karl Denninger <[email-masked]>
Date: Tue, 24 Feb 1998 15:42:55 -0600

> What exactly would a registrar do for my clients that I don't?

Take more of your money.

--
-- 
Karl Denninger ([email-masked])| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost

---

From: "Dick St.Peters" <[email-masked]>
Date: Tue, 24 Feb 1998 17:27:51 -0500

> the wholesaler, while the registrar is the retailer.

This still isn't clear.

Arranging domain registrations at the current registry is part of my
business.  One part of your answer sounds like the intent is to hand
that part of my business over to ordained registrars, who will do for
my client what I do now - and, I suspect, charge him more for it.

However, the last part of your answer sounds like these registrars
will insert themselves between me and the registry, for a fee.
Unless, that is, "registrar is the retailer" means retailer to my
client, with me out of the loop.  In that case, both answers are the
same.

Either way, I do not like these answers.

---

From: Kent Crispin <[email-masked]>
Date: Tue, 24 Feb 1998 15:01:08 -0800

On Tue, Feb 24, 1998 at 05:27:51PM -0500, Dick St.Peters wrote:
[...]
> client, with me out of the loop.  In that case, both answers are the

Part of the confusion stems from terminology, I believe.  A registry,
in the new jargon, is strictly a back-end database operation, whereas
a registrar is a front-end customer interface operation.  Currently
NSI does both those functions.  When you deal with NSI currently you
deal with their customer interface -- email, or whatever, and if you
have a problem you deal with their customer service organization. 
Internally, NSI's email interface and customer service organization
deal with their database operation, and you never see it.  That is,
NSI's customer interface "inserts itself" between their registry (the
database/dns operation) and you -- you do not have direct access to
the NSI .com database (the "registry" in the new jargon), for example, 
nor do you deal with .com zone updates.  

This will be exactly the same with the CORE shared registry system --
the registrars have special, authenticated access to the database that
you as a customer do not, and they can do things that you as a
customer cannot -- they have the ability to modify things to fix
problems, for example.  This is quite a different interface than that 
of a "preferred partner", I believe.

The CORE DB (registry) is operated on a non-profit, cost-recovery
basis by the registrars -- it really is just the backend database
operation, much as if NSI (the registrar) subcontracted it's database
operation to NSI (the registry).

An ISP can become a registrar, and thereby get the direct access (and 
at-cost pricing) of any of the other registrars.  It is expected that 
in the long run most of the registrars will in fact be ISPs, in which 
case the ISPs will essentially run the registry.  

This would be like NSI being owned and operated by a partnership of a
large number of ISPs, which is really different from the business 
relationship of being a "preferred partner".

> Either way, I do not like these answers.

Fortunately, the reality is different from either one :-)

-- 
Kent Crispin, PAB Chair			"No reason to get excited",
[email-masked]			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

---

From: "Dick St.Peters" <[email-masked]>
Date: Wed, 25 Feb 1998 02:33:27 -0500

Kent Crispin writes:

> NSI does both those functions.

NSI also does something else vital that I never see mentioned in these
discussion, which to me suggests the people doing the discussing don't
actually do much domain registration.

NSI resolves disputes over which ISP represents a domain holder.
Where will this function go in the new model?

The basic value of a registry+registrar is forming an association
among domain, domain registrant, domain contacts, and DNS provider;
preventing unauthorized changes; and enabling authorized changes.  A
huge part of this is confirming authorization - preventing domain
piracy of both the active and passive sort.

Who deals with the case where a person working for a company registers
the company's domain with himself as admin contact and later leaves
the company?  Believe me, this kind of thing happens all the time, and
it leaves the domain in limbo.  Changes to the domain can't be made
without the concurrence of the admin contact, who is still on record
at the registry, but he/she no longer represents the registrant and
typically is no longer at the registered email address.

You're an ISP, and your client informs you they're moving to another
ISP.  Just turn off their DNS and if the admin contact's email address
is in the domain, the InterNIC's request to acknowledge the domain
transfer goes nowhere.  Or better yet, leave DNS running but change
the email mapping so the request comes to you, then Nack it.  Who
deals with these?

To whom will my clients be faxing picture IDs and letters on company
letterheads to get these situations straightened out?

Can an admin contact whose been fired go find a registrar to
reregister his ex-boss's domain?

---

From: Kent Crispin <[email-masked]>
Date: Wed, 25 Feb 1998 06:51:38 -0800

> actually do much domain registration.

Your inference would be incorrect, though.  The level of experience
varies widely, in fact, but there are certainly people involved in
this process who are very familiar with the domain registration
process.  And dispute resolution was a *major* concern in the design 
of the CORE SRS.

> Where will this function go in the new model?

In the CORE model the domain holder controls the domain, not the ISP
or even the registrar.  Associated with each domain in the registry is
a public key, supplied by the domain holder.  A domain holder with the
private key can go to *any* registrar to get records changed for that
domain -- the domain holder is not locked in to any ISP or registrar 
to make changes to the record.  This is referred to in the jargon as 
"domain portability" or something like that -- just like you can move 
your phone number from one company to another.

Of course, some customers won't supply a public key.  In that case
they are bound to the registrar, that registrar acts as their agent,
and disputes will be handled by the registrar that represents the
domain -- basically the same as with NSI.  But unlike the case with
NSI, you can still change registrars -- if you don't like their
policies or service you just go to a different registrar to service
your domain.  If you don't supply a key you are more vulnerable to 
disputes with your registrar, of course, but, unlike the case with 
NSI, you do have some recourse -- there are other registrars you can 
deal with, there is a dispute resolution process, etc etc.

> piracy of both the active and passive sort.

Believe me, all this was considered at great depth and in great 
detail.

> the company?

With no associated public key the situation is much the same as with 
InterNIC -- the originating registrar must be involved in the 
transaction -- you fax them ID, etc.

With an associated key the situation can be either simpler, or more 
difficult.  The difficult case should be the rare one.

>  Believe me, this kind of thing happens all the time, and

I believe you.  In the case where the admin just leaves, and the key
is sitting around in their files, you have no problem, because it's
the key that matters, not the contact name.  In the case where the
admin is angry and does something bad with the key, you have a more
complex problem resolution case. 

> the email mapping so the request comes to you, then Nack it.  Who

As described above, if there is no domain key, then the registrar; if 
there is a domain key, then the user with the matching private key.  
Remember that the registrar is the customer interface to the registry 
-- as far as dispute resolution is concerened, the registrar is like 
an NSI branch office.

> letterheads to get these situations straightened out?

The registrar that registered the domain for you, generally.  If you 
have a disagreement with that registrar, then you can go to another 
one to press your case.  If it turns into a cross-registrar dispute 
it may have to go to CORE to be resolved.  In really bad cases the 
legal system may become involved.  Things have hopefully been 
constructed to minimize the likelihood of this happening, but the 
possibility can't be eliminated, and, in fact, you don't want to 
eliminate it.

> reregister his ex-boss's domain?

In the case where he steals the private keys, possibly, depending on 
how the keys have been stored.  But if the boss has a clue (and 
access to the keys) then those keys will have been changed, and the 
answer will be not at all.

Of course, it is recognized that it will be a while before most domain
holders get a clue about how to deal with PK.  But public awareness of
encryption, certificates, authentication, and other security concerns
is growing -- all this kind of stuff is in our browsers now, after all.

And while using PK simplifies some problems a great deal, it certainly
isn't a panacea -- there will always be cases where a human needs to
step in and make a judgement.  In most cases the registrar will handle
the problem.  If the dispute involves more than one registrar, then
CORE will need to get involved.  In the worse case, the legal system
will get involved.  It's real important to have policies and
procedures that handle problems as close to the customer as possible.  
And of course, by having many many registrars, the odds are that 
there is one physically near you -- you can actually go talk to a 
human face to face, if that's your style.

A great deal of thought went into the kinds of disputes that can come
up, and how they can be resolved, because, among other things,
disputes are an economic drain.  When you have a non-profit,
cost-recovery based registry, and competitive registrars, the price of
domains is driven down to the base costs of maintaining the system. 
Dispute resolution is one of those costs. 

Hmm.  There is actually a lot to say on this subject and this is
starting to get a bit pedantic and rambly.  Forgive me.  And note that
a lot of this is moot -- the Green Paper mandates shared registries,
as well.  But the GP hasn't given much thought to the dispute
resolution issues...