Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Gould, James]

Patrick,



Thanks for your thoughts of the 4 options presented for handling the returning 
of a poll message that the client does not support based on the client login 
services.  To note, this is not specific to draft-ietf-regext-change-poll, so 
it is an important topic for defining a generic solution for all poll messages. 
 I re-reviewing the options, I believe option 4 is the only option that is 
protocol compliant and that would not result in a poison poll message.  I 
provide a response to your feedback embedded below prefixed with "JG-".  For 
option 4, I propose to define a simple  ABNF formatted message that 
indicates what poll message service namespaces (object or extension) are not 
supported are therefore not returned by the server.  A poll message may include 
multiple EPP services (object and extensions).  It would be up to the server to 
filter the services not supported by the client and add the service namespace 
to the encoded  element.  The  element is defined as 
mixed with a sequence of any elements that skip processing, which means that we 
can mix XML with text without causing negative side effects on the client-side. 
 Any attributes for a non-supported service (object or extension) can be 
retrieved from the server out-of-band using the message identifier ( "id" 
attribute).I propose supporting a list of  XML elements 
appended to the end of the  text.  Each  element 
contains the XML namespace of the EPP service (object or extension) that is not 
supported by the client.  The ABNF for the  element is:



msg   = msg-text *LWSP *(not-supported-service *LWSP)

msg-text  = *VCHAR

not-supported-service = “” 1*VCHAR “”



The following is an example of a Change Poll Message where the client does not 
support the Change Poll Extension:







  



  

   Command completed successfully; ack to dequeue





  2013-10-22T14:25:57.0Z

  Registry initiated update of domain.

urn:ietf:params:xml:ns:changePoll-1.0



  





  

domain.example

EXAMPLE1-REP







jd1234

sh8013

sh8013

ClientX

ClientY

2012-04-03T22:00:00.0Z

ClientZ

2013-10-22T14:25:57.0Z

2014-04-03T22:00:00.0Z

  





  ABC-12345

  54321-XYZ



  





The following is an example of a Change Poll Message where the client does not 
support the Domain Mapping and the Change Poll Extension to show the many case:







  



  

 Command completed successfully; ack to dequeue





  2013-10-22T14:25:57.0Z

  Registry initiated update of domain.

 urn:ietf:params:xml:ns:domain-1.0

 

 urn:ietf:params:xml:ns:changePoll-1.0

 

   





  ABC-12345

  54321-XYZ



  





What do you think of this proposal?



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 

On 4/5/18, 3:12 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Wed, Jan 31, 2018, at 18:11, Gould, James wrote:

> Yes, there is no great solution to the problem of including extensions

> (object or command-response) in poll messages to clients that don’t

> support the extension as indicated by their login services.  So, to

> clarifying for the list, there are 4 options that include:



I favor option 1 (return the extension independent of the login services) 
from your list.



And now for my detailed rationale about that:



- the list of extensions at greeting/login time do not convey enough 
semantics, like for example which extension is mandatory for login (especially 
complicated when the registry offers at the same time multiple versions of the 
same  extension). The registry can only react by refusing the login, hopefully 
with a good enough error message, but nothing is guaranteed here.

So for now, this kind of information is lost in documentation (James, 
another useful data item to have in the Registry Mapping in fact).



- the registrar has to specifically acknowledge a message, after having 
seen it; so the responsability is on him.



- poll results, aka notification messages are by definition not real time: 
a registrar could as well download them all, store them locally in some way and 
parse them later, including later when he has a software capable of 
understanding them



- some registries let registrars choose, out-of-band, which kind of 
notification messages they wish to receive; hence when this feature exists it 
should again be the burden of the registrar to make sure it receives the 
notification it needs to receive.



- giving the registrar all messages, irrespective of its choices at login 
time, is also the case giving less work to the server.

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Patrick Mevzek]

On Wed, Jan 31, 2018, at 18:11, Gould, James wrote:
> Yes, there is no great solution to the problem of including extensions 
> (object or command-response) in poll messages to clients that don’t 
> support the extension as indicated by their login services.  So, to 
> clarifying for the list, there are 4 options that include:

I favor option 1 (return the extension independent of the login services) from 
your list.

And now for my detailed rationale about that:

- the list of extensions at greeting/login time do not convey enough semantics, 
like for example which extension is mandatory for login (especially complicated 
when the registry offers at the same time multiple versions of the same  
extension). The registry can only react by refusing the login, hopefully with a 
good enough error message, but nothing is guaranteed here.
So for now, this kind of information is lost in documentation (James, another 
useful data item to have in the Registry Mapping in fact).

- the registrar has to specifically acknowledge a message, after having seen 
it; so the responsability is on him.

- poll results, aka notification messages are by definition not real time: a 
registrar could as well download them all, store them locally in some way and 
parse them later, including later when he has a software capable of 
understanding them

- some registries let registrars choose, out-of-band, which kind of 
notification messages they wish to receive; hence when this feature exists it 
should again be the burden of the registrar to make sure it receives the 
notification it needs to receive.

- giving the registrar all messages, irrespective of its choices at login time, 
is also the case giving less work to the server.

>   2.  Return an Error (e.g., 2307 “Unimplemented object service”) to 
> Poll Request for Unsupported Poll Message

This would be hugely detrimental for registrars because this would block all of 
their queue for one message about something maybe that they explicitely do not 
care about and have not implemented the relevant extension.

>   3.  Return a Successful EPP Poll Response with an Extension Element 
> that Indicates Lack of Client Support

If this means the original message is lost, I think it is a show stopper.
And if the registrar was not inclined to code a parser for some registry 
notification that forces the registry to respond with this case, why should we 
imagine that he would have coded the parser for this new extension also?

>   4.  Return a Successful EPP Poll Response with an Encoded  
> Element Indicating Lack of Client Support

Same remark. Also  is defined as a human-readable element content, hence
I do not think it is good to overload it with other data in it formatted
in some way. XML is a format, if you need to carry some formatted things it 
should be using XML elements/attributes, and not be serialized in some way in a 
string element.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Gould, James]

Martin,

Yes, there is no great solution to the problem of including extensions (object 
or command-response) in poll messages to clients that don’t support the 
extension as indicated by their login services.  So, to clarifying for the 
list, there are 4 options that include:


  1.  Return the Extension Independent of the Login Services
 *   This option is only included to complete the decision tree.  RFC 5730 
doesn’t explicitly state that a server must not return an extension that is not 
included in the login services, but I believe that this is implied by inclusion 
the server and login services.
 *   I don’t recommend this option due to meeting the intent of the RFC.
  2.  Return an Error (e.g., 2307 “Unimplemented object service”) to Poll 
Request for Unsupported Poll Message
 *   Technically the server did not receive an object service that is not 
supported from the client but has a message that it created that is not 
supported by the client.
 *   Returning an error will stop the processing of the poll queue that 
would mean that the unsupported poll message would become a poison message in 
the queue.
 *   If the client is not interested in implementing the poll message, then 
they should have the capability of gracefully ignoring it by acking it.
 *   I don’t recommend returning an error, since I believe the client 
should have the option of ignoring poll messages that they decide not to 
support.
  3.  Return a Successful EPP Poll Response with an Extension Element that 
Indicates Lack of Client Support
 *   There is no way to include information in an extension that the client 
doesn’t support the extension without violating the original problem.
 *   I don’t recommend this option due to meeting the intent of the RFC, 
where there is no difference between this option and option #1.
  4.  Return a Successful EPP Poll Response with an Encoded  Element 
Indicating Lack of Client Support
 *   The main question for this option is the format of the encoded 
 element.  Since this is human readable and only meant to inform the 
client that the message is not supported by the client, I don’t believe we need 
to make this overly complex by attempting to encode in XML, JSON or some other 
structured language in the  element.  I believe using the simple 
ABNF format will meet the need.

I believe the best option is option 4.

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>
From: Martin Casanova 
Date: Wednesday, January 31, 2018 at 10:47 AM
To: James Gould , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-07.txt

James,

Thanks for your fast answer. I think your suggestion is a good way to solve 
this issue.

We discussed it in our team and have 2 thoughts about it:

1. The  field is described as human-readable message that is not 
validated and even can have a language attribute. Therefore we agree that this 
field should be used as "last resort" only due to the lack of other options.
The only other way I could think of was to define an optional:

Element. This way it is up to the change poll RFC, how to transmit the message, 
that the client should enable the extension in the Login command if it wants to 
receive all the information the change poll extension has to offer.
Drawback here: We are already sending this tiny part of the extension even when 
not specified in Login.


2. Normally we respond with the following error code if a client sends a 
request containing an extension element that was not enabled at Login:


Unimplemented object service


This return code could also be returned instead of the

Command completed successfully; ack to dequeue


That way more already implemented clients would remark the freshly implemented 
change poll extension since the result code is more likely to be evaluated than 
the  field.
On the other hand also more clients would potentially fail for this reason and 
stop working until this case is handled. Since this is not client initiated 
maybe it is not appropriate to return 2307 in this case ?


Martin Casanova




--

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone +41 44 268 15 55, direct +41 44 268 16 25

martin.casan...@switch.ch<mailto:martin.casan...@switch.ch>, 
www.switch.ch<http://www.switch.ch>



Working for a better digital world

On 30.01.2018 19:07, Gould, James wrote:
Martin,

Yes, that is an excellent point that we need to consider for any poll message 
extension.  What should the server do with a poll message that the client does 
not support based on the login services?  We need to consider two poll 
extension cases:

1.   Object Extension – This is the case for an extension like the Registry 
Maintenance Notifications for E

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Martin Casanova]

.0Z
> S:    ClientY
> S:    2000-06-13T22:00:00.0Z
> S:    2002-09-08T22:00:00.0Z
> S:  
> S:    
> S:    
> S:  ABC-12345
> S:  54321-XYZ
> S:    
> S:  
> S:
>
>  
>
>  
>
> Thoughts?
>
>  
>
> —
>
>  
>
> JG
>
>
> cid:image001.png@01D255E2.EB933A30
>
> *James Gould
> *Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext  on behalf of Martin Casanova
> 
> *Date: *Tuesday, January 30, 2018 at 9:14 AM
> *To: *"regext@ietf.org" 
> *Subject: *[EXTERNAL] Re: [regext] I-D Action:
> draft-ietf-regext-change-poll-07.txt
>
>  
>
> Hi
>
> Thank you for the new version 07 of the draft-ietf-regext-change-poll.
>
> May I ask a question about it?
>
> "RFC5730 states: The  element MAY contain an OPTIONAL
>  element that contains one or more  elements
> that identify object extensions to be used during the session."
>
> The extension should be specified in the EPP Login command otherwise
> it will not be available for the client during that EPP session. I
> suppose this is also the case for this change-poll extension..
>
> What happens if a client does not specify the change-poll extension in
> the Login command but starts consuming all its poll messages? Are the
> change-poll messages delivered just without the
>
>   element or are these poll messages retained
> until a change-poll enabled EPP-Session polls them?
>
> Thank you.
>
> Martin Casanova
>
>  
>
>  
>
>  
>
>  
>
> On 29.01.2018 20:40, Gould, James wrote:
>
> Hi,
>
>  
>
> I published the revised draft-ietf-regext-change-poll based on the
> feedback received during the WGLC.  Please provide any additional
> feedback on the list. 
>
>  
>
> Thanks,
>
>  
>
> —
>
> JG
>
>  
>
>  
>
>  
>
> James Gould
>
> Distinguished Engineer
>
> jgo...@verisign.com<mailto:jgo...@verisign.com>
>
>  
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
>  
>
> Verisign.com <http://verisigninc.com/><http://verisigninc.com/>
>
> On 1/29/18, 2:38 PM, "regext on behalf of
> internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
>  
> internet-dra...@ietf.org><mailto:regext-bounces@ietf.orgonbehalfofinternet-dra...@ietf.org>wrote:
>
>  
>
>    
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>     This draft is a work item of the Registration Protocols
> Extensions WG of the IETF.
>
>    
>
> Title   : Change Poll Extension for the
> Extensible Provisioning Protocol (EPP)
>
>     Authors : James Gould
>
>   Kal Feher
>
>        Filename    : draft-ietf-regext-change-poll-07.txt
>
>        Pages   : 26
>
>        Date    : 2018-01-29
>
>    
>
> Abstract:
>
>    This document describes an Extensible Provisioning Protocol
> (EPP)
>
>    extension for notifying clients of operations on client
> sponsored
>
>    objects that were not initiated by the client through EPP. 
> These
>
>    operations may include contractual or policy requirements
> including
>
>    but not limited to regular batch processes, customer
> support actions,
>
>    Uniform Domain-Name Dispute-Resolution Policy (UDRP) or
> Uniform Rapid
>
>    Suspension (URS) actions, court directed actions, and bulk
> updates
>
>    based on customer requests.  Since the client is not directly
>
>    involved or knowledgable of these operations, the extension
> is used
>
>    along with an EPP object mapping to provide the resulting
> state of
>
>    the post-operation object, and optionally a pre-operation
> object,
>
>    with the operation meta-data of what, when, who, and why.
>
>    
>
> 
>
> The IETF datatracker status page for this draft is:
>
>     https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/
>
>    
>
> There are also htmlized versions available at:
>
>     https://tools.ietf.org/html/draft-ietf-regext-chan

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Gould, James]

Martin,

Yes, that is an excellent point that we need to consider for any poll message 
extension.  What should the server do with a poll message that the client does 
not support based on the login services?  We need to consider two poll 
extension cases:


  1.  Object Extension – This is the case for an extension like the Registry 
Maintenance Notifications for EPP 
(https://tools.ietf.org/html/draft-sattler-epp-registry-maintenance) that is 
being discussed on rr_ry_techops list.
  2.  Command Response Extension – This is the case for the Change Poll 
extension, where it extends the info response of EPP objects (domain, host, 
contact, …).

To be protocol compliant the server must not return an extension (Object or 
Command Response) that is not supported by the client based on the login 
services.  I really only see one solution that would apply to both types of 
extensions, which would be to return a successful EPP Poll Response with an 
appropriate message indicating the poll message namespaces that are not 
supported by the client logic services.  The client could add support for the 
poll messsage or choose to ack it to move to the next message in the queue.  
The only element in the EPP response that we can use is the   
element.  You could leverage the  as well, but I don’t believe 
that would help here.  I don’t advocate encoding something in the  
element, which is the point I made about including JSON in the  element 
for the Registry Maintenance Notifications for EPP.  In this case, I don’t 
believe there is much of a choice to stay protocol compliant and to ensure that 
the poll queue can continue to be processed.  How about encoding the  
element as below when the server needs to return a poll message to a client 
that doesn’t support one or more extensions based on their login services?

msg = extension-namespaces “ not supported in login services”
extension-namespaces = extension-namespace / extension-namespace “,” 
extension-namespaces
extension-namespace = XML namespace of EPP extension


An example of a Change Poll  element of a supported object (e.g., domain) 
is “urn:ietf:params:xml:ns:changePoll-1.0 not supported in login services”.  An 
example of a Change Poll  element of an unsupported object (e.g., .NAME 
Email Forwarding object) is 
“http://www.nic.name/epp/emailFwd-1.0,urn:ietf:params:xml:ns:changePoll-1.0 not 
supported in login services”.  The full EPP response for the first Change Poll 
 element is included below:





S:

S:

S:  

S:

S:  Command completed successfully; ack to dequeue

S:

S:

S:  2000-06-08T22:00:00.0Z

S:  urn:ietf:params:xml:ns:changePoll-1.0 not supported in login 
services

S:

S:

S:  

S:example.com

S:pending

S:ClientX

S:2000-06-08T22:00:00.0Z

S:ClientY

S:2000-06-13T22:00:00.0Z

S:2002-09-08T22:00:00.0Z

S:  

S:

S:

S:  ABC-12345

S:  54321-XYZ

S:

S:  

S:


Thoughts?

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>
From: regext  on behalf of Martin Casanova 

Date: Tuesday, January 30, 2018 at 9:14 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-07.txt


Hi

Thank you for the new version 07 of the draft-ietf-regext-change-poll.

May I ask a question about it?

"RFC5730 states: The  element MAY contain an OPTIONAL  
element that contains one or more  elements that identify object 
extensions to be used during the session."

The extension should be specified in the EPP Login command otherwise it will 
not be available for the client during that EPP session. I suppose this is also 
the case for this change-poll extension..

What happens if a client does not specify the change-poll extension in the 
Login command but starts consuming all its poll messages? Are the change-poll 
messages delivered just without the

  element or are these poll messages retained until a 
change-poll enabled EPP-Session polls them?

Thank you.

Martin Casanova







On 29.01.2018 20:40, Gould, James wrote:

Hi,



I published the revised draft-ietf-regext-change-poll based on the feedback 
received during the WGLC.  Please provide any additional feedback on the list.



Thanks,



—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com<mailto:jgo...@verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/><http://verisigninc.com/>

On 1/29/18, 2:38 PM, "regext on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<mailto:regext-bounces@ietf.orgonbehalfofinternet-dra...@ietf.org>
 wrote:





A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a 

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Martin Casanova]

Hi

Thank you for the new version 07 of the draft-ietf-regext-change-poll.

May I ask a question about it?

"RFC5730 states: The  element MAY contain an OPTIONAL
 element that contains one or more  elements that
identify object extensions to be used during the session."

The extension should be specified in the EPP Login command otherwise it
will not be available for the client during that EPP session. I suppose
this is also the case for this change-poll extension..

What happens if a client does not specify the change-poll extension in
the Login command but starts consuming all its poll messages? Are the
change-poll messages delivered just without the

  element or are these poll messages retained
until a change-poll enabled EPP-Session polls them?

Thank you.

Martin Casanova




 
On 29.01.2018 20:40, Gould, James wrote:
> Hi,
>
> I published the revised draft-ietf-regext-change-poll based on the feedback 
> received during the WGLC.  Please provide any additional feedback on the 
> list.  
>
> Thanks,
>   
> —
>  
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com  
> On 1/29/18, 2:38 PM, "regext on behalf of internet-dra...@ietf.org" 
>  wrote:
>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Registration Protocols Extensions WG of 
> the IETF.
> 
> Title   : Change Poll Extension for the Extensible 
> Provisioning Protocol (EPP)
> Authors : James Gould
>   Kal Feher
>   Filename: draft-ietf-regext-change-poll-07.txt
>   Pages   : 26
>   Date: 2018-01-29
> 
> Abstract:
>This document describes an Extensible Provisioning Protocol (EPP)
>extension for notifying clients of operations on client sponsored
>objects that were not initiated by the client through EPP.  These
>operations may include contractual or policy requirements including
>but not limited to regular batch processes, customer support actions,
>Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
>Suspension (URS) actions, court directed actions, and bulk updates
>based on customer requests.  Since the client is not directly
>involved or knowledgable of these operations, the extension is used
>along with an EPP object mapping to provide the resulting state of
>the post-operation object, and optionally a pre-operation object,
>with the operation meta-data of what, when, who, and why.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-regext-change-poll-07
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-07
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[Gould, James]

Hi,

I published the revised draft-ietf-regext-change-poll based on the feedback 
received during the WGLC.  Please provide any additional feedback on the list.  

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  
On 1/29/18, 2:38 PM, "regext on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.

Title   : Change Poll Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : James Gould
  Kal Feher
Filename: draft-ietf-regext-change-poll-07.txt
Pages   : 26
Date: 2018-01-29

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension for notifying clients of operations on client sponsored
   objects that were not initiated by the client through EPP.  These
   operations may include contractual or policy requirements including
   but not limited to regular batch processes, customer support actions,
   Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
   Suspension (URS) actions, court directed actions, and bulk updates
   based on customer requests.  Since the client is not directly
   involved or knowledgable of these operations, the extension is used
   along with an EPP object mapping to provide the resulting state of
   the post-operation object, and optionally a pre-operation object,
   with the operation meta-data of what, when, who, and why.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-07
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-change-poll-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
Authors : James Gould
  Kal Feher
Filename: draft-ietf-regext-change-poll-07.txt
Pages   : 26
Date: 2018-01-29

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension for notifying clients of operations on client sponsored
   objects that were not initiated by the client through EPP.  These
   operations may include contractual or policy requirements including
   but not limited to regular batch processes, customer support actions,
   Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
   Suspension (URS) actions, court directed actions, and bulk updates
   based on customer requests.  Since the client is not directly
   involved or knowledgable of these operations, the extension is used
   along with an EPP object mapping to provide the resulting state of
   the post-operation object, and optionally a pre-operation object,
   with the operation meta-data of what, when, who, and why.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-07
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext