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

"Michael Young" <myoung@libertyrms.info> Wed, 03 December 2003 17:51 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 MAA25895 for <provreg-archive@ietf.org>; Wed, 3 Dec 2003 12:51:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb9i-0005GZ-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 12:51:18 -0500
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARb9h-0005GS-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 12:51:17 -0500
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3HaZdF018555 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 3 Dec 2003 18:36:35 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3HaZmK018554 for ietf-provreg-outgoing; Wed, 3 Dec 2003 18:36:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3HaYdF018549 for <ietf-provreg@cafax.se>; Wed, 3 Dec 2003 18:36:34 +0100 (MET)
Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARavR-0004lc-00 for <ietf-provreg@cafax.se>; Wed, 03 Dec 2003 12:36:33 -0500
From: Michael Young <myoung@libertyrms.info>
To: ietf-provreg@cafax.se
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 03 Dec 2003 12:36:33 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
thread-index: AcO5trlFFodKKevSTLGcYWFzx/hXJgAB3x1Q
In-Reply-To: <20031203154852.GG18622@nohope.patoche.org>
Message-Id: <E1ARavR-0004lc-00@mail.libertyrms.com>
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
Content-Transfer-Encoding: 7bit

See comments below:


Michael Young 
-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On
Behalf Of Patrick
Sent: December 3, 2003 10:49 AM
To: ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

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.

-MY You introduced yourself to the thread recently by stating what your
relevant experience is to the issue.  I was clarifying that indeed the
information you provided about yourself was relevant to the thread.  Since
you answered a question posed to registrars, I think it's a reasonable
question.

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.

-MY Right even more so we shouldn't even be concerned with implementations
in this particular working group that are not EPP based.

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.

-MY I do not think I critiqued anyone for voicing an opinion, but don't
voice it if you don't expect it to be commented on.

> 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 ?

-MY No you're right technically we can approach this as if there is no
burden on an existing EPP community or we can be responsible and try to
consider what's been happening in the real world.

> 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.

-MY Again that's highly irresponsible to the community and does not solve
current issues. 

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.

-MY Again that's everyone's problem and I don't believe regular contributors
to this group would condone ignoring registrar's issues, this is why James
quite reasonably posted the question to them on the list.

> 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_.

-MY Seems like you are repeating the same broken argument that we shouldn't
care about the registrars who are dealing with implementations based on
varying submitted EPP documents.  In my opinion we should care what their
burdens are.    

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.

-MY Since there are no obvious candidate objects at this time to extend RGP
to, its safe to say that if that ever occurred that would represent a
reasonable argument to consider new objects and/or additional extensions at
that time.  RGP today is an object specific grace period, extensions of RGP
would likely be specific to new objects.  RGP is an extremely complex policy
in of itself, and it can't be lightly applied for any other use without a
long consensus building process.  Any extension of RGP that was not put
through this process would represent a proprietary implementation.


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.''