Re: Draft provreg charter

Richard Shockey <rshockey@ix.netcom.com> Sat, 30 December 2000 16:32 UTC

Return-Path: <owner-ietf-provreg@cafax.se>
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id eBUGWN325369 for ietf-provreg-outgoing; Sat, 30 Dec 2000 17:32:23 +0100 (MET)
Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) with ESMTP id eBUGWM225364 for <ietf-provreg@cafax.se>; Sat, 30 Dec 2000 17:32:22 +0100 (MET)
Received: from computer.ix.netcom.com (user-2ivekf7.dialup.mindspring.com [165.247.81.231]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA30523; Sat, 30 Dec 2000 11:32:07 -0500 (EST)
Message-Id: <5.0.2.1.2.20001230105559.02ddbd50@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sat, 30 Dec 2000 11:34:02 -0500
To: Edward Lewis <lewis@tislabs.com>, Christopher Ambler <cambler-ietf@iodesign.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: Draft provreg charter
Cc: ietf-provreg@cafax.se, lewis@tislabs.com
In-Reply-To: <v03130302b672b34c5121@[10.33.10.145]>
References: <01b501c0716a$b860d640$140a0a0a@ambler.net> <5.0.2.1.2.20001226092136.039ad860@mail.bayarea.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

At 04:39 PM 12/29/2000 -0500, Edward Lewis wrote:
>The effort to define a generic registrar registry protocol has been
>underway for some time now, seeking input from various groups.  Little or
>no interest has been expressed until now, hence the compressed schedule
>presented in the charter.  Interest and attendence at the BOF meeting in
>San Diego was much greater than anticipated.

Well IMHO it was totally expected... what possible interest would there be 
in a generic RRP if there were no new TLD's issued?  The progressive 
members ccTLD community has been waiting for this as well ..timing is 
everything and the critical mass now exists.


>Although the hope is that the existing documents are in good shape, the
>desire is to generate a protocol that is beneficial to all involved and in
>a timely manner.  Although we would like to have quick results, arriving at
>a solid protocol is more important than the schedule.

Well I'm not sure I agree here.. there is a genuine dilemma here caused by 
ICANN process <suprise>. Whereas it is clear that there was no critical 
mass for a XRRP until new TLD's were issued but now there is a serious 
problem of time to market among the new registry entrants and the desire of 
the registrar community NOT to have competing standards out there.

That is just as important as a solid protocol...and the business of our 
registrars will be seriously impaired if we have multiple proposals out 
there or we stall and delay.

>  Bare in mind that
>delays in achieving the protocol specification may have an impact on the
>registry to registrar business model for some time.

Well I don't know about your business model but that is unacceptable to 
mine. I cant speak for my TUCOWS friends but I cant imagine they want this 
process dragged out.

  We cant have any delays here for any number of reasons including the 
public expatiation that these new TLD's have been created and need to be 
put in place and the need to prove to ICANN  that the "proof of concept" 
will work.


>With this in mind, what is the feeling about:
>Apr, 2001       WG agreement on functional requirements for protocol
>May, 2001       Initial specification of provreg protocol

I would accelerate this to Requirements by Feb , by April have the 
specification ready and by IETF 50 we think about wraping things up.


>This allows for a face to face meeting at the next IETF (providing the WG
>is formed) before the deadline for the two documents.  But, please,
>continue to provide comments on the existing documents in a timely fashion.


Well I'm going to propose that we discuss with our Area Director Patrik the 
possibility of some off-site meetings to accelerate the requirements and 
design process. This is standard procedure within the  IETF when a 
consensus within the WG exists that such meetings are necessary. The list 
is always the central focus of the WG but such off sites have the advantage 
of focusing attention on the problem among a highly motivated group of 
participants. These meetings have worked with great success in the past and 
given the unique situation here and the market pressures for new registries 
to be up and running is a short period of time I believe this is a good idea.

The reason I'm suggesting this is my belief that there is already rough 
consensus on what this protocol looks like (transport a XML something) and 
the core problems are defining the schemas , preparing them for an IANA 
registration procedure ( see  draft-mealling-iana-xmlns-registry-00.txt) , 
and deciding on a transport and security model ( I favor BEEP) since I'm 
sure no one wants to invent a new transport or security model for this.

Extensibility in this model is achieved by the abstraction of the XML 
objects from the transport layer and the detailed description of the 
business rules associated with the XML objects. Clearly the business rules 
for TLD registration would be different from IP address requests, telephone 
numbers or teachers accessing a registry of student records etc.

Indeed there may be different business rules between TLD registries. Our 
colleagues at .DE have been correct to point out that what is required for 
a gTLD is not necessarily what is needed by a ccTLD.  European privacy 
rules being what they are. Indeed the requirements for .COM registration 
might change over time as new gTLD are issued and Verisign looks to "add 
value" in new ways. Such value adds would eventually be reflected in the 
"extensible" registration procedure.

So .. even though the WG has not been approved and we are still debating 
charter and requirements issues ..is there interest in some structured 
off-site meetings?   Washington DC perhaps :-)