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

[Patrick Mevzek <[e-mail]>]

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 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
  [e-mail]