Re: [regext] Registry Maintenance Notifications for the EPP

Patrick Mevzek <> Thu, 05 April 2018 07:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20D00126DC2 for <>; Thu, 5 Apr 2018 00:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Muv1v2U5; dkim=pass (2048-bit key) header.b=i7rxORWK
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CdVLf6HQjIWU for <>; Thu, 5 Apr 2018 00:26:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7F2C126D74 for <>; Thu, 5 Apr 2018 00:26:58 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4C3C621AAC for <>; Thu, 5 Apr 2018 03:26:58 -0400 (EDT)
Received: from web3 ([]) by compute3.internal (MEProxy); Thu, 05 Apr 2018 03:26:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BzOhth1wtlC+zVKdwO46/gAS9Z9iU irFiCK7sAoVYv8=; b=Muv1v2U5F2nzktHG6HoC7G/ZEfv+nCc6YnewVBfNgjV3U 2/27yGlwMF7HaW15yxspqIlS8Pl0X+foSzcAKjArG0EDSyG0OshyenrzdwieL9Du TuvjhJ2+MAQzm7QYkhX/CUxNzh/beuZVCHnLjw28p3sr0AkwZ1CkYyGRzVRzoVJL 3YA6LCQHlyNf77+78Re+LKqry5xKgSPyr/MLZ6af5SWxyjilQQXUc36K00wAqfhD kzh/xM2BRwPlaPjdUKll6PdiV1MsSz8Ah6I5/vwnXQdpQ2FlXLp0IBg6DfmtXATt qUr29vRklFSWm7vJd8cHC7zSvw3EIO5i55BpTET6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BzOhth 1wtlC+zVKdwO46/gAS9Z9iUirFiCK7sAoVYv8=; b=i7rxORWKhC/b/TXeXlR03o KMwvfxeR/XmfVfgPO2js+14gxPVijdWjZCG4wnm5XVdPyIg/0gtSaSTiUUmu0TVT Gpt/Cw+X5rERf6fHzOa5E47Qg+EcvId8ypCA4bhjypjJ4MsnvWn1vK4JkSffwESC gUmDGEaR7LohZT/j4zwHSwM9lKcDshHAth2pljQCdx2BhnVYytVCPLMwrdDIhB1f Fyr/JOZWa2gRePO18PVeUN2V8v30Yf0e37xIDj0BG2krkDSkC8/3ZzR51d23qgSI 5blX5s78IHxZIUi74iDP/z7wfmCnZrLkXMwdRTYWocWCK33EHhybKQZTIP1/cNBQ ==
X-ME-Sender: <xms:ws_FWmDqHgyU3kZFoW8-N-EKSzo9o3sQld6IXYTOsOklMFjA_AGBMXeZX84>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 26BF79E13B; Thu, 5 Apr 2018 03:26:58 -0400 (EDT)
Message-Id: <>
From: Patrick Mevzek <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-61ab7380
Date: Thu, 05 Apr 2018 09:26:58 +0200
References: <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [regext] Registry Maintenance Notifications for the EPP
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Apr 2018 07:27:01 -0000

Hello Tobias,

On Mon, Mar 26, 2018, at 08:41, Tobias Sattler wrote:
> This group created an IETF draft on Registry Maintenance Notification 
> for the EPP, to make it easier for registrars to keep track and to 
> prepare their systems while a registry maintenance is or will happen. 
> Due to the heavy work that the IETF REGEXT working group is lifting, the 
> idea came up to refine this draft to a certain level before asking for 
> support and/or adoption. We think that we reached this point.

As a side note, and as already stated privately, I do not think this is the best way to operate. The community of EPP/RDAP engineers is not big and not extensible(!), so fragmenting it by having multiple circles where documents are discussed will only lower the participation and final quality.

Also, doing it like that may look like as if the IETF is just rubber stamping things that have been cooked outside of it. Which is certainly the wrong image to convey.
> If you have any thoughts, suggestions, ideas, etc., please do not hesitate.

I already implemented version -02 of your draft in my EPP library and will try to update it in the near future to implement your latest version.
If I find any new items worthwhile to discuss, I will then send it.

I already sent all the following comments about a previous version of the draft, and based on a cursory look I do not think they were all adressed already.
So I am giving them here again, in hope they are useful and trigger some discussion.


* 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.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
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
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
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
This seems under-defined to me.

* 2.3
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
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
Same problem (even larger) than for maint:connection.

* 2.3
Please further detail active vs inactive.

* 3.1.3
I am not sure to understand why you needed to create a new action. Why couldn't 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 somewhere in the maintenance details maybe?

- How would your extension code for the fact that some maintenances for example would make EPP read-only, the registry would accept all queries but only act on the ones not modifying
objects? Maybe a new impact value like 'read-only'?
How to code a maintenance that "only" degrades performances? 

- I think you should also have a look at usual past cases of maintenances. For example: global change of passwords because of a breach, registry ramp-up such as a cut just before entering GA for example, EBERO switches maybe? etc.

- I would like a discussion on OT&E systems too: do they have notifications? If so, where?
(because registrars may not poll on OT&E systems so it may make sense to publish OT&E maintenances even on the production EPP server).

  Patrick Mevzek