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

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Dec 2003 14:09:30 -0500

Janusz,

When initially discussing this with Scott, my thought was that RGP could
apply to more objects than just domains.  I know of other provisioned
objects that could benefit from an RGP like feature (i.e. E-mail
Forwarding).  In this, RGP would become another verb that that could be
extended by command mappings similar to the core verbs (i.e. Domain RGP and
E-mail Forwarding RGP) each with elements specific to each object.  From a
purest perspective this made sense, but I felt it was too complicated for
now.  By combining the object, in this case domain, with the protocol
extension, I don't believe it invalidates the use of the protocol extension
for adding a new verb.     

My intention of the initial e-mail was to propose the concept of the rgp
protocol extension and not to define the final specification.  Elements like
<rgp:domain> and <rgp:period> could easily be added, since it would have its
own XML schema.  

I disagree with your assertion that a protocol extension should not be
directly associated with existing object mappings.  Since you are defining a
new verb, you can define exactly what objects it applies to.  This could be
an extensible object like described in the first paragraph or it could be a
specific object like domain.  Since domain is the predominate object for
EPP, limiting the verbs to check, create, update, info, renew, delete, and
transfer is too limiting. 

I hope some Registrars are following this so that we get their feedback.
What we have here are two registries with different requirements for rgp
(one with a renew feature and one without).  If the specification is going
to be registry independent it should support both cleanly.  I don't like
coupling rgp with update based on my previous comments related to confusion
of what update elements should be accepted, but for me an update would match
better than a renew.  In our case, no updates are allowed during the
redemption period.    

Any Registrar feedback?  The three options right now include:

RGP as renew command-response extension.  The typical use case is:
1. Domain is auto renewed
2. Registrar deletes Domain via a <domain:delete>
3. Registrar sends a <domain:renew> with a <domain:period> of 0 (supporting
a period is registry specific) with the rgp request extension
4. Registrar sends a <domain:renew> with a <domain:period> of 0 with the rgp
report extension
5. Domain is ok

RGP as update command-response extension.  The typical use case is:
1. Domain is auto renewed
2. Registrar deletes Domain via a <domain:delete>
3. Registrar sends a <domain:update> with no updates (supporting update
elements is registry specific) with the rgp request extension
4. Registrar sends a <domain:renew> with no updates (supporting update
elements is registry specific) with the rgp report extension
5. Domain is ok

RGP as protocol extension.  The typical use case is:
1. Domain is auto renewed
2. Registrar deletes Domain via a <domain:delete>
3. Registrar sends an <rgp:request> with an optional <rgp:period> element.
4. Registrar sends an <rgp:report>
5. Domain is ok

The command-response extension to the <domain:info> still applies with all
three options.  

JG

James F. Gould
VeriSign Naming and Directory Services
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 12:26 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal 

James,

I don't think protocol extension offers more clarity than command response
extension. In the first approach the verb is provided in explicit way but
the object the verb is releted to is missing. Looking at the syntax you
attached it is not obvious that <rgp:restore> is a domain related
operation. In the second approach the object is clearly defined but the
verb is defined in implicit manner.

The protocol extension approach is more difficult to implement. With this
approach the rgp syntax will be more complex. The samples you attached to
your original proposal are incorrect and they offer very simplistic view
of necessary changes to rgp draft document. I pointed that out in my first
response. More complex rgp syntax can be used as a rough but objective
measure for determining amount of efforts required for implementing a
particular approach. Subjective references to a particular server
implementation attempts SHOULD NOT be used as a such measure.

You said in one of your responses in the thread that if protocol extension
is not adopted for rgp then "there is really no purpose for defining the
protocol extension in EPP". I disagree with that judgment. An example for
a usefull application of protocol extension would a be a new verb that is
not directly associated with existing object mappings. Something like poll
or hello command.

Janusz Sienkiewicz

---

From: "Ram Mohan" <[email-masked]>
Date: Tue, 2 Dec 2003 18:03:05 -0500

James,
> (one with a renew feature and one without).

I have been told that Neulevel/Neustar (.BIZ, .US, .CN, .TW operator) has a
<renew> extension for RGP rather than an update.  Perhaps someone from
Neulevel/Neustar on this list can comment more authoritatively.

-Ram
--------------------------------------------------------------
Ram Mohan
Vice President, Business Operations
Chief Technology Officer
Afilias (http://www.afilias.info)
p: 215-706-5700 x103; f: 215-706-5701
e: [email-masked]
--------------------------------------------------------------
----- Original Message ----- 
From: "Gould, James" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Hollenbeck, Scott" <[email-masked]>
Sent: Tuesday, December 02, 2003 2:09 PM
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

---

From: Patrick <[email-masked]>
Date: Wed, 3 Dec 2003 13:29:40 +0100

> Any Registrar feedback?  The three options right now include:

I am not working in a Registrar right now, but was 6 months ago, and
hope to be soon again. I implemented RRP & EPP clients for 5
registries back then, and still working on this open source project.

> 4. Registrar sends a <domain:renew> with a <domain:period> of 0 with the rgp

(I find the domain:period=0 to be a awful hack)

[..]

> 4. Registrar sends an <rgp:report>

For me, this is the cleaner way, since RGP is a totally new feature.
We could imagine that it is used for contacts[1], for example, and then
domain:renew would not apply easily. Ditto for any other objects
managed at the Registry.

[1] with new requirements to check contacts' validity, we can imagine
that someone would like to work as: when a contact is not validated,
delete it, but then provide the functionnality of a restore, as a
last chance.

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

---

From: "Michael Young" <[email-masked]>
Date: Wed, 3 Dec 2003 10:32:10 -0500

Hi Patrick,

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.
Also we have a silent majority of well over a hundred registrars that are
using RGP via the renew command extension today.  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.  

I go back to a simple statement.

"If it aint broke, don't fix it."

Michael Young 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Patrick
Sent: December 3, 2003 7:30 AM
To: [email-masked]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

> Any Registrar feedback?  The three options right now include:

I am not working in a Registrar right now, but was 6 months ago, and hope to
be soon again. I implemented RRP & EPP clients for 5 registries back then,
and still working on this open source project.

> 2. Registrar deletes Domain via a <domain:delete> 3. Registrar sends a 
> <domain:renew> with a <domain:period> of 0 (supporting a period is 
> registry specific) with the rgp request extension 4. Registrar sends a 
> <domain:renew> with a <domain:period> of 0 with the rgp report 
> extension 5. Domain is ok

[..]

> 2. Registrar deletes Domain via a <domain:delete> 3. Registrar sends 
> an <rgp:request> with an optional <rgp:period> element.

For me, this is the cleaner way, since RGP is a totally new feature.
We could imagine that it is used for contacts[1], for example, and then
domain:renew would not apply easily. Ditto for any other objects managed at
the Registry.

[1] with new requirements to check contacts' validity, we can imagine that
someone would like to work as: when a contact is not validated, delete it,
but then provide the functionnality of a restore, as a last chance.

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

---

From: Patrick <[email-masked]>
Date: Wed, 3 Dec 2003 16:48:52 +0100

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

> 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

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.

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

---

From: "Michael Young" <[email-masked]>
Date: Wed, 3 Dec 2003 12:36:33 -0500

See comments below:

Michael Young 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Patrick
Sent: December 3, 2003 10:49 AM
To: [email-masked]
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.

-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 

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.

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

---

From: janusz sienkiewicz <[email-masked]>
Date: Wed, 03 Dec 2003 13:41:08 -0500

Patrick,
in your response you expressed strong support for protocol extension approach. As
the chief reason for that you could imagine RGP syntax to be used for contacts or
other objects.

Since with protocol extension RGP request is not tied to a particular object
mapping (domain or contact) how would use the syntax proposed by James? It is
impossible without adding some real hacks into rgp syntax.

Applying rgp syntax for other than domain objects actually strongly favors
command response extension approach.

Janusz Sienkiewicz