[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, epp-rtk-devel <epp-rtk-devel@lists.sourceforge.net>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Thu, 14 Jun 2001 20:27:41 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: [Epp-rtk-devel] RE: ROID Placement

> -----Original Message-----
> From: Dan Kirkdorffer [mailto:dan.kirkdorffer@enom.com]
> Sent: Thursday, June 14, 2001 6:01 PM
> To: 'Rick H Wesson'
> Cc: 'Daniel Manley'; Hollenbeck, Scott; Damaraju, Ayesha;
> 'ietf-provreg@cafax.se'; epp-rtk-devel
> Subject: RE: [Epp-rtk-devel] RE: ROID Placement
> 
> 
> > we could just go to release 10 but what would that mean...
> 
> A difference in expectations.  You and I know 0.3 code will change.
Bosses
> who tell me what to do barely understand that.  1.0 code is a level that
> says we may deprecate, but we won't break code.  Once registrars have
coded
> to a 1.0 spec then they should expect that code to work in 1.1.
> 
> The issue here is time.  Sunrise for .info is in 11 days, as far as I
know.
> I'm developing code for that.  Things must be stable, regardless of what
is
> being schemed.
> 
> Or sunrise must be pushed back.
> 
> It is the difference between R&D and Production.  R&D must not impact
> Production.

If "things must be stable", as Rick said you won't get that until an RFC or
RFCs are published.  Even then things can change as the protocol moves
through the RFC states of proposed standard, draft standard, and standard.

The WG has to have the freedom to revisit requirement and design decisions
as time and experience demonstrate a need for evolution.  I really don't
think we're at a point where we can declare victory and stop design work.
Until we are, change is a certainty and the scope of change isn't.

<Scott/>

Home | Date list | Subject list