Re: [regext] Registry Maintenance Notifications for the EPP
Hi Patrick, Here are our responses inline. Let me know if you have any questions. Thanks, Jody. -Original Message- From: regext 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 - 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 relat
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-maintenance/ > > 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. * 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 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 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
[regext] Registry Maintenance Notifications for the EPP
Dear IETF REGEXT members, The ICANN Generic Names Supporting Organization (GNSO) Contracted Party House (CPH) formed the TechOps subcommittee in September 2017 to address technical and operational issues facing ICANN accredited registries and registrars. 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. https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/ If you have any thoughts, suggestions, ideas, etc., please do not hesitate. Thank you, Tobias Tobias Sattler Chief Information Officer -- united-domains AG Gautinger Str. 10 82319 Starnberg Germany Twitter: @tobiassattler Phone: +49 8151 36867-0 Fax: +49 8151 36867-77 https://www.united-domains.de satt...@united-domains.de Registration No.: HRB 127020, Munich Board of Directors: Alexander Helm, Markus Eggensperger Supervisory Board: Dr. Christian Böing (Chairman) signature.asc Description: Message signed with OpenPGP ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
