Hi Patrick,
Here are our responses inline. Let me know if you have any questions. Thanks, Jody. -----Original Message----- From: regext <regext-boun...@ietf.org> On Behalf Of Patrick Mevzek Sent: Thursday, April 5, 2018 2:27 AM To: regext@ietf.org Subject: Re: [regext] Registry Maintenance Notifications for the EPP 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. > https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenanc > e/ > > 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. Regards, * 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. -- JWK - Updated in Draft from "Domain Name Registry" to "Registry" * 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) -- JWK - Draft has been updated. * 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. -- JWK - We have not seen any other models for this type of data. If anyone else is, please reply to the list. * 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. -- JWK - We have updated to use a server unique ID. * 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? -- JWK - These are only examples, the list will be server dependent. Although we would like to have the systems names as standardized as possible. * 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. -- JWK - The draft has been updated to use RFC 5731 definitions. * 2.3 maint:impact This seems under-defined to me. -- JWK - That was the intent, it is server definable. These are two example values. * 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) -- JWK - <maint:tlds> has been changed from MUST to SHOULD. * 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. -- JWK -- <maint:connection> has been changed from MUST to SHOULD. Our intent was to only state if the maintenances would affect connections. Any additional information could be covered in the <maint:description> element. I doubt that we will be able to imagine all issues that could affect connections; so I think it would be best to keep it generic for now. * 2.3 maint:implementation Same problem (even larger) than for maint:connection. -- JWK -- <maint:implementation> has been changed from MUST to SHOULD. Our intent was to only state if the maintenances would be a code breaking change. Any additional information could be covered in the <maint:description> element. * 2.3 maint:status Please further detail active vs inactive. -- JWK - Active/Inactive is described at the beginning of this section (2.3) * 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. -- JWK - The messages are available through the poll messages. If the registrar has missed the poll messages, the registrar can use the <maint:list> command to obtain the list of maintenances and then use the <maint:info> command to retrieve the information regarding maintenances. I would like to hear from other registrys or registrars as to their opinion if this is overkill. 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. -- JWK - I would expect that this command would only show future maintenances that are either active or inactive and would only show maintenances that are within the next 6 months - to a year. Thoughts? I don't see any reason to list prior maintenances or recurring maintenances that are more than 6 - 12 months in the future. In the end, this should be server policy. * 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? -- JWK - The maintenance could be an emergency maintenance for which the start and end is not known. We can update the doc to explain. - The status list here is active and deleted, where the text speaks only about active and inactive, so there is a discrepancy. -- JWK - Updated - 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? -- JWK - Updated * 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. -- JWK This could be referenced in the description. Should an additional parameter be added? - 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? -- JWK This could also be referenced in the description. Should an additional parameter be added? - 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? -- JWK This could also be referenced in the description. Degrade only maintenances could also be listed as "partial". - 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. -- JWK How would you suggest that these be referenced? - 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). -- JWK - I would expect OT&E maintenances would be sent to both the production and OT&E environments. -- Patrick Mevzek p...@dotandco.com _______________________________________________ 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
