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

From: "Gould, James" <[email-masked]>
Date: Mon, 29 Jan 2018 19:40:01 +0000

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

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

Verisign.com <http://verisigninc.com/> 
On 1/29/18, 2:38 PM, "regext on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> 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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Martin Casanova <[email-masked]>
Date: Tue, 30 Jan 2018 15:13:07 +0100

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 <svcs> element MAY contain an OPTIONAL
<svcExtension> element that contains one or more <extURI> 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

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

Thank you.

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
[email-masked], www.switch.ch 
 
Working for a better digital world

---

From: "Gould, James" <[email-masked]>
Date: Tue, 30 Jan 2018 18:07:40 +0000

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 <msgQ> <msg> element.  You could leverage the <result><msg> as well, but I don’t believe that would help here.  I don’t advocate encoding something in the <msg> element, which is the point I made about including JSON in the <msg> 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 <msg> 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 <msg> 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 <msg> 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 <msg> element is included below:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>

S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">

S:  <response>

S:    <result code="1301">

S:      <msg>Command completed successfully; ack to dequeue</msg>

S:    </result>

S:    <msgQ count="5" id="12345">

S:      <qDate>2000-06-08T22:00:00.0Z</qDate>

S:      <msg>urn:ietf:params:xml:ns:changePoll-1.0 not supported in login services</msg>

S:    </msgQ>

S:    <resData>

S:      <obj:trnData

S:       xmlns:obj="urn:ietf:params:xml:ns:obj-1.0">

S:        <obj:name>example.com</obj:name>

S:        <obj:trStatus>pending</obj:trStatus>

S:        <obj:reID>ClientX</obj:reID>

S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>

S:        <obj:acID>ClientY</obj:acID>

S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>

S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>

S:      </obj:trnData>

S:    </resData>

S:    <trID>

S:      <clTRID>ABC-12345</clTRID>

S:      <svTRID>54321-XYZ</svTRID>

S:    </trID>

S:  </response>

S:</epp>

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: regext <[email-masked]> on behalf of Martin Casanova <[email-masked]>
Date: Tuesday, January 30, 2018 at 9:14 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

Hi

"RFC5730 states: The <svcs> element MAY contain an OPTIONAL <svcExtension> element that contains one or more <extURI> 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

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

Thank you.

Martin Casanova

Hi,

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]<mailto:[email-masked]>

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 [email-masked]<mailto:[email-masked]>" <[email-masked] on behalf of [email-masked]><mailto:[email-masked]@ietf.org> wrote:

            Authors         : James Gould

                              Kal Feher

           Pages           : 26

           Date            : 2018-01-29

    Abstract:

    regext mailing list

    [email-masked]<mailto:[email-masked]>

regext mailing list

[email-masked]<mailto:[email-masked]>

--

SWITCH

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>

---

From: Martin Casanova <[email-masked]>
Date: Wed, 31 Jan 2018 16:47:41 +0100

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 <msgQ><msg> 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:
<msgQ><extension><changePoll:changeData
xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0" msg = “not
supported in login services”/>
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:

<msg><result code="2307">
<msg lang="en">Unimplemented object service</msg>
</result>

This return code could also be returned instead of the
<result code="1301">
<msg>Command completed successfully; ack to dequeue</msg>
</result>

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 <msgQ><msg> 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

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 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 <msgQ> <msg>
> element.  You could leverage the <result><msg> as well, but I don’t
> believe that would help here.  I don’t advocate encoding something in
> the <msg> element, which is the point I made about including JSON in
> the <msg> 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 <msg> 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?
>
>  
>
> extension-namespace = /XML namespace of EPP extension/
>
>  
>
> An example of a Change Poll <msg> 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 <msg> 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 <msg> element is included below:
>  
>  
> *James Gould
> *Distinguished Engineer
> *From: *regext <[email-masked]> on behalf of Martin Casanova
> <[email-masked]>
> *Date: *Tuesday, January 30, 2018 at 9:14 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] I-D Action:
> draft-ietf-regext-change-poll-07.txt
>
>  
>
> Hi
>
> <svcExtension> element that contains one or more <extURI> 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..
>
>     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
>
>     On 1/29/18, 2:38 PM, "regext on behalf of
>     [email-masked]<mailto:[email-masked]>"
>     <[email-masked] on behalf of
>     [email-masked]><mailto:[email-masked]@ietf.org>wrote:
>
>      
>
>        
>

---

From: "Gould, James" <[email-masked]>
Date: Wed, 31 Jan 2018 17:11:17 +0000

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 <msgQ><msg> Element Indicating Lack of Client Support
     *   The main question for this option is the format of the encoded <msgQ><msg> 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 <msgQ><msg> element.  I believe using the simple ABNF format will meet the need.

I believe the best option is option 4.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: Martin Casanova <[email-masked]>
Date: Wednesday, January 31, 2018 at 10:47 AM
To: James Gould <[email-masked]>, "[email-masked]" <[email-masked]>
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.

1. The <msgQ><msg> 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:
<msgQ><extension><changePoll:changeData xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0" msg = “not supported in login services”/>
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:

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 <msgQ><msg> 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

S:  <response>

S:    <result code="1301">

S:    </result>

S:    </msgQ>

S:    <resData>

S:      <obj:trnData

S:      </obj:trnData>

S:    </resData>

S:    <trID>

S:    </trID>

S:  </response>

S:</epp>

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: regext <[email-masked]><mailto:[email-masked]> on behalf of Martin Casanova <[email-masked]><mailto:[email-masked]>
Date: Tuesday, January 30, 2018 at 9:14 AM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

Hi

Thank you.

Martin Casanova

Hi,

Thanks,

—

JG

James Gould

Distinguished Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

            Authors         : James Gould

                              Kal Feher

           Pages           : 26

           Date            : 2018-01-29

    Abstract:

    regext mailing list

regext mailing list

--

SWITCH