Subject: [ietf-provreg] could a int or loc postalInfo be removed?

From: "Alexander Peters" <[email-masked]>
Date: Sun, 30 Nov 2003 16:13:38 +0100

Dear all,

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. 

is a searchable mailarchive for the provreg list available?

Thanks,
Alexander Peters

From: "Alexander Peters" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-provreg] could a int or loc postalInfo be removed?
Date: Sun, 30 Nov 2003 16:13:38 +0100
Importance: Normal
Sender: [email-masked]

Dear all,

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. 

is a searchable mailarchive for the provreg list available?

Thanks,
Alexander Peters

Date: Wed, 26 Nov 2003 17:28:58 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Gould, James" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Subject: Re: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal
Sender: [email-masked]

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
> [email-masked]

From: "Gould, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Subject: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal
Date: Wed, 26 Nov 2003 15:46:17 -0500
Sender: [email-masked]

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
[email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Antony Perkov'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] RE: Grace periods
Date: Sun, 9 Nov 2003 18:53:34 -0500 
Sender: [email-masked]

Antony,

After thinking about this a bit more I think you might be on to something.
It may make more sense to modify this document to make it a general grace
period document since the RGP is itself an ICANN-described grace period.  It
would mean some re-work to make the RGP one of several grace periods, but it
might make more sense than having two documents describing different grace
periods.

I'm at the IETF meeting now if anyone wants to talk about this live.  If
not, I'll think about it some more and see what I can do next week.

-Scott-

> -----Original Message-----
> From: Antony Perkov [mailto:[email-masked]] 
> Sent: Wednesday, November 05, 2003 8:15 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: RE: [ietf-provreg] RE: Grace periods
> 
> 
> Scott,
> 
> I agree, it wouldn't be the right thing to do to have non RGP 
> stuff in the
> existing document without changing it's name.  I guess I was 
> really asking
> is there an intent to make it a more general "grace periods" 
> document.  As
> you say this may or may not be necessary.
> 
> For clarity, perhaps I should explain my understanding of the 
> "new" grace
> periods suggested in the Deletes Task Force report.  It seems 
> to all boils
> down to: a registrar being able to get a credit / refund for 
> any domain
> creation, renewal, or transfer as long as they delete the 
> domain within 5
> days of the creation, renewal, or transfer (which then leads to the
> redemption grace period except during the add grace period).
> 
> To me the "pending" status values don't really seem to describe this
> situation adequately to a registrar as they don't distinguish between
> "action not finished" and "action refundable".
> 
> I guess the most important thing is that all registries 
> implementing the
> Deletes Task Force's suggested grace periods expose this information
> consistently.  How are other people doing this at the moment?
> 
> Antony. 
> 
> > -----Original Message-----
> > From: Hollenbeck, Scott [mailto:[email-masked]] 
> > Sent: 04 November 2003 12:31
> > To: 'Antony Perkov'; [email-masked]'
> > Subject: [ietf-provreg] RE: Grace periods
> > 
> > Antony,
> > 
> > No, I have no intention of updating the RGP document to 
> > include descriptions
> > of status values that have nothing to do with the RGP.  There 
> > may, however,
> > be some value in defining a new extension that describes some of the
> > policy-based grace periods that you described below.
> > 
> > But -- there's already a status value to describe what I 
> > think you mean when
> > you say "Transfer grace period".  See the description of the
> > "pendingTransfer" status in the domain draft.  For that 
> > matter, it may make
> > sense to use the other "pending" status values to describe 
> > the add and renew
> > grace periods, as in "this action has been requested but 
> > hasn't yet been
> > fully completed".  Would that make sense?
> > 
> > -Scott-
> > 
> > > -----Original Message-----
> > > From: Antony Perkov [mailto:[email-masked]] 
> > > Sent: Tuesday, November 04, 2003 6:04 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Grace periods
> > > 
> > > 
> > > Are there any plans to update the 
> > > draft-hollenbeck-epp-rgp-01.txt document
> > > to include status values for grace periods other than 
> "redemption"?
> > > 
> > > I'm interested in status values for the other grace periods 
> > > described at
> > > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report
> > .html which
> > are:
> > 
> > * Add grace period
> > * Auto renew grace period
> > * Renew grace period
> > * Transfer grace period
> > 
> > It seems to me that it would be useful to be able to provide 
> > registrars this
> > information via the <info> command.
> > 
> 

From: Antony Perkov <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] RE: Grace periods
Date: Wed, 5 Nov 2003 13:15:06 -0000 
Sender: [email-masked]

Scott,

I agree, it wouldn't be the right thing to do to have non RGP stuff in the
existing document without changing it's name.  I guess I was really asking
is there an intent to make it a more general "grace periods" document.  As
you say this may or may not be necessary.

For clarity, perhaps I should explain my understanding of the "new" grace
periods suggested in the Deletes Task Force report.  It seems to all boils
down to: a registrar being able to get a credit / refund for any domain
creation, renewal, or transfer as long as they delete the domain within 5
days of the creation, renewal, or transfer (which then leads to the
redemption grace period except during the add grace period).

To me the "pending" status values don't really seem to describe this
situation adequately to a registrar as they don't distinguish between
"action not finished" and "action refundable".

I guess the most important thing is that all registries implementing the
Deletes Task Force's suggested grace periods expose this information
consistently.  How are other people doing this at the moment?

Antony. 

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]] 
> Sent: 04 November 2003 12:31
> To: 'Antony Perkov'; [email-masked]'
> Subject: [ietf-provreg] RE: Grace periods
> 
> Antony,
> 
> No, I have no intention of updating the RGP document to 
> include descriptions
> of status values that have nothing to do with the RGP.  There 
> may, however,
> be some value in defining a new extension that describes some of the
> policy-based grace periods that you described below.
> 
> But -- there's already a status value to describe what I 
> think you mean when
> you say "Transfer grace period".  See the description of the
> "pendingTransfer" status in the domain draft.  For that 
> matter, it may make
> sense to use the other "pending" status values to describe 
> the add and renew
> grace periods, as in "this action has been requested but 
> hasn't yet been
> fully completed".  Would that make sense?
> 
> -Scott-
> 
> > -----Original Message-----
> > From: Antony Perkov [mailto:[email-masked]] 
> > Sent: Tuesday, November 04, 2003 6:04 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Grace periods
> > 
> > 
> > Are there any plans to update the 
> > draft-hollenbeck-epp-rgp-01.txt document
> > to include status values for grace periods other than "redemption"?
> > 
> > I'm interested in status values for the other grace periods 
> > described at
> > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report
> .html which
> are:
> 
> * Add grace period
> * Auto renew grace period
> * Renew grace period
> * Transfer grace period
> 
> It seems to me that it would be useful to be able to provide 
> registrars this
> information via the <info> command.
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Antony Perkov'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] RE: Grace periods
Date: Wed, 5 Nov 2003 08:35:58 -0500 
Sender: [email-masked]

> I agree, it wouldn't be the right thing to do to have non RGP 
> stuff in the
> existing document without changing it's name.  I guess I was 
> really asking
> is there an intent to make it a more general "grace periods" 
> document.  As
> you say this may or may not be necessary.

No, I wasn't planning on making the document a "grace periods" document.
The ones that you described outside of RGP require nothing more than status
values to indicate application of a registry policy.  RGP has real
processing requirements in addition to the status values.

One should be able to do RGP without the grace periods (and vice-versa), so
I don't think they should be combined in the same namespace (or document).

> For clarity, perhaps I should explain my understanding of the 
> "new" grace
> periods suggested in the Deletes Task Force report.  It seems 
> to all boils
> down to: a registrar being able to get a credit / refund for 
> any domain
> creation, renewal, or transfer as long as they delete the 
> domain within 5
> days of the creation, renewal, or transfer (which then leads to the
> redemption grace period except during the add grace period).
> 
> To me the "pending" status values don't really seem to describe this
> situation adequately to a registrar as they don't distinguish between
> "action not finished" and "action refundable".

Perhaps...

> I guess the most important thing is that all registries 
> implementing the
> Deletes Task Force's suggested grace periods expose this information
> consistently.  How are other people doing this at the moment?

I'm not aware of anyone that has tried expose the grace period information.
To be honest, I'm leery when it comes to producing new protocol structures
every time some ICANN task force produces a policy recommendation.  If,
however, others feel that these grace periods are sufficiently well
established in a few different TLD registries maybe it makes sense to
document them as status values.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Antony Perkov'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] RE: Grace periods
Date: Tue, 4 Nov 2003 07:30:35 -0500 
Sender: [email-masked]

Antony,

No, I have no intention of updating the RGP document to include descriptions
of status values that have nothing to do with the RGP.  There may, however,
be some value in defining a new extension that describes some of the
policy-based grace periods that you described below.

But -- there's already a status value to describe what I think you mean when
you say "Transfer grace period".  See the description of the
"pendingTransfer" status in the domain draft.  For that matter, it may make
sense to use the other "pending" status values to describe the add and renew
grace periods, as in "this action has been requested but hasn't yet been
fully completed".  Would that make sense?

-Scott-

> -----Original Message-----
> From: Antony Perkov [mailto:[email-masked]] 
> Sent: Tuesday, November 04, 2003 6:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Grace periods
> 
> 
> Are there any plans to update the 
> draft-hollenbeck-epp-rgp-01.txt document
> to include status values for grace periods other than "redemption"?
> 
> I'm interested in status values for the other grace periods 
> described at
> http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report
.html which
are:

* Add grace period
* Auto renew grace period
* Renew grace period
* Transfer grace period

It seems to me that it would be useful to be able to provide registrars this
information via the <info> command.