CORE technical meeting - Minutes

Thursday September 4, 1997

1) Agenda for the meeting: Attempt to identify the problems and issues

involved in a shared registry system.

a) Deadlines

i) October 15, 1997 - deadline for registrar applications

ii) March 1998 - NSI exclusive contract ends

iii) April - October 1998 - How to deal with the inclusion of .com in the

shared registry database

2) Problems and issues

a) What is the relationship between the three parties involved:

i) CORE

ii) Registrar

iii) End-user

b) Who owns the CORE db and the developed software?

i) The developer or CORE or is it public domain?  (*There was a general

concensus that a separation of powers is needed so that not one party has

full control or a staff of CORE reps. will run the system.  Also, the

operator of the CORE db should be prevented from being the single entity in

control.)

c) When should the developer of the CORE db hand off the finished product?

(*In the RFP, it can be stated that CORE can terminate the contract between

the vendor and CORE.)

3) Contents of the Request For Proposal (RFP)

a) Performance of the system

i) How many initial transactions per second? (*One transaction per second

or 86,400 a day is realistic and if it exceeds that rate, there will be

"push back" to the registrar.)

b) Security issues

i) Use of digital signatures: Should they be used between the end-user and

the registrar or should they only be used between CORE and the registrar?

(1) Are digital signatures too complicated for the average end-user?  If

the end-user does not want to use any digital signatures, should the

registrar keep the digital signature on behalf of the end-user?  (*The

general consensus was that digital signatures should definitely be used

between CORE and the registrars.  It was undecided, however, which kind of

digital signature to use.)

(2) Should digital signatures be used between the end-user and registrar?

(a) If yes, several complications arise:

(i) Registrars will have to spend a large amount of time and money in

customer support for those users who do not know how to use the technology.

(ii) Should the registrar keep the digital signature for those users that

do not know how to manage the digital signature?  Should this kind of trust

be placed with the registrars?  If yes, what happens when an unhappy

end-user wants to move it's domain to another registrar but the current one

will not release the domain or the accompanying signature?

(b) If no, these issues:

(i) What security measures will be used to verify that authorized parties

are making modifications to domains?

(ii) How will the end-user move it's domain from one registrar to another?

c) Scalability

i) The first surge of registrations (first three months)

ii) When .com is added to the shared registry db

iii) Long lasting growth of the CORE db

d) Miscellaneous issues involving the systems

i) Email vs. web based or other forms of transactions - Email transactions

should be used between CORE and registrars.  A user-friendly web interface

can be used between registrars and the end-user.  However, this issue was

not satisfactorily resolved and a consensus was not reached among the

attendees.

ii) Assignment of tracking numbers to each transaction

iii) Queuing vs. FCFs

iv) A transfer protocol for the those who wish to take their domain to

another registrar

v) Automated trademark searches by CORE?

vi) The development of registrar accounting systems.

4) Specific presentations

a) Robert Frank, President of Corsearch

i) These new gTLDs have been proposed because of issues involving trademark

laws (Tony, I have this down in my notes...I do remember him saying

something to this effect, but it seems sorta silly, doesn't it?)

ii) As it is, the domain dispute/trademark policy with NSI is undefined;

caution and a clearly defined policy must be formed prior to day one for

these seven new gTLDs.

b) Curt Mayer

i) Can the db handle the initial flood of new registrations

ii) How much downtime should be allowed for the servers?

iii) Scalability - Can the db system handle growth?

c) Chris Gibson, WIPO Sr. Office at Arbitration and Mediation Center

i) How can the CORE db be shared and changes be communicated between

registrars, and later, multiple registries?

ii) A domain dispute is referred to as a "challenge" or "petition."

iii) The plan is to have online forms available to those that wish to

petition a domain registration.

iv) Web interface forms that state results and decisions of the

Administrative Challenge Panels (ACP); the CORE db will be updated

automatically.

v) There will be a defined list of "proactive exclusion" domains that no

one can register.

vi) A CORE db in Geneva and North America

vii) Unresolved issues:

(1) How to validate disputes and those contacts that can speak

authoritatively for that domain.

(2) How to make notifications to CORE, registrars and ultimately the end-user.

d) Alan Sullivan, Votiv Systems

i) Internet Registry Interface Standard (IRIS) is a shared registry system

interface intended to provide registrars a way to expand capabilities of

the db.

ii) The current NSI systems is perceived as unreliable, not user-friendly,

and there is lack of competition.

iii) Votiv wants to ensure that CORE supports new services and  achieve

faster delivery.

iv) Also, it won't be one company that designs the shared registry model;

it will be a partnership of companies.

e) Perry Metzger, Piermont Information

i) When designing the CORE db model, several key ideas must be kept in mind:

(1) Fast acknowledgements ("acks") from the registry stating that new

registrations have been committed to the queue are essential.

(2) Multiple new registration requests from a single party must be

acknowledged as one request, not 50 or 100.

(3) There must be a way to track verifications and changes to domain

information, via authorized contacts for that domain.

ii) Costs have been underestimated thus far; costs will be incurred in

staffing, customer service, etc.

iii) The first stage of registrations (day one) cannot be a slow,

controlled process because the cost of moderating the flow of registrations

will exceed any initial costs.

f) Rick Wesson

i) RIDE - Registry Information Data Exchange

(1) A system for sharing information between registries

(a) Information to share would include hostnames, nic handles, etc

ii) Digital signatures

(1) Security is an important issue - PGP v.5.0

iii) Templates

(1) Generic templates  for the end-user.

(2) Template parsers for the registrars to facilitate the flow of new

registrations

(3) Don't user the InterNIC-style template; use the RIPE-model template

(4) Object/contact updates are more done more often than new registrations

of SLDs.

iv) Whois

(1) NIC handles for these new gTLDs should be different from that of the

existing .com domains.

(2) Using the same NIC handles can be confusing

(3) Public whois servers should be updated on a 24 hr basis

g) Javier Sola, Spanish Internet Users Society

i) Architecture of CORE db v1.01

(1) End-user

(a) Customer submits a new domain registration to the registrar of its choice

(2) Registrar

(a) Registrar sends the new domain registration to the registry

(3) Reception system

(a) First stage of registration; a firewall will exist between the queuing

system and the public.  Only transactions from registrar IP s will be

accepted; all others will be bounced

(4) Queuing system

(a) Rejection of invalid applications (those with mistakes); a log of these

rejections will be kept.

(b) Valid new registrations get sent to the round robin assignment queue

(5) Administration system

(a) All rejected  and accepted registrations will be filtered to this part

of the system.  Successful SLDs will be charged to registrar accounts

(6) Response system

(a) Encrypted email will be sent to the registrar which must then be

acknowledged and a response sent back to the CORE db

(7) CORE db - Logs of all new registrations that are accepted into the

queue will be kept here.  Also, a log of all successful registrations along

with all accompanying data, including whois info, and digital signatures

associated with a domain.

h) Kent Crispin, Songbird

i) Security issues - cost effective minimization of risk

(1) Threats - insider and outsider threats

(a) Threats to the CORE db security may not have a motivational intent (eg.

the threat may be a machine malfunction)

(b) Internal threats are more complex than outside threats

(2) Distributed/replicated db systems multiply any risk

(3) The CORE db cannot/should not trust the registrars

(4) Encryption (for privacy) is not needed because DNS and whois data is

public information

(5) Digital signatures are needed because they provide three things:

(a) Authenticated identification

(b) Data integrity

(c) Non-repudiation

(6) The difficulty of using digital signatures is overstated

(7) Management of public keys is a major operational complexity

(8) CORE db is the most valuable part of the infrastucture

5) At the end of the days session, six volunteers agreed to put something

on paper for the next day, a sort of draft for the drafters.

a) Dave Crocker, Internet Mail Consortium

b) Trevor Hales, Melbourne IT

c) Siegfried Langenbach, CSL GmbH

d) Leni Mayo, Top Level Registries Pty Ltd

e) Javier Sola, Spanish Internet Users Society

f) Rick Wesson, PAB

CORE technical meeting

Friday September 5, 1997

1) A timeline is established:

a) Draft RFP                    September 11, 1997

b) Comments finished            September 17, 1997

c) Final RFP issued                     September 26, 1997

d) Proposals in by....                  October 3, 1997

e) Selection of a contractor            October 10, 1997

f) Development begins           October 20, 1997

g) Component testing            November 17, 1997

h) Integration testing          December 15, 1997

i) Controlled operations                January 26, 1998

j) Full operation                       February 9, 1998

2) Establishment of discussion mailing lists

a) RFP-announce

b) RFP-submit

c) RFP-team (a closed discussion)

d) CORE- submit

e) CORE - announce

3) Items to focus on for today:

a) Selection of RFP drafting team to work together after the CORE technical

meeting

b) Publication on the Internet of relevant documents

c) Press release and communication to potential vendors

d) CORE operations

4) Discussion of first version of RFP draft

a) The RFP schedule - is it reasonable? (* Most seem to agree that although

it is tight, a vigorous schedule is the only way to complete the project)

b) CORE operations

i) Transition time frame

(1) After 15 months, with a 3 month transition of operations? (the

transition period can begin earlier)

(2) Plans for separate registries per gTLD

ii) In the RFP, specify the problem and demand a time frame, transition

plan, staffing, an operation logistics from the potential vendor.

iii) "Options for vendor operations are open, but the RFP team will list

suggestions and there will be a sunset (?) clause.  This is done by stating

the problem."

5) Volunteers for the  drafting team for RFP

a) Kevin Connolly, PSI Japan/Eaton & Van Winkle

b) Kent Crispin, Songbird

c) Jim Dixon, Euro ISPA

d) John Gilmore, Top Level Registries Pty Ltd

e) Trevor Hales, Melbourne IT

f) Javier Sola, Spanish Internet Users Society

6) Further discussion of RFP draft and related technical issues

a) Fairness in queuing

i) It is agreed that registrations will begin at 12:00 am GMT

b) The possibility of a leased private line from a registrar to the CORE

db, for those registrars that choose to have one.

i) This is unfair to those registrars that do not have the funds or the

technical capabilities

c) The "steady state" - registrations under the new gTLDs after the initial

start-up

i) Non-starvation

ii) Accessibility

iii) Transparent

iv) No preferences

v) Any transaction (successful or not) will count against a registrar, when

using the round robin system

d) CORE db and whois

i) Make it freely available to the public, including the source code

information

(1) Some argued that the source code should be kept public, but not

necessarily as public domain

(2) The source code may or may not be owned by CORE

(3) Data information in db (whois) will be publicly available.

7) Requirements for submission by vendors

a) Page limit?

b) Qualification statement

c) Sealed or public?

i) Some argued that the proposals should be made in 2 envelopes

(1) Technical specifications

(2) Financial cost

d) Distribution of proposals

e) Location of the machines - this may determine the ultimate costs for the

vendor.