Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

From: "Gould, James" <[email-masked]>
Date: Wed, 7 Apr 2021 14:22:50 +0000

Tobias,

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
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 4/7/21, 10:10 AM, "Tobias Sattler" <[email-masked]> 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=[email-masked]> 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
    > [email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
    > 
    > 703-948-3271
    > 12061 Bluemont Way
    > Reston, VA 20190
    > 
    > Verisign.com <http://secure-web.cisco.com/1FvjPxkKPbUpINlZOBRph11ZugX99sVSkMflvv4TbigMmrqAxfXjREq65nR_rU0sQTtNMU2uaHk3SMQ_SukpB_TvZPSKtUXX_d4BgTVpm4Yz3DBmGui-XoNHJl4yEPGBPV32XKt4KQpB4BOxz3z77LaPWWv3GSYcEDneh7dzMLaYrc3ldRv6Q5lcU__YObtHaVaEzSBLLg43pQY7CmILUtf7MAwcU5sXI5bJ5IwUTDvZLgntqOJEzGExoMlGyrX5F/http%3A%2F%2Fverisigninc.com%2F>
    > 
    > On 4/7/21, 8:11 AM, "Jody Kolker" <[email-masked]> 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 <[email-masked]> On Behalf Of Michael Bauland
    >    Sent: Wednesday, April 7, 2021 1:26 AM
    >    To: Gould, James <[email-masked]>
    >    Cc: [email-masked]
    >    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:    [email-masked]
    >         Software Development        E-mail: [email-masked]
    > 
    >                                     Register Court:
    >                                     Amtsgericht Dortmund, HRB 13728
    > 
    >                                     Chief Executive Officers:
    >                                     Dietmar Knipp, Elmar Knipp
    > 
    >    _______________________________________________
    >    regext mailing list
    >    [email-masked]
    >    https://secure-web.cisco.com/1bRq_GiwNaKdJfsrunT5ES1Cj_ykDCbj52Q_sMe-hwkZ6R-3vUNU8b7cjya-8AW6Kwg2KbYlGzhiLM7tXvVb1KyGal4yHAYNRwUBrDBb8FF6VhfB2BRajHigbK9sAwYVaYHr1mIcPIpSFrRpVaqsRXU6WEjl9oSx898Tf1ytMRXN4UmKJp8PDODAb1OR6ez0fFtYUNQd37LXtiDwrHj4_9AdkiwVvY7T9ilwqbCuxVqkSyWVjNSeAjQDLLQsBlwJs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
    > 
    > _______________________________________________
    > regext mailing list
    > [email-masked]
    > https://secure-web.cisco.com/1ErRCahZdIFn7o9-DXFc9g3NbyEgwX7JC2KpPN8Z7wDlpof2Ox0Kfz2NDdsayjMNz6Y9U751prM5CtGL1yM3WsQZKrxgyz1oLIxH3zaC3-ZnZFE8ESZvk4dB7oVXAJQzkNtuxZEuBHr1MZamD90fO6akwpfi-9DwwK8DsXe6R0If_H98ewPzkJ8vbaSABeo4ETSvglE59NS6SZx3SyvmUUx-WfTz3VpM3HZS-Ngdq_FAebVRvW5WlMofbfaYGv1be/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Tobias Sattler <[email-masked]>
Date: Wed, 7 Apr 2021 16:46:23 +0200

Jim,

Got it. I guess, I mixed it up with potential(ly). How should we address “none” to avoid that all systems will be listed that aren’t even affected?

Tobias

> On 7. Apr 2021, at 16:22, Gould, James <[email-masked]> wrote:
> 
> Tobias,
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 8 Apr 2021 08:04:28 +0000

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

> [email-masked] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]
> 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$ 
> >
>
>> [email-masked] 
>> <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$ >
>>
>>   Subject: Re: [regext] I-D Action: 
>> draft-ietf-regext-epp-registry-maintenance-12.txt
>>
>>> I have one more proposed change to the draft upon further review.  
>>> For the <maint:impact> element, no impact to availability is not covered.
>>   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.,
>>
>> 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$
>>
>> 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
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!N14HnBHF!qzUCHpcxHiPKkpwHjfHu-c-M9p3lDCdnFfl1L-YTF2Q9k9n3BGj-MOIHtepxRvA1gD4HsUzc$

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 8 Apr 2021 10:57:39 +0200

> On Apr 8, 2021, at 10:04 AM, [email-masked] wrote:
> 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.

Yes, that’s correct.  Each TLD will have one “domain registry” which may be internal to its administrative controller or may be outsourced to an RSP; and they will have one or more, but typically several, DNS operators, which may or may not include a DNS service of the RSP.  So, as Quoc notes, these are not coupled functions in any way.

                                -Bill

---

From: Michael Bauland <[email-masked]>
Date: Thu, 8 Apr 2021 11:46:02 +0200

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

                                 Register Court:

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 8 Apr 2021 17:20:26 +0200

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 <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Michael Bauland <[email-masked]>
Date: Thu, 8 Apr 2021 17:31:13 +0200

Hi Tobias,

On 08.04.2021 17:20, Tobias Sattler wrote:
> 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>
> 

there is a typo in the description:
"If access is not effect, it is  "none".
should be:
If access is not affected, it is "none".

> @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?

I still think unbounded is necessary, if you want to support multiple
languages, e.g.,

<maint:type>Routine Maintenance</maint:type>
<maint:type lang="de">normale Wartung</maint:type>

I think whenever someone uses a non-English version for the type, they
would almost always also want to put the English version, too.

Best regards,

Michael

                                 Register Court:

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 8 Apr 2021 19:14:05 +0200

Thanks, Michael.

Fixed the typo, and added another missing lang attribute.

I am fine with setting it to unbounded. Any other thoughts on the mailing list?

Tobias

> On 8. Apr 2021, at 17:31, Michael Bauland <[email-masked]> wrote:
> 
> Hi Tobias,
>