Hi everyone, Thank you for your feedback.
We have updated the draft on GitHub: https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt <https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt> (1) <maint:impact> can be “none” too (2) Set <maint:host> to OPTIONAL (3) Added more description and an example for <maint:type> Looking forward for more feedback. @Michael: The example you sent looks correct for me. Can you please review the new example of <maint:type>, as it is intended I don’t know if unbounded is necessary. Thoughts? Thanks, Tobias > On 8. Apr 2021, at 11:46, Michael Bauland <michael.baul...@knipp.de> wrote: > > Hi all, > > first, Jim's argument convinced me and I take back my comment that I > think impact "none" is not useful. In the described use cases where a > registry just wants to inform about some implementation changes, this > might not necessarily always include a downtime. > > In response to Quoc's e-mail, in our implementation we took a similar > approach to GoDaddy's. We also did not include support services like > phone or e-mail support. In addition to the ones mentioned by Quoc, we > also added the "Zone Propagation" as a service that could be in > maintenance. In that case DNS resolution is still working (as are other > customer facing systems), but updates to the TLD zone are not propagated > to the name servers. > > In this context, I have three further comments to the draft, which I > forgot to mention last time. > > 1. The <maint:host> element should maybe also be made optional. There > can be services (like zone propagation or DNSSEC) which are not tied to > a specific host but could still be in maintenance. > > In this context, I assume that if I want to inform about maintenance of > DNS and this affects more than one name server, we add two system > entries, like: > <maint:system> > <maint:name>DNS</maint:name> > <maint:host>ns1.registry.example</maint:host> > <maint:impact>partial</maint:impact> > </maint:system> > <maint:system> > <maint:name>DNS</maint:name> > <maint:host>ns2.registry.example</maint:host> > <maint:impact>partial</maint:impact> > </maint:system> > > This is the intended way, is that right? > > 2. The <maint:type> should probably (similar to <maint:description>) be > unbounded as this also allows the specification of an language > attribute. If a registry adds a description in two (or more) languages > it most likely also wants to have the type in those languages. > > 3. You should probably also add <maint:type> to your examples (other > optional fields are also mentioned). This could also help to avoid a too > creative divergence in different implementations. > > Best regards, > > Michael > > > -- > ____________________________________________________________________ > | | > | knipp | Knipp Medien und Kommunikation GmbH > ------- Technologiepark > Martin-Schmeisser-Weg 9 > 44227 Dortmund > Germany > > Dipl.-Informatiker Fon: +49 231 9703-0 > Fax: +49 231 9703-200 > Dr. Michael Bauland SIP: michael.baul...@knipp.de > Software Development E-mail: michael.baul...@knipp.de > > Register Court: > Amtsgericht Dortmund, HRB 13728 > > Chief Executive Officers: > Dietmar Knipp, Elmar Knipp
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
