Shared TLD Daily Digest, Aug 07, 1996

-> [VOLUNTARY CALL] Comments - TLD Applications
     by Simon Higgs 
-> Re: [VOLUNTARY CALL] Comments - TLD Applications
     by Kent Crispin 
-> Re: [VOLUNTARY CALL] Comments - TLD Applications
     by chris@kosh.punk.net (Christopher Ambler)
-> Coordination protocols (was Lightweight vs. heavyweight registries)
     by "Dave Collier-Brown" 


----------------------------------------------------------------------

Date: 6 Aug 1996 03:53:19 -0700
From: Simon Higgs 
Subject: [VOLUNTARY CALL] Comments - TLD Applications

      I have received requests to consider the inclusion of existing
      TLD claims in the next revision of draft-higgs-tld-cat-02.txt.
      The existing TLD applications are filed at IANA and are
      "sealed" until an application process is established. I believe
      this is a wise move.

      I am open to listening to why existing TLD claims should be
      included in the next revision of draft-higgs-tld-cat-02.txt.
      I'd also like to hear from those who think this is a bad idea.
      Please send any comments to me directly at simon@higgs.com.

      Should I decide to include existing TLD claims in the next
      draft, I will need to verify that the TLD applications have in
      fact been made. Copies of existing TLD applications (InterNIC
      v2.0 or v3.0 template with the InterNIC receipt timestamp in the
      subject line) should be sent to hostmaster@higgs.net.

      THIS IS PURELY A VOLUNTARY CALL AND IT IN NO WAY AFFECTS THE
      IANA TLD APPLICATION PROCESS. THERE IS ABSOLUTELY NO GUARANTEE
      THAT ANY EXISTING TLD CLAIMS WILL BE IN THE NEXT REVISION OF
      DRAFT-HIGGS-TLD-CAT-02.TXT.


_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...




----------------------------------------------------------------------

Date: 6 Aug 1996 11:58:38 -0700
From: Kent Crispin 
Subject: Re: [VOLUNTARY CALL] Comments - TLD Applications

Simon Higgs allegedly said:
>
>       I have received requests to consider the inclusion of existing
>       TLD claims in the next revision of draft-higgs-tld-cat-02.txt.
>       The existing TLD applications are filed at IANA and are
>       "sealed" until an application process is established. I believe
>       this is a wise move.
>
>       I am open to listening to why existing TLD claims should be
>       included in the next revision of draft-higgs-tld-cat-02.txt.
>       I'd also like to hear from those who think this is a bad idea.
>       Please send any comments to me directly at simon@higgs.com.
>
>       Should I decide to include existing TLD claims in the next
>       draft, I will need to verify that the TLD applications have in
>       fact been made. Copies of existing TLD applications (InterNIC
>       v2.0 or v3.0 template with the InterNIC receipt timestamp in the
>       subject line) should be sent to hostmaster@higgs.net.
>
>       THIS IS PURELY A VOLUNTARY CALL AND IT IN NO WAY AFFECTS THE
>       IANA TLD APPLICATION PROCESS. THERE IS ABSOLUTELY NO GUARANTEE
>       THAT ANY EXISTING TLD CLAIMS WILL BE IN THE NEXT REVISION OF
>       DRAFT-HIGGS-TLD-CAT-02.TXT.

Simon, I think it would be completely inappropriate to include
existing TLD claims in the draft.

If inclusion in the draft confers some advantage to the claim holders,
then that would be unfair to claim holders that you don't know about
- -- they might be on vacation, for example, and not see your call.  And
of course, we have no way of finding out about all pending
applications at InterNIC.
	
If inclusion in the draft does *not* convey any advantage, then there
is no particular purpose served.

I think the draft should only include hypothetical examples, with
clear disclaimers that they *are* hypothetical and not known to to be
in any way involved in any current actions on the part of InterNIC,
AlterNIC, or anyone else.  Such a disclaimer should address the case
where you include a name that is in process some way, but that you
didn't know about.

- --
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
kc@llnl.gov


----------------------------------------------------------------------

Date: 6 Aug 1996 12:07:48 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: [VOLUNTARY CALL] Comments - TLD Applications

I have to agree, Simon, that putting existing TLDs in the draft
is a bad idea. Obviously, since I have 2, one would think that I'd
want them in there - but if the process is unfair to begin with
(example being someone who didn't see your call for submissions),
then it's worthless.

I recommend you merely make mention that they exist, and perhaps
mention that prior use is a major factor in granting registry
status. I believe that would have the desired effect.

Christopher Ambler
President, Image Online Design, Inc.


----------------------------------------------------------------------

Date: 6 Aug 1996 13:51:20 -0700
From: "Dave Collier-Brown" 
Subject: Coordination protocols (was Lightweight vs. heavyweight registries)

 John R Levine allegedly said:
> I've been pondering the ways that shared TLDs might work, and I see two
> somewhat different ways that the responsibility might be parcelled out:
> 	The heavyweight registry model:
[...]	
> 	The lightweight registry model:
 	> provide one-stop service to its users.

Kent Crispin replied:
	You realize, of course, that the two alternatives you describe are
	just points in a design continuum, and not necessarily endpoints 	
	either.
 	[...l
 	Notice that the only real use for the coordination database in this
	scenario is to act as a reservation system.  The situation gets a
	little more complicated when you start worrying about things like a
	competitor cohort cheating by claiming a bunch of names, or how the
	IANA audits things to collect its fees ;-).

Hmmn..   This immediately brings to mind an implementation of a
particular lightweight registry and its distribution system.  While
the idea is still only half-baked (and therfore while I'm not emotionally
over-attached to it), let me outline it:

	Customer C goes to registry R to register x.com
	Registry R connects to coordination-database server D via
		an ssh (for example) session, and the conversation
		is:
	R			D
				220 D Ready.
	HELLO R
				250 Welcome, R.
	REQUEST x.com
				550 x.com is taken
				or
				250 ok, reserved for 10 minutes
	DATA
				350 send data
	
	.
				250 data accepted, x.com is yours
	BYE
				250 Nice talking to you, R.

	The coordination-database server then mails out the data
	to it's subscribers, loads it into it's DNS and links it,
	and finally does a periodic zone transfer of the .SHARED
	zone to all its customers.

This mostly uses existing software for the distribution, and presumably
has a distributed database of the coordination data for reliability.

A low-cost D could do it all with perl scripts and a routine to
copy the session to a second machine, journal-like.

The smtp-like or ftp-like transacation are easy to write: I've done
dozens, and they usually take about an evening.

MIME is trivial to write: I often generate mime messages with shell scripts.
One can include a part for every significant block of data.

Ssh (or SKIP, or whatever) provides authentication and more.

An explicit tcp sesion allows a simple daemon (under inetd it's a filter)
which can do a database transaction and time out and abort it if the
session fails.  I have written lots.

Failure modes are as follows:
  1) session lost due to network outage.
	R doesn't get to request x.com.  If the session is running
	in front of C, and if R hasn't C's cheque in hand, C goes elsewhere.
  2) session lost due to timeout, R's side
	R reboots and tries again (:-))
  3) D is down
	R connects to D'
  4) D and D' are down
	No-one can do anything.  R collects the data, prints out
	a copy and signs and dates it, then puts the data into a script
	to use when D comes back.  He then faxes it to D to prove the
	date is as he says.
   5) C provides bad data
	R fixes it and submits an UPDATE transaction.
    6) C provides bad data and R accepts
	C isn't reachable, and D bugs R about it.  Customers
	can't reach x.com, although they can reach the dns server
	for it (probably at R)


I think the failure analysis is independant of the implementation (;-))
I know it isn't exhaustive.

- --dave
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb@hobbes.ss.org, unicaat.yorku.ca
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb