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

[janusz sienkiewicz <[e-mail]>]

Scott,
thanks for directing all participants of the RGP thread (not excluding myself)
to this document. I somehow missed release of this important document. I was
looking for some extension guidelines mostly in "Extensible Provisioning
Protocol" (section 2.7) and obviously I could not find anything satisfactory.

Following the guidelines is the best way to extend the protocol functionality
without loosing reasonable level of interoperability.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> At this point I think it would be worthwhile for the people who are
> discussing this topic to re-read section 3 of the WG's "Guidelines for
> Extending the Extensible Provisioning Protocol" document.  That document has
> completed WG and IETF last call and is thus supposed to represent our best
> thinking on the topic.
>
> Folks advocating protocol-level or object-level extension should then
> explain how the answer to the first question in section 3 is an unequivocal
> "no".
>
> -Scott-




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB4FOYdF029908 for <[e-mail]>; Thu, 4 Dec 2003 16:24:34 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB4FOY6e029907 for ietf-provreg-outgoing; Thu, 4 Dec 2003 16:24:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB4FOQdF029902 for <[e-mail]>; Thu, 4 Dec 2003 16:24:30 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARvL1-0008Q9-00; Thu, 04 Dec 2003 10:24:19 -0500
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 2003 10:24:20 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Scott,
thanks for directing all participants of the RGP thread (not excluding myself)
to this document. I somehow missed release of this important document. I was
looking for some extension guidelines mostly in "Extensible Provisioning
Protocol" (section 2.7) and obviously I could not find anything satisfactory.

Following the guidelines is the best way to extend the protocol functionality
without loosing reasonable level of interoperability.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> At this point I think it would be worthwhile for the people who are
> discussing this topic to re-read section 3 of the WG's "Guidelines for
> Extending the Extensible Provisioning Protocol" document.  That document has
> completed WG and IETF last call and is thus supposed to represent our best
> thinking on the topic.
>
> Folks advocating protocol-level or object-level extension should then
> explain how the answer to the first question in section 3 is an unequivocal
> "no".
>
> -Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB4Ce5dF028687 for <[e-mail]>; Thu, 4 Dec 2003 13:40:05 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB4Ce5N7028686 for ietf-provreg-outgoing; Thu, 4 Dec 2003 13:40:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB4Ce4dF028681 for <[e-mail]>; Thu, 4 Dec 2003 13:40:04 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB4Ce3ha016865 for <[e-mail]>; Thu, 4 Dec 2003 07:40:03 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5STBRT>; Thu, 4 Dec 2003 07:40:03 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Thu, 4 Dec 2003 07:40:02 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

At this point I think it would be worthwhile for the people who are
discussing this topic to re-read section 3 of the WG's "Guidelines for
Extending the Extensible Provisioning Protocol" document.  That document has
completed WG and IETF last call and is thus supposed to represent our best
thinking on the topic.

Folks advocating protocol-level or object-level extension should then
explain how the answer to the first question in section 3 is an unequivocal
"no".

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3KXodF020416 for <[e-mail]>; Wed, 3 Dec 2003 21:33:50 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3KXoxo020415 for ietf-provreg-outgoing; Wed, 3 Dec 2003 21:33:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3KXmdF020410 for <[e-mail]>; Wed, 3 Dec 2003 21:33:49 +0100 (MET)
Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARdgx-0007XA-00; Wed, 03 Dec 2003 15:33:47 -0500
From: "Michael Young" <[e-mail]>
To: "'Gould, James'" <[e-mail]>, <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 3 Dec 2003 15:33:46 -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: AcO5xr6qIAp9IOuMTJqM5GU26qgThQADuZgw
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

James thank you for clarifying that the intent of this thread is solve a
cross-protocol registry/registrar implementation issue with RGP.  While I am
indeed in favour of trying to accommodate the general issue, this working
group has not been a forum for solving RRP to EPP issues to date.  Many of
us have had RRP to EPP interoperability issues to solve for, and generally
speaking, the focus of provreg has been not been to work on cross-protocol,
cross registry issues.  The basis for clear argument for reworking EPP draft
approaches has been based on EPP issues alone.

Having said that I agree there is a worthwhile problem to solve,(its only
going to make registrars life easier if we implement consistently) but I
don't think this is the correct forum.  I am happy to take the RGP
discussion off-line with Scott and yourself and see if we can come up with a
reasonable approach to the issue - so we can end this thread and not end up
with contending drafts down the line.  
     
Michael Young

 
-----Original Message-----
From: Gould, James [mailto:[e-mail]] 
Sent: December 3, 2003 12:56 PM
To: 'Michael Young'; [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

Mike,

You have a working version of the existing specification in a single
registry.  The .com/.net ICANN agreement for RGP does not allow for a renew
feature or any updates for that matter while a domain has a redemption
status.  You can look at RRP as a reference for how it is handled in another
running registry, which is not by extending the renew command.  

For the rgp extension to be a standard across registries it needs to support
the basic set of requirements across all registries.  I believe it to be
unintuitive for our Registrars to send rgp commands via a domain:renew.  The
fact that you implemented to the current version of the specification does
not make it a defacto standard.  Changes can and will occur as more
registries implement RGP via EPP.  Just look at what has happened from EPP
00 to EPP 09.  We implemented to different versions of EPP knowing that it
would change based on community input.  

I would like to hear from the silent majority.  These are the same set of
Registrars that have to integrate with other registries including the VNDS
registries.   

JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Young
Sent: Wednesday, December 03, 2003 10:32 AM
To: 'Patrick'; [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Patrick
Sent: December 3, 2003 7:30 AM
To: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

On Tue, Dec 02, 2003 at 02:09:30PM -0500, Gould, James took time to write:
> 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.

> 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

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

[..]

> 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

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3KVAdF020376 for <[e-mail]>; Wed, 3 Dec 2003 21:31:10 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3KVAkH020375 for ietf-provreg-outgoing; Wed, 3 Dec 2003 21:31:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3KV9dF020370 for <[e-mail]>; Wed, 3 Dec 2003 21:31:09 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB3KV8ha004650; Wed, 3 Dec 2003 15:31:08 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5QANLA>; Wed, 3 Dec 2003 15:31:07 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, Patrick <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 3 Dec 2003 15:31:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Janusz, 

The extension of the restore (I renamed it to be more generic) protocol
extension would be similar to the extensibility built in the base EPP
specification for command mappings, where the verbs (restore:request and
restore:report) would be extensible by object specific tags.  

For example:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <extension>
C:     <restore xmlns:restore="urn:ietf:params:xml:ns:restore-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:restore-1.0
C:       restore-1.0.xsd">
C:		<restore:request>
C:              <domainres:request 
C:
xmlns:domainres="urn:ietf:params:xml:ns:domainrestore-1.0" 
C:                 xsi:schemaLocation="urn:ietf:params:xml:ns:domainrestore
-1.0 
C:                                     domainrestore.xsd">
C:                 <domainres:name>example.com</domainres:name>
C:                 <domainres:period unit="y">2</domainres:period>
C:              </domainres:domain>
C:          </restore:request>
C:       <restore:clTRID>ABC-12345</restore:clTRID>
C:    </restore>
C:  </extension>
C:</epp>

Both "urn:ietf:params:xml:ns:restore-1.0" and "urn:ietf:params:xml:ns:
domainrestore-1.0" would be reported as a <svcExtension> in the <greeting>
and the <login>.  For example the greeting might look like the following:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
  S:     epp-1.0.xsd">
  S:  <greeting>
  S:    <svID>Example EPP server epp.example.com</svID>
  S:    <svDate>2000-06-08T22:00:00.0Z</svDate>
  S:    <svcMenu>
  S:      <version>1.0</version>
  S:      <lang>en</lang>
  S:      <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
  S:      <svcExtension>
  S:        <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI>
  S:        <extURI>urn:ietf:params:xml:ns:domainrestore-1.0</extURI>
  S:      </svcExtension>
  S:    </svcMenu>
  S:    <dcp>
  S:      <access><all/></access>
  S:      <statement>
  S:        <purpose><admin/><prov/></purpose>
  S:        <recipient><ours/><public/></recipient>
  S:        <retention><stated/></retention>
  S:      </statement>
  S:    </dcp>
  S:  </greeting>
  S:</epp>


This raises restore:request and restore:report to the same level as the core
verbs.

JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of janusz sienkiewicz
Sent: Wednesday, December 03, 2003 1:41 PM
To: Patrick
Cc: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3IfGdF019221 for <[e-mail]>; Wed, 3 Dec 2003 19:41:16 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3IfGOs019220 for ietf-provreg-outgoing; Wed, 3 Dec 2003 19:41:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3IfEdF019215 for <[e-mail]>; Wed, 3 Dec 2003 19:41:15 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARbvv-0005qo-00; Wed, 03 Dec 2003 13:41:07 -0500
Message-ID: <[e-mail]>
Date: Wed, 03 Dec 2003 13:41:08 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrick <[e-mail]>
CC: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p  roposal
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3HtjdF018708 for <[e-mail]>; Wed, 3 Dec 2003 18:55:45 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3HtjEf018707 for ietf-provreg-outgoing; Wed, 3 Dec 2003 18:55:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3HthdF018702 for <[e-mail]>; Wed, 3 Dec 2003 18:55:43 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB3Htgha029475; Wed, 3 Dec 2003 12:55:42 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5QAK1H>; Wed, 3 Dec 2003 12:55:42 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'Michael Young'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 3 Dec 2003 12:55:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Mike,

You have a working version of the existing specification in a single
registry.  The .com/.net ICANN agreement for RGP does not allow for a renew
feature or any updates for that matter while a domain has a redemption
status.  You can look at RRP as a reference for how it is handled in another
running registry, which is not by extending the renew command.  

For the rgp extension to be a standard across registries it needs to support
the basic set of requirements across all registries.  I believe it to be
unintuitive for our Registrars to send rgp commands via a domain:renew.  The
fact that you implemented to the current version of the specification does
not make it a defacto standard.  Changes can and will occur as more
registries implement RGP via EPP.  Just look at what has happened from EPP
00 to EPP 09.  We implemented to different versions of EPP knowing that it
would change based on community input.  

I would like to hear from the silent majority.  These are the same set of
Registrars that have to integrate with other registries including the VNDS
registries.   

JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Young
Sent: Wednesday, December 03, 2003 10:32 AM
To: 'Patrick'; [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Patrick
Sent: December 3, 2003 7:30 AM
To: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

On Tue, Dec 02, 2003 at 02:09:30PM -0500, Gould, James took time to write:
> 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.

> 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

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

[..]

> 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

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


Return-Path: <[e-mail]>
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 <[e-mail]>; 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 [e-mail] 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 <[e-mail]>; 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 <[e-mail]>; Wed, 03 Dec 2003 12:36:33 -0500
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 3 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: <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

See comments below:


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



Return-Path: <[e-mail]>
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 <[e-mail]>; 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 [e-mail] 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 <[e-mail]>; 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, 3 Dec 2003 16:48:52 +0100
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
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: [e-mail]
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.''


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3FWGdF017272 for <[e-mail]>; Wed, 3 Dec 2003 16:32:16 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3FWGeB017271 for ietf-provreg-outgoing; Wed, 3 Dec 2003 16:32:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3FWFdF017258 for <[e-mail]>; Wed, 3 Dec 2003 16:32:15 +0100 (MET)
Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARYz8-0002f2-00; Wed, 03 Dec 2003 10:32:14 -0500
From: "Michael Young" <[e-mail]>
To: "'Patrick'" <[e-mail]>, <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 3 Dec 2003 10:32:10 -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: AcO5mvCl/MDHyxriRH663fi204M7bQAFb+oA
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Patrick
Sent: December 3, 2003 7:30 AM
To: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

On Tue, Dec 02, 2003 at 02:09:30PM -0500, Gould, James took time to write:
> 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.

> 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

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

[..]

> 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

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3CThdF016165 for <[e-mail]>; Wed, 3 Dec 2003 13:29:43 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3CThFC016164 for ietf-provreg-outgoing; Wed, 3 Dec 2003 13:29:43 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nohope.patoche.org ([62.160.23.78]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3CTfdF016159 for <[e-mail]>; Wed, 3 Dec 2003 13:29:42 +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 hB3CTefI018070 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 3 Dec 2003 13:29:40 +0100
Received: (from patrick@localhost) by nohope.patoche.org (8.12.3/8.12.3/Debian-6.6) id hB3CTeG9018068; Wed, 3 Dec 2003 13:29:40 +0100
Date: Wed, 3 Dec 2003 13:29:40 +0100
From: Patrick <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
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: [e-mail]
Precedence: bulk

On Tue, Dec 02, 2003 at 02:09:30PM -0500, Gould, James took time to write:
> 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.

> 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

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

[..]

> 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

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2N3GdF008982 for <[e-mail]>; Wed, 3 Dec 2003 00:03:16 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB2N3GJf008981 for ietf-provreg-outgoing; Wed, 3 Dec 2003 00:03:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [170.224.17.215]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2N3FdF008976 for <[e-mail]>; Wed, 3 Dec 2003 00:03:15 +0100 (MET)
Received: from eagle (ismtp.afilias.com [216.217.55.254]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id hB2N3D4S005334; Tue, 2 Dec 2003 18:03:13 -0500
Message-ID: <0aa901c3b928$7551a060$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Gould, James" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal 
Date: Tue, 2 Dec 2003 18:03:05 -0500
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk

James,
> What we have here are two registries with different requirements for rgp
> (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: [e-mail]
--------------------------------------------------------------
----- Original Message ----- 
From: "Gould, James" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; "Hollenbeck, Scott" <[e-mail]>
Sent: Tuesday, December 02, 2003 2:09 PM
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal


> 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
> [e-mail]
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, December 02, 2003 12:26 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2J9YdF006590 for <[e-mail]>; Tue, 2 Dec 2003 20:09:34 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB2J9YO7006589 for ietf-provreg-outgoing; Tue, 2 Dec 2003 20:09:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2J9XdF006584 for <[e-mail]>; Tue, 2 Dec 2003 20:09:33 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB2J9Wha005118; Tue, 2 Dec 2003 14:09:32 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5P0YPC>; Tue, 2 Dec 2003 14:09:31 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail], "Hollenbeck, Scott" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal 
Date: Tue, 2 Dec 2003 14:09:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

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
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, December 02, 2003 12:26 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
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




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2HQBdF005500 for <[e-mail]>; Tue, 2 Dec 2003 18:26:11 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB2HQBxd005499 for ietf-provreg-outgoing; Tue, 2 Dec 2003 18:26:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2HQ9dF005494 for <[e-mail]>; Tue, 2 Dec 2003 18:26:10 +0100 (MET)
Received: from acdc.int.libertyrms.com ([10.1.2.254] helo=libertyrms.info) by mail.libertyrms.com with smtp (Exim 3.22 #3 (Debian)) id 1AREHk-0006g6-00; Tue, 02 Dec 2003 12:26:04 -0500
Received: from 64.229.18.206 (SquirrelMail authenticated user janusz) by look.libertyrms.com with HTTP; Tue, 2 Dec 2003 12:26:04 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 2 Dec 2003 12:26:04 -0500 (EST)
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal 
From: <[e-mail]>
To: <[e-mail]>
X-Priority: 3
Importance: Normal
Cc: <[e-mail]>, <[e-mail]>
X-Mailer: SquirrelMail (version 1.2.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

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






Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2DtFdF003271 for <[e-mail]>; Tue, 2 Dec 2003 14:55:15 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB2DtFFw003270 for ietf-provreg-outgoing; Tue, 2 Dec 2003 14:55:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB2DtDdF003265 for <[e-mail]>; Tue, 2 Dec 2003 14:55:13 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB2DtCha025403; Tue, 2 Dec 2003 08:55:12 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5SSHMC>; Tue, 2 Dec 2003 08:55:11 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'Michael Young'" <[e-mail]>, "'janusz sienkiewicz'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: [e-mail], "Nylund, Joel" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Tue, 2 Dec 2003 08:55:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Mike,

What I meant by making the renew feature subordinate to the rgp command is
that as with transfer, create, and renew, there is the ability to specify
the registration period.  If rgp has an optional renew feature, than it to
should have the ability to specify the registration period.  I did not mean
to make an rgp renew command, but to simply add an optional <rgp:period>
element to allow for it.  

By latching a completely different action (i.e. rgp:report) to an existing
one (i.e. domain:renew, domain:update, or domain:delete) the only thing that
is being reused might be the verb name and maybe one or two other
attributes.  The reuse of the verb doesn't make sense since it doesn't
really match the intent of the new action and the reuse of the attribute
still leaves open what to do with the attributes that are not reused (i.e.
ignore, report error).  A command-response extension is perfect for adding
attributes that weren't previously defined, but not for changing the entire
meaning of the action.  Sending an rgp:report with a domain:renew is a good
example of a misuse of a command-response extension, since it has absolutely
nothing to do with renew.    

When I reviewed the EPP specifications and saw the Protocol Extension, I
believed that it was the answer for these kinds of problems.  As I stated
before, rgp could be implemented as an extension to any one of the standard
commands, but this is like writing a single doIt function that takes a large
number of arguments were the values make sense in one context but not in
another.  I prefer the OO concept of adding a new method.

Based on this thread, I need clarification of a best practice for use of the
EPP Protocol Extension.  I have another extension that I'm considering
making a Protocol Extension, based on the same reasoning.  It looks like
sticking with the existing verbs is preferred by some over adding new ones.


Any comments from the Registrars?


JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: Michael Young [mailto:[e-mail]] 
Sent: Monday, December 01, 2003 6:15 PM
To: 'Gould, James'; 'janusz sienkiewicz'; 'Hollenbeck, Scott'
Cc: [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gould, James
Sent: Monday, December 01, 2003 5:16 PM
To: 'janusz sienkiewicz'; Hollenbeck, Scott
Cc: '[e-mail]'
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

Scott & Janusz,

I agree that specifying a period of zero is cleaner if the renew command is
extended for rgp.  

I still believe that the command-response extension is the wrong way to go
for rgp.  Server functions would have to be updated to differentiate between
a standard renew and an rgp (request & report) renew.

MY- I don't see why this is more effort that introducing a new command.

If verb extensions are made by extending either renew or update, than the
registry has to make
policy decisions related to what standard attributes to ignore or report
errors on.  

MY- that problem exists in EPP implementations already - we have to deal
this already - no added burden there.

I prefer making the validation more explicit using an XML
schema.  Morphing a renew or update into an rgp request or rgp report is
mixing verbs that really don't belong together.  

-MY since the whole RGP implementation is essentially a settlement action;
it seems perfectly reasonable to extend either the renew or delete commands
as they are associated with the transactions that lead (or don't lead)to the
settlement action.  Renew is a better choice as its less overloaded than the
delete command. I don't see a valid argument here for burdening registrars
with a new command.  

The VNDS rgp does not have
a renew feature, so logically it shouldn't involve a renew command.

-MY I still don't see how this is relevant to the discussion, if anything
its driving the argument to extend the delete command which I am sure no one
wants to do.

Similarly, while a domain is in pendingDelete status we don't allow any
updates to it, but if rgp is mixed with an update than what do we do about
the specified updates?  If we disallow all updates for an rgp command, than
there is no point in making it an extension of the update command.
If rgp has a renew feature, make the renew function subordinate to the rgp
request command and not the other way around.  If rgp is not a good
candidate for a protocol extension than what is?  

-MY If your argument is that extending renew is confusing to registrars,
then how do you defend suggesting an RGP specific renew command - you don't
think that one renew command plus an extension renew command under an RGP
command is not a little more difficult to follow - this is re-inventing the
wheel just to make it round again.  There are implementations in place using
the renew command extensions; I don't see the point in revisiting this with
these arguments.  They are not compelling enough to warrant starting this
thread all over again. 


-Michael Young



JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of janusz sienkiewicz
Sent: Monday, December 01, 2003 2:29 PM
To: Hollenbeck, Scott
Cc: '[e-mail]'
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I also prefer required zero value for RGP situations. Such behavior would
improve interoperatibility of RGP implementations.

Janusz Sienkiewicz


"Hollenbeck, Scott" wrote:

> > The wording for <renew> command in rgp draft document could
> > be modified to
> > indicate that the absence of period element in <renew> part
> > or value ZERO
> > should indicate that renewal should not be a part of rgp
> > restore. Another
> > option would be to force server to ignore the value of
> > <period> element and
> > assume certain value.
>
> I've thought about the zero value being appropriate here.  It's certainly
an
> approach.
> > > If people are already doing RGP as an extended renewal,
> > what are they doing
> > > about the renewal part of the command?
> >
> > I am aware of one implementation that just ignores the value
> > of <period>
> > element and assumes ZERO if rgp extension is present.
>
> Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
> That would make data reconciliation very difficult in the future if one
> tries to reconcile a non-zero-period <renew> command that was processed
> without error, but with no change to the expiration date.  I'd rather
> require a period of zero for RGP situations.

>
>
> -Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1NF9dF024141 for <[e-mail]>; Tue, 2 Dec 2003 00:15:09 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1NF9jT024139 for ietf-provreg-outgoing; Tue, 2 Dec 2003 00:15:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1NF7dF024134 for <[e-mail]>; Tue, 2 Dec 2003 00:15:08 +0100 (MET)
Received: from [10.1.2.227] (helo=mwy2) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AQxFy-0006vn-00; Mon, 01 Dec 2003 18:15:06 -0500
From: "Michael Young" <[e-mail]>
To: "'Gould, James'" <[e-mail]>, "'janusz sienkiewicz'" <[e-mail]>, "'Hollenbeck, Scott'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
Date: Mon, 1 Dec 2003 18:14:53 -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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcO4WzxR1MzpHk5BSryIACxWdRRvCAAAv2qA
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gould, James
Sent: Monday, December 01, 2003 5:16 PM
To: 'janusz sienkiewicz'; Hollenbeck, Scott
Cc: '[e-mail]'
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

Scott & Janusz,

I agree that specifying a period of zero is cleaner if the renew command is
extended for rgp.  

I still believe that the command-response extension is the wrong way to go
for rgp.  Server functions would have to be updated to differentiate between
a standard renew and an rgp (request & report) renew.

MY- I don't see why this is more effort that introducing a new command.

If verb extensions are made by extending either renew or update, than the
registry has to make
policy decisions related to what standard attributes to ignore or report
errors on.  

MY- that problem exists in EPP implementations already - we have to deal
this already - no added burden there.

I prefer making the validation more explicit using an XML
schema.  Morphing a renew or update into an rgp request or rgp report is
mixing verbs that really don't belong together.  

-MY since the whole RGP implementation is essentially a settlement action;
it seems perfectly reasonable to extend either the renew or delete commands
as they are associated with the transactions that lead (or don't lead)to the
settlement action.  Renew is a better choice as its less overloaded than the
delete command. I don't see a valid argument here for burdening registrars
with a new command.  

The VNDS rgp does not have
a renew feature, so logically it shouldn't involve a renew command.

-MY I still don't see how this is relevant to the discussion, if anything
its driving the argument to extend the delete command which I am sure no one
wants to do.

Similarly, while a domain is in pendingDelete status we don't allow any
updates to it, but if rgp is mixed with an update than what do we do about
the specified updates?  If we disallow all updates for an rgp command, than
there is no point in making it an extension of the update command.
If rgp has a renew feature, make the renew function subordinate to the rgp
request command and not the other way around.  If rgp is not a good
candidate for a protocol extension than what is?  

-MY If your argument is that extending renew is confusing to registrars,
then how do you defend suggesting an RGP specific renew command - you don't
think that one renew command plus an extension renew command under an RGP
command is not a little more difficult to follow - this is re-inventing the
wheel just to make it round again.  There are implementations in place using
the renew command extensions; I don't see the point in revisiting this with
these arguments.  They are not compelling enough to warrant starting this
thread all over again. 


-Michael Young



JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of janusz sienkiewicz
Sent: Monday, December 01, 2003 2:29 PM
To: Hollenbeck, Scott
Cc: '[e-mail]'
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I also prefer required zero value for RGP situations. Such behavior would
improve interoperatibility of RGP implementations.

Janusz Sienkiewicz


"Hollenbeck, Scott" wrote:

> > The wording for <renew> command in rgp draft document could
> > be modified to
> > indicate that the absence of period element in <renew> part
> > or value ZERO
> > should indicate that renewal should not be a part of rgp
> > restore. Another
> > option would be to force server to ignore the value of
> > <period> element and
> > assume certain value.
>
> I've thought about the zero value being appropriate here.  It's certainly
an
> approach.
> > > If people are already doing RGP as an extended renewal,
> > what are they doing
> > > about the renewal part of the command?
> >
> > I am aware of one implementation that just ignores the value
> > of <period>
> > element and assumes ZERO if rgp extension is present.
>
> Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
> That would make data reconciliation very difficult in the future if one
> tries to reconcile a non-zero-period <renew> command that was processed
> without error, but with no change to the expiration date.  I'd rather
> require a period of zero for RGP situations.

>
>
> -Scott-




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1MFadF023313 for <[e-mail]>; Mon, 1 Dec 2003 23:15:36 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1MFatJ023311 for ietf-provreg-outgoing; Mon, 1 Dec 2003 23:15:36 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1MFYdF023304 for <[e-mail]>; Mon, 1 Dec 2003 23:15:34 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1MFXha016777; Mon, 1 Dec 2003 17:15:33 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5SSBHV>; Mon, 1 Dec 2003 17:15:32 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'janusz sienkiewicz'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Mon, 1 Dec 2003 17:15:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Scott & Janusz,

I agree that specifying a period of zero is cleaner if the renew command is
extended for rgp.  

I still believe that the command-response extension is the wrong way to go
for rgp.  Server functions would have to be updated to differentiate between
a standard renew and an rgp (request & report) renew.  If verb extensions
are made by extending either renew or update, than the registry has to make
policy decisions related to what standard attributes to ignore or report
errors on.  I prefer making the validation more explicit using an XML
schema.  Morphing a renew or update into an rgp request or rgp report is
mixing verbs that really don't belong together.  The VNDS rgp does not have
a renew feature, so logically it shouldn't involve a renew command.
Similarly, while a domain is in pendingDelete status we don't allow any
updates to it, but if rgp is mixed with an update than what do we do about
the specified updates?  If we disallow all updates for an rgp command, than
there is no point in making it an extension of the update command.

If rgp has a renew feature, make the renew function subordinate to the rgp
request command and not the other way around.  If rgp is not a good
candidate for a protocol extension than what is?  


JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of janusz sienkiewicz
Sent: Monday, December 01, 2003 2:29 PM
To: Hollenbeck, Scott
Cc: '[e-mail]'
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I also prefer required zero value for RGP situations. Such behavior would
improve interoperatibility of RGP implementations.

Janusz Sienkiewicz


"Hollenbeck, Scott" wrote:

> > The wording for <renew> command in rgp draft document could
> > be modified to
> > indicate that the absence of period element in <renew> part
> > or value ZERO
> > should indicate that renewal should not be a part of rgp
> > restore. Another
> > option would be to force server to ignore the value of
> > <period> element and
> > assume certain value.
>
> I've thought about the zero value being appropriate here.  It's certainly
an
> approach.
> > > If people are already doing RGP as an extended renewal,
> > what are they doing
> > > about the renewal part of the command?
> >
> > I am aware of one implementation that just ignores the value
> > of <period>
> > element and assumes ZERO if rgp extension is present.
>
> Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
> That would make data reconciliation very difficult in the future if one
> tries to reconcile a non-zero-period <renew> command that was processed
> without error, but with no change to the expiration date.  I'd rather
> require a period of zero for RGP situations.

>
>
> -Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1JT8dF021507 for <[e-mail]>; Mon, 1 Dec 2003 20:29:08 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1JT8G7021506 for ietf-provreg-outgoing; Mon, 1 Dec 2003 20:29:08 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1JT7dF021501 for <[e-mail]>; Mon, 1 Dec 2003 20:29:07 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AQtjF-0003Aw-00; Mon, 01 Dec 2003 14:29:05 -0500
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2003 14:29:06 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I also prefer required zero value for RGP situations. Such behavior would
improve interoperatibility of RGP implementations.

Janusz Sienkiewicz


"Hollenbeck, Scott" wrote:

> > The wording for <renew> command in rgp draft document could
> > be modified to
> > indicate that the absence of period element in <renew> part
> > or value ZERO
> > should indicate that renewal should not be a part of rgp
> > restore. Another
> > option would be to force server to ignore the value of
> > <period> element and
> > assume certain value.
>
> I've thought about the zero value being appropriate here.  It's certainly an
> approach.
> > > If people are already doing RGP as an extended renewal,
> > what are they doing
> > > about the renewal part of the command?
> >
> > I am aware of one implementation that just ignores the value
> > of <period>
> > element and assumes ZERO if rgp extension is present.
>
> Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
> That would make data reconciliation very difficult in the future if one
> tries to reconcile a non-zero-period <renew> command that was processed
> without error, but with no change to the expiration date.  I'd rather
> require a period of zero for RGP situations.

>
>
> -Scott-





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1JCmdF021322 for <[e-mail]>; Mon, 1 Dec 2003 20:12:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1JCm0Z021321 for ietf-provreg-outgoing; Mon, 1 Dec 2003 20:12:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1JCldF021316 for <[e-mail]>; Mon, 1 Dec 2003 20:12:47 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1JCkha009861; Mon, 1 Dec 2003 14:12:46 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5P0FAL>; Mon, 1 Dec 2003 14:12:46 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Mon, 1 Dec 2003 14:12:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> The wording for <renew> command in rgp draft document could 
> be modified to
> indicate that the absence of period element in <renew> part 
> or value ZERO
> should indicate that renewal should not be a part of rgp 
> restore. Another
> option would be to force server to ignore the value of 
> <period> element and
> assume certain value.

I've thought about the zero value being appropriate here.  It's certainly an
approach.
> > If people are already doing RGP as an extended renewal, 
> what are they doing
> > about the renewal part of the command?
> 
> I am aware of one implementation that just ignores the value 
> of <period>
> element and assumes ZERO if rgp extension is present.

Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
That would make data reconciliation very difficult in the future if one
tries to reconcile a non-zero-period <renew> command that was processed
without error, but with no change to the expiration date.  I'd rather
require a period of zero for RGP situations.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1J4idF021218 for <[e-mail]>; Mon, 1 Dec 2003 20:04:44 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1J4ipx021217 for ietf-provreg-outgoing; Mon, 1 Dec 2003 20:04:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1J4hdF021212 for <[e-mail]>; Mon, 1 Dec 2003 20:04:43 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AQtLc-0002lc-00; Mon, 01 Dec 2003 14:04:40 -0500
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2003 14:04:41 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Please see comments below:

"Hollenbeck, Scott" wrote:

> > I think that unless something is really broken with <renew>
> > approach, rgp
> > syntax changes that may impact operating clients should be avoided.
>
> But:
>
> 1. We're talking about an Internet-Draft (meaning "implement at your own
> risk!"), and an individual submission that hasn't been commented on very
> broadly at that.
>
> 2. I think we need to come up with something that we can all implement the
> same way to maximize interoperability opportunities.
>
> Part of what I think is broken is that redemption should not necessarily
> require an implicit renewal.  I prefer the idea of "redeem via update" and
> then "renew if necessary".  That's two commands, but it's two commands that
> are doing very different things.

I think "renew if necessary" approach is more flexible than "redeem via
update". I covers situations when rgp restore involves renewals and situation
when it does not. Approach "redeem via update" does not offer such flexibility
it assumes that renewal will never be a part of rgp restore.

The wording for <renew> command in rgp draft document could be modified to
indicate that the absence of period element in <renew> part or value ZERO
should indicate that renewal should not be a part of rgp restore. Another
option would be to force server to ignore the value of <period> element and
assume certain value.


>
>
> If people are already doing RGP as an extended renewal, what are they doing
> about the renewal part of the command?

I am aware of one implementation that just ignores the value of <period>
element and assumes ZERO if rgp extension is present.


>
>
> -Scott-

Janusz Sienkiewicz



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1HxOdF020472 for <[e-mail]>; Mon, 1 Dec 2003 18:59:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1HxOxL020471 for ietf-provreg-outgoing; Mon, 1 Dec 2003 18:59:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1HxNdF020463 for <[e-mail]>; Mon, 1 Dec 2003 18:59:23 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1HxNha007689; Mon, 1 Dec 2003 12:59:23 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5SR8JK>; Mon, 1 Dec 2003 12:59:22 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Mon, 1 Dec 2003 12:59:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> I think that unless something is really broken with <renew> 
> approach, rgp
> syntax changes that may impact operating clients should be avoided.

But:

1. We're talking about an Internet-Draft (meaning "implement at your own
risk!"), and an individual submission that hasn't been commented on very
broadly at that.

2. I think we need to come up with something that we can all implement the
same way to maximize interoperability opportunities.

Part of what I think is broken is that redemption should not necessarily
require an implicit renewal.  I prefer the idea of "redeem via update" and
then "renew if necessary".  That's two commands, but it's two commands that
are doing very different things.

If people are already doing RGP as an extended renewal, what are they doing
about the renewal part of the command?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1HWqdF020274 for <[e-mail]>; Mon, 1 Dec 2003 18:32:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1HWpvm020273 for ietf-provreg-outgoing; Mon, 1 Dec 2003 18:32:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1HWodF020268 for <[e-mail]>; Mon, 1 Dec 2003 18:32:51 +0100 (MET)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AQrui-0001AH-00; Mon, 01 Dec 2003 12:32:48 -0500
Message-ID: <[e-mail]>
Date: Mon, 01 Dec 2003 12:32:49 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I agree that Jim might be right about redemption not really being an extension
of renewal. From the other hand rgp as an extension of <renew> command can be
used without any major problems on both server and client side. As a proof of
that already deployed rgp implementations that use <renew> command for rgp
redemption could be used. There are near future plans for additional
deployments of similiar rgp implementations.

I think that unless something is really broken with <renew> approach, rgp
syntax changes that may impact operating clients should be avoided.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> Jim and I had a long talk about his ideas before he sent them to the list.
> I encouraged him to do so since I knew others were looking at ways to
> implement RGP.
>
> While I don't personally like the idea of adding new command verbs
> (extending the protocol) for operations that seem (to me) similar to an
> existing operation, I do think that Jim might be right about redemption not
> really being an extension of renewal.  I'm thinking about the merits of
> changing the extension from the <renew> command to the <update> command.
> How would that sit with those of you who care about the RGP?
>
> -Scott-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1GFpdF019602 for <[e-mail]>; Mon, 1 Dec 2003 17:15:51 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1GFpO6019601 for ietf-provreg-outgoing; Mon, 1 Dec 2003 17:15:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1GFodF019596 for <[e-mail]>; Mon, 1 Dec 2003 17:15:50 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1GFnha004370; Mon, 1 Dec 2003 11:15:49 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5SR6SS>; Mon, 1 Dec 2003 11:15:48 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Alexander Peters'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] could a int or loc postalInfo be removed?
Date: Mon, 1 Dec 2003 11:15:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> for example a contact provides local and international postal 
> address information. how could the registrar remove the local
> information for some reasons?
> 
> i don't have a concrete use case for this but i was wondering 
> if this may be possible with draft-ietf-provreg-epp-contact-07.txt. 

You can overwrite the postal information with new data that excludes
whichever form you wish to remove, but there is no way to remove one form or
the other using the "rem" attribute.  You have the change the data using the
"chg" attribute

> is a searchable mailarchive for the provreg list available?

http://www.cafax.se/ietf-provreg/maillist/

You can google the site to search for content.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1EfOdF018801 for <[e-mail]>; Mon, 1 Dec 2003 15:41:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1EfOHW018800 for ietf-provreg-outgoing; Mon, 1 Dec 2003 15:41:24 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1EfMdF018795 for <[e-mail]>; Mon, 1 Dec 2003 15:41:23 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1EfMha001249; Mon, 1 Dec 2003 09:41:22 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5P9071>; Mon, 1 Dec 2003 09:41:21 -0500
Message-ID: <[e-mail]>
From: "Gould, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Subject: RE: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/propo sal
Date: Mon, 1 Dec 2003 09:41:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Janusz,

I agree that there could be a way in making rgp work as a Command-Response
Extension to renew or any other base command, but I don't believe it is
optimal.  Below is a typical rgp use case with rgp as a renew extension:

1. Domain is auto renewed
2. Domain is deleted putting it the redemption grace period
3. Client submits a renew with the rgp request extension with 0 as the
registration period
4. Client submits a renew with the rgp report with 0 as the registration
period
5. Domain is ok

The use case with rgp as a protocol extension:
1. Domain is auto renewed
2. Domain is deleted putting it in redemption grace period
3. Client submits a rgp request (billable operation)
4. Client submits a rgp report
5. Domain is ok

You are correct that additional attributes and elements would be added to
the protocol extension to include attributes like the domain name.  I did
not fully define the protocol extension, but really only wanted to present
it in theory. The response to the rgp request or report could be extended,
but it is not essential for rgp.  I don't believe submitting two renew
commands to satisfy the use case is as clean as submitting explicit rgp
commands.  

rgp is a perfect example of the use of a protocol extension, since it really
is not a renew or an update, but is a new set of verbs.  By combining verbs
(i.e. rgp with renew, rgp with update) it makes it more of a complex
interface for the clients and makes it a more complex implementation for the
server.  The clients will have to know not to pass specific elements for a
rgp request to work with a renew or an update.  If rgp is defined as a
protocol extension it is defined at the XML schema level.  The server side
only needs a handler per verb, so the handling of rgp is not mixed with any
other operation.  rgp is billable which matches more closely with renew, but
it doesn't extend the registration period which matches more closely with
update.  rgp is not a perfect match for either renew or update.  

The command response extensions are best suited in adding attributes to
existing verbs, but not suited for adding completely new verbs.  If this is
the pattern that will be followed, there is really no purpose for defining
the protocol extension in EPP.       

JG

James F. Gould
VeriSign Naming and Directory Services
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, November 26, 2003 5:29 PM
To: Gould, James
Cc: '[e-mail]'; Hollenbeck, Scott
Subject: Re: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I don't see any clear advantage of using Protocol Extension.

The fact that rgp is provisioned as an extension of renew command does not
mean
that renew and rgp behavior should be coupled. To avoid confusion the
registry
implementation may impose restriction on valid values for period element. It
could only accept ZERO value if <rgp:extension> element is present.

Using Protocol Extension approach instead of Command-Response Extension for
RGP
would make the extension syntax more complex. At least one element should be
added to <rgp:restore> to allow passing domain name that should be restored.

I don't agree that the response of <rgp:restore> would include no <resData>
element. The response should contain at least domain name and without
<resData>
it can not be accomplished.

Janusz Sienkiewicz

Please see comments below:

"Gould, James" wrote:

> Scott,
>
> I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following
> comments:
>
> 1. In the VNDS implementation, RGP does not have a renewal feature, so if
> RGP was a Command-Response Extension, it would be better suited for the
> domain:update command than the domain:renew command.

>
> 2. Since restore (request & report) functions more as a Protocol Command
> than a Command-Response Extension, I believe that it is better suited as a
> Protocol Extension.  The namespace and XML schema could support both the
> restore Protocol Extension and the Command-Response extension for the
> domain:info response.
>
> Based on the proposal of 2, the info response would include the same
> extension as defined in draft-hollenbeck-epp-rgp-01.txt:
>
>    S:    <extension>
>    S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    S:       rgp-1.0.xsd">
>    S:        <rgp:rgpStatus s="redemptionPeriod"/>
>    S:      </rgp:infData>
>    S:    </extension>
>
> The restore extension would be moved up to a protocol extension with some
> slight modifications:
>
>    C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>    C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>    C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>    C:     epp-1.0.xsd">
>    C:  <extension>
>    C:     <rgp:restore xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    C:       rgp-1.0.xsd">
>    C:        <rgp:request/>  OR <rgp:report>...</rgp:report>
>    C:      </rgp:renew>
>    C:    <clTRID>ABC-12345</clTRID>
>    C:  </extension>
>    C:</epp>
>
> The response would include no <resData> element.
>
>   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   S:     epp-1.0.xsd">
>   S:  <response>
>   S:    <result code="1000">
>   S:      <msg>Command completed successfully</msg>
>   S:    </result>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp>
>
> By making the rgp:request and rgp:report protocol extensions, there would
be
> no coupling of either domain:update or domain:renew behavior.
>
> If anyone else is working on rgp, please respond with your thoughts and
> comments.
>
> Thanks,
>
> JG
>
> James F. Gould
> VeriSign Naming and Directory Services
> [e-mail]


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1ChndF017711 for <[e-mail]>; Mon, 1 Dec 2003 13:43:49 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB1ChndX017710 for ietf-provreg-outgoing; Mon, 1 Dec 2003 13:43:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB1ChldF017705 for <[e-mail]>; Mon, 1 Dec 2003 13:43:47 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hB1Chhha028688 for <[e-mail]>; Mon, 1 Dec 2003 07:43:44 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5SRZ1C>; Mon, 1 Dec 2003 07:43:43 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal
Date: Mon, 1 Dec 2003 07:43:43 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jim and I had a long talk about his ideas before he sent them to the list.
I encouraged him to do so since I knew others were looking at ways to
implement RGP.

While I don't personally like the idea of adding new command verbs
(extending the protocol) for operations that seem (to me) similar to an
existing operation, I do think that Jim might be right about redemption not
really being an extension of renewal.  I'm thinking about the merits of
changing the extension from the <renew> command to the <update> command.
How would that sit with those of you who care about the RGP?

-Scott-

> -----Original Message-----
> From: Gould, James 
> Sent: Wednesday, November 26, 2003 3:46 PM
> To: '[e-mail]'; Hollenbeck, Scott
> Subject: draft-hollenbeck-epp-rgp-01.txt comments/proposal
> 
> 
> Scott,
> 
> I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the 
> following comments:
> 
> 1. In the VNDS implementation, RGP does not have a renewal 
> feature, so if RGP was a Command-Response Extension, it would 
> be better suited for the domain:update command than the 
> domain:renew command.  
> 2. Since restore (request & report) functions more as a 
> Protocol Command than a Command-Response Extension, I believe 
> that it is better suited as a Protocol Extension.  The 
> namespace and XML schema could support both the restore 
> Protocol Extension and the Command-Response extension for the 
> domain:info response.
> 
> Based on the proposal of 2, the info response would include 
> the same extension as defined in draft-hollenbeck-epp-rgp-01.txt:
> 
>    S:    <extension>
>    S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    S:       rgp-1.0.xsd">
>    S:        <rgp:rgpStatus s="redemptionPeriod"/>
>    S:      </rgp:infData>
>    S:    </extension>
>  
> The restore extension would be moved up to a protocol 
> extension with some slight modifications:
> 
>    C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>    C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>    C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>    C:     epp-1.0.xsd">
>    C:  <extension>
>    C:     <rgp:restore xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    C:       rgp-1.0.xsd">
>    C:        <rgp:request/>  OR <rgp:report>...</rgp:report>
>    C:      </rgp:renew>
>    C:    <clTRID>ABC-12345</clTRID>
>    C:  </extension>
>    C:</epp>
> 
> The response would include no <resData> element.
> 
>   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   S:     epp-1.0.xsd">
>   S:  <response>
>   S:    <result code="1000">
>   S:      <msg>Command completed successfully</msg>
>   S:    </result>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp> 
> 
> By making the rgp:request and rgp:report protocol extensions, 
> there would be no coupling of either domain:update or 
> domain:renew behavior.
> 
> If anyone else is working on rgp, please respond with your 
> thoughts and comments.
> 
> Thanks,
> 
> 
> JG
> 
> James F. Gould
> VeriSign Naming and Directory Services
> [e-mail]
> 
> 
> 
>