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
  p...@dotandco.com

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

Reply via email to