[regext] Comments on "draft-sattler-epp-registry-maintenance-02"

[Patrick Mevzek]

Hello Tobias,

I am currently adding support for this draft in my open source EPP client 
library and doing so generates the following comments, that I hope would prove 
useful:

* Abstract
I am not sure you really need to specify "Domain Name" in "Domain Name 
Registry". As written in RFC5730, the protocol is generic and can be used for 
other things than domain names, and could then profit from your extension in 
the same way as domain name registries

Same remark in the introduction and further below in the document.

* 1.1 
You should probably there have an explanation on the XML namespace you are 
using, in the same way that is done in the fee document for example (the fact 
that the namespace change if the draft version change), and also about the 
prefix you use (with the custom warning that it should not be hardcoded on 
clients)

* 2.1
Why referencing RFC3492 and not RFC5891 that updates it?

* 2.3
Generic remark: have you looked at other models that exist for this type of 
data?
As it is clearly not anything specific to our area and I am pretty sure they 
should already
exist some definitions related to that or close to it. I lack specific 
references right now but I suspect similar works exist at the IETF or the W3C 
or the ISO.
It may be worthwhile to have a look, even if it is to redefine things 
completely at the end of the day.
There are also various things around SLAs at ICANN that are related to this.

* 2.3
maint:id
Why is maint:id mandatory to be an UUID? There are various other identification 
tokens in EPP, such as clTRID and svTRID and they are left to be formatted the 
way the registry likes it. Why imposing UUID here?
Even more since you define in the XML schema the id as just a token type.

* 2.3
maint:name
I would advise using "recognized" terminology, such as RDDS instead of whois.
In the schema it is left open as a token, shouldn't there be a list of values?

* 2.3
maint:host
I am not a fan of having this element be a name or an IP.
This makes validation complicated, and also does not cater precisely to all 
needs I believe.

* 2.3
maint:impact
This seems under-defined to me.

* 2.3
maint:tlds
This is overly specific to domain name registries (see my initial remark) and I 
think there is no need to be so specific.
Instead, why not use the already defined namespaces (like EPP domain-1.0) to 
define the type of objects impacted by the maintenance, and then a value being 
the object themselves (like a TLD for object type = domain-1.0)

* 2.3
maint:connection
It seems vague or underspecified.
You say "if a client needs to do something that is connection related, such as 
a reconnect."
For me "such as" denotes an example, one case among others. But the element is 
a boolean so that does not live very much spaces for multiple cases.
For example, there could be a maintenance where the registrar has to reconnect 
BUT also is forced to change its password. Currently there would be no way to 
code for that.

* 2.3
maint:implementation
Same problem (even larger) than for maint:connection.

* 2.3
maint:status
Please further detail active vs inactive.

* 3.1.3
I am not sure to understand why you needed to create a new action. Why could'nt 
the notification messages just be available through the poll mechanism, with 
the other messages?
Can you describe the rationale?
If the argument is that registrars may not poll their messages, hence the need 
for a specific
case for these messages, then in the same way it could be argued that 
registrars will not take time to implement this specific extension, whereas 
just having another poll notification result does not mean implementing anythin 
on the protocol level, just the parsing of a new message type.

I believe that maint:list is underspecified. What are "all maintenance 
notifications"? Only future ones or really all of them, even from the past? 
Does that include ongoing ones?
Only active ones?
For registries having fixed maintenance slots (like sunday 6AM, each sunday), 
how should they handle that? They would obviously need to limit the amount of 
future maintenances to return.

* 4.1 Schema

- I see both start and end are optional. What is the meaning of a maintenance 
without a start? Without an end? Without a start and without an end?

- The status list here is active and deleted, where the text speaks only about 
active and inactive, so there is a discrepancy.

- You changed maint:remark to maint:detail in the text, but not in the schema
Also since you say there are URLs, why not choose something more specific than 
token for its type?

* Other generic comments/ideas

- Some maintenances may be a follow-up, a fix, or a reply to another past 
maintenance.
It may be useful hence to add a parameter (optional) in a maintenance data that 
would
reference a previous maintenance id.

- Also registries may provide specific point of contact during the maintenance,
specially for important cases. It should be useful to be able to put this 

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



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 

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