Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal

Patrick <pat+ietf@patoche.org> Wed, 03 December 2003 15:59 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20897 for <provreg-archive@ietf.org>; Wed, 3 Dec 2003 10:59:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZPp-0003Mz-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 10:59:49 -0500
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARZPn-0003Mr-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 10:59:48 -0500
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3Fn0dF017405 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 3 Dec 2003 16:49:00 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3FmxbN017404 for ietf-provreg-outgoing; Wed, 3 Dec 2003 16:48:59 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from nohope.patoche.org ([62.160.23.78]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3FmwdF017396 for <ietf-provreg@cafax.se>; Wed, 3 Dec 2003 16:48:58 +0100 (MET)
Received: from nohope.patoche.org (localhost.localdomain [127.0.0.1]) by nohope.patoche.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB3FmqfI021979 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 3 Dec 2003 16:48:53 +0100
Received: (from patrick@localhost) by nohope.patoche.org (8.12.3/8.12.3/Debian-6.6) id hB3Fmqlv021977; Wed, 3 Dec 2003 16:48:52 +0100
Date: Wed, 03 Dec 2003 16:48:52 +0100
From: Patrick <pat+ietf@patoche.org>
To: ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Message-ID: <20031203154852.GG18622@nohope.patoche.org>
References: <20031203122940.GC17279@nohope.patoche.org> <E1ARYz8-0002f2-00@mail.libertyrms.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1ARYz8-0002f2-00@mail.libertyrms.com>
User-Agent: Mutt/1.3.28i
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD 9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

On Wed, Dec 03, 2003 at 10:32:10AM -0500, Michael Young took time to write:
> You don't specifiy that you actually have implemented RGP via the renew
> command extension for any registries.  Given that you state its been six
> months since you implemented epp clients, it seems you couldn't have done so
> for RGP(renew ext approach) which came in later than that.

I do not see how this information can be useful to our work.
In fact I do not see that this WG should put in stone what appears to
be current implementations. It should develop a sane standard, and if
things are not finally as they are today in the wild, it is not a
problem of this WG.

As someone doing implementations, I prefer James approach on this
issue, and that is only what I am saying, since people asked.
And when not coding, I can read drafts and see what I prefer, thanks
for asking.

> Also we have a silent majority of well over a hundred registrars that are
> using RGP via the renew command extension today. 

And then what ?
Because everyone is doing something, this WG is forbidden to specify
things otherwise ?

> I have yet to see any
> registrars come into the list and specifically say they have a desire to
> reimplement the current EPP approach to RGP.  The gains in adopting a new
> command for the community at large are not greater than the efforts to
> redeploy an entirely new approach in EPP registries when an
> adequate/workable approach exists.  After all we are talking about EPP
> concerns in this group, not RRP concerns.  

Sorry, but EPP not being right now a standard, and not even an RFC,
what people are doing right now is *irrelevant* to what is done with
the standard.

As far am I aware, this thread talks about what is in
draft-hollenbeck-epp-rgp-01.txt or what will be.
So, if people already started to use a *draft* to implement EPP, and
then add their own specifics like RGP, it is *their* problem.

> I go back to a simple statement.
> 
> "If it aint broke, don't fix it."

Sorry, but this has nothing to do with the problem in hand.
Since the ``it'' (an EPP _standard_ with extensions for RGP for
example) does not exist _yet_.

We can even say this it *is* broken, since I will be happy to learn
how you will handle RGP on other objects than domain name, with a
domain:renew extension.

PS: please no CC to me, I'm subscribed, and please watch your quotes.

-- 
Patrick.
``Never argue with an idiot. He'll drag you down to his level,
then beat you with experience.''