Hi all, Very interesting discussion specifically on the "systems" of the Registry that can be reported for maintenance. During our implementation we held a somewhat "narrow" view of systems which were the "core" parts: * EPP * Portal * RDDS (WHOIS and RDAP) * DNS
Services mentioned like reporting servers (SCP/SFTP host endpoints), customer service portal, phone systems wasn't something that I was thinking about. They are most definitely "services" of importance but not necessarily considered "core", which by my definition is the domain name provisioning and management system. I want to note as well that the "domain registry" and "DNS" aren't necessarily the same system as a TLD may not use the DNS service of the RSP or the RSP may not offer a DNS hosting for the TLD For the time being I am settled on only reporting on the "core" systems, of course it's up the RSP to decide what other "non-core" services/systems they wish to report on. On the "impact" value discussion, I think if a system is undergoing maintenance even if it's a rolling upgrade there is always a chance of "intermittent" connectivity impact or a slight impact on performance, I would think Registrars "should" have a heightened sense of aware regardless of the "impact" value because a core system is being reported as undergoing maintenance. So to me any notice of "maintenance" there should be an expectation potential interruption accompanied by a severity level if it were to occur. Other than that I think the current draft version looks good and I support its submission. Thanks Quoc > > I initially thought that a rolling deployment could be handled using the > "partial" impact value, but then I came across a use case where there is a > maintenance that doesn't impact the connectivity and subsequently the > availability. Adding the "none" impact would cover this use case. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.c > om> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <https://urldefense.com/v3/__http://verisigninc.com/__;!!N14HnBHF!qzUC > HpcxHiPKkpwHjfHu-c-M9p3lDCdnFfl1L-YTF2Q9k9n3BGj-MOIHtepxRvA1gLwVPjHU$ > > > > On 4/7/21, 10:10 AM, "Tobias Sattler" <satt...@united-domains.de> wrote: > > Hi Jim, > > I understand your point. Just a thought: From a different perspective, > wouldn't partial not automatically include "none" too? So, if you set > maintenance to partial, then something could happen or not. If you know that > nothing is going to happen, then the status partial would still be okay. From > this point of view, "none" would almost be a duplication. And we could save a > status to avoid confusion. > > Tobias > >> On 7. Apr 2021, at 14:48, Gould, James >> <jgould=40verisign....@dmarc.ietf.org> wrote: >> >> Jody, >> >> I replied to Michael previously, but the intent of the "none" impact option >> is to cover the available use case for a system that is associated with the >> maintenance and doesn't imply the inclusion of systems that are not >> associated with the maintenance. In this case, the system under maintenance >> may not have any impact to availability, but there may be logic changes that >> the client needs to be aware of that is the purpose of the maintenance >> notification. >> >> -- >> >> JG >> >> >> >> James Gould >> Fellow Engineer >> jgo...@verisign.com >> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign. >> com> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> Verisign.com >> <https://urldefense.com/v3/__http://secure-web.cisco.com/1FvjPxkKPbUp >> INlZOBRph11ZugX99sVSkMflvv4TbigMmrqAxfXjREq65nR_rU0sQTtNMU2uaHk3SMQ_S >> ukpB_TvZPSKtUXX_d4BgTVpm4Yz3DBmGui-XoNHJl4yEPGBPV32XKt4KQpB4BOxz3z77L >> aPWWv3GSYcEDneh7dzMLaYrc3ldRv6Q5lcU__YObtHaVaEzSBLLg43pQY7CmILUtf7MAw >> cU5sXI5bJ5IwUTDvZLgntqOJEzGExoMlGyrX5F/http*3A*2F*2Fverisigninc.com*2 >> F__;JSUlJQ!!N14HnBHF!qzUCHpcxHiPKkpwHjfHu-c-M9p3lDCdnFfl1L-YTF2Q9k9n3 >> BGj-MOIHtepxRvA1gMJH2u0H$ > >> >> On 4/7/21, 8:11 AM, "Jody Kolker" <jkol...@godaddy.com> wrote: >> >> >> Hi Jim and Michael, >> >> Thanks for your feedback. >> >> I tend to agree that adding "none" would require all systems of the >> registry to be listed for each maintenance. It seems that each system >> within the registry would need to be listed within the maintenance that are >> not affected by the maintenance such as the customer support phone system, >> SFTP or FTP service, marketing portals, reporting portals, customer service >> portals etc. >> >> I might be tying a little to much in here. >> >> Thoughts? >> >> Thanks, >> Jody Kolker. >> >> -----Original Message----- >> From: regext <regext-boun...@ietf.org> On Behalf Of Michael Bauland >> Sent: Wednesday, April 7, 2021 1:26 AM >> To: Gould, James <jgo...@verisign.com> >> Cc: regext@ietf.org >> Subject: Re: [regext] I-D Action: >> draft-ietf-regext-epp-registry-maintenance-12.txt >> >> Caution: This email is from an external sender. Please do not click links >> or open attachments unless you recognize the sender and know the content is >> safe. Forward suspicious emails to isitbad@. >> >> >> >> Hi Jim, >> >> On 06.04.2021 21:39, Gould, James wrote: >>> Tobias, >>> >>> >>> >>> I have one more proposed change to the draft upon further review. >>> For the <maint:impact> element, no impact to availability is not covered. >>> My recommendation is to add support for the “none” value, >> >> I do not think "none" is too useful in this context and could even cause >> confusion. Shouldn't every system that is not included in the list >> automatically be not affected? >> >> What would be the consequence of having "none" there? In my opinion >> this then requires the registry to list each system in every >> maintenance notification. Otherwise one might wonder what is the >> difference between, e.g., >> >> <maint:name>Whois</maint:name> >> <maint:host>whois.registry.example</maint:host> >> <maint:impact>none</maint:impact> >> >> and just omitting the Whois entry. >> >> I think in e-mails from the registry it can make sense to add something >> like "DNS is not affected by our maintenance" to put the reading registrar >> at ease, but in an automated notification I do not see the value. If it's >> not mentioned, it's not affected. >> >> 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://urldefense.com/v3/__https://secure-web.cisco.com/1bRq_GiwNaKd >> JfsrunT5ES1Cj_ykDCbj52Q_sMe-hwkZ6R-3vUNU8b7cjya-8AW6Kwg2KbYlGzhiLM7tX >> vVb1KyGal4yHAYNRwUBrDBb8FF6VhfB2BRajHigbK9sAwYVaYHr1mIcPIpSFrRpVaqsRX >> U6WEjl9oSx898Tf1ytMRXN4UmKJp8PDODAb1OR6ez0fFtYUNQd37LXtiDwrHj4_9Adkiw >> VvY7T9ilwqbCuxVqkSyWVjNSeAjQDLLQsBlwJs/https*3A*2F*2Fwww.ietf.org*2Fm >> ailman*2Flistinfo*2Fregext__;JSUlJSUl!!N14HnBHF!qzUCHpcxHiPKkpwHjfHu- >> c-M9p3lDCdnFfl1L-YTF2Q9k9n3BGj-MOIHtepxRvA1gBLTz_5w$ >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org >> https://urldefense.com/v3/__https://secure-web.cisco.com/1ErRCahZdIFn >> 7o9-DXFc9g3NbyEgwX7JC2KpPN8Z7wDlpof2Ox0Kfz2NDdsayjMNz6Y9U751prM5CtGL1 >> yM3WsQZKrxgyz1oLIxH3zaC3-ZnZFE8ESZvk4dB7oVXAJQzkNtuxZEuBHr1MZamD90fO6 >> akwpfi-9DwwK8DsXe6R0If_H98ewPzkJ8vbaSABeo4ETSvglE59NS6SZx3SyvmUUx-WfT >> z3VpM3HZS-Ngdq_FAebVRvW5WlMofbfaYGv1be/https*3A*2F*2Fwww.ietf.org*2Fm >> ailman*2Flistinfo*2Fregext__;JSUlJSUl!!N14HnBHF!qzUCHpcxHiPKkpwHjfHu- >> c-M9p3lDCdnFfl1L-YTF2Q9k9n3BGj-MOIHtepxRvA1gNUQlPWl$ > > _______________________________________________ regext mailing list regext@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!N14HnBHF!qzUCHpcxHiPKkpwHjfHu-c-M9p3lDCdnFfl1L-YTF2Q9k9n3BGj-MOIHtepxRvA1gD4HsUzc$ _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
