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

From: "Gould, James" <[email-masked]>
Date: Tue, 6 Apr 2021 19:39:41 +0000

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, with language such as the following:

The impact level; the values MUST either be "full", "partial", or "none". If access is completely unavailable, it is "full".  If there is degradation in availability, it is "partial".  If there is no impact to availability, it is "none".

The impactEnum would then be changed to:

     <simpleType name="impactEnum">
       <restriction base="token">
         <enumeration value="partial"/>
         <enumeration value="full"/>
         <enumeration value="none"/>
       </restriction>
     </simpleType>

Thanks,

--

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/>

From: Tobias Sattler <[email-masked]>
Date: Tuesday, April 6, 2021 at 1:10 PM
To: James Gould <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Thanks, Jim.

Please see my comments inline.

The updates are done on GitHub for your review.

Tobias

On 6. Apr 2021, at 18:58, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Tobias,

In reviewing the version of the draft in GitHub, I have the following feedback:

1.       Nit – There is an extra line in the second paragraph of section 4.1.3.1 “Info Maintenance Item” that looks like it needs to be removed.
a.  When an <info> command has been processed successfully, the EPP
b.
c.  <resData>

TS: Thanks! Fixed.

2.       Nit – It may be useful to adjust the dates in the draft to be in the future.  For example:

a.       Section 4.1.3.1 Info Maintenance Info example
                                                              i.      2020-12-30T06:00:00Z to 2021-12-30T06:00:00Z
                                                            ii.      2020-12-30T14:25:57Z to 2021-12-30T14:25:57Z
                                                          iii.      2020-10-08T22:10:00Z to 2021-10-08T22:10:00Z

b.       Section 4.1.3.2 Info Maintenance List example
                                                               i.      2020-12-30T06:00:00Z to 2021-12-30T06:00:00Z
                                                             ii.      2020-12-30T07:00:00Z to 2021-12-30T07:00:00Z
                                                           iii.      2020-09-08T22:10:00Z to 2021-09-08T22:10:00Z
                                                           iv.      2021-02-15T04:30:00Z to 2022-02-15T04:30:00Z
                                                             v.      2021-02-15T05:30:00Z to 2022-02-15T05:30:00Z
                                                           vi.      2020-09-08T22:11:00Z to 2021-09-08T22:11:00Z
                                                          vii.      2020-10-17T15:00:00Z to 2021-10-17T15:00:00Z

c.       Section 4.1.4 “EPP <poll> Command” example
                                                              i.      2020-12-30T06:00:00Z to 2021-12-30T06:00:00Z
                                                            ii.      2020-12-30T14:25:57Z to 2021-12-30T14:25:57Z
                                                          iii.      2020-10-08T22:10:00Z to 2021-10-08T22:10:00Z

TS: I’ve added another year to each timestamp.

3.       Once the draft passes WGLC, my recommendation is to change the XML namespace from urn:ietf:params:xml:ns:epp:maintenance-0.3 to urn:ietf:params:xml:ns:epp:maintenance-1.0

TS: Will keep that in mind and do the update after WGLC.

Thanks,

--

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/1D2n8EhKK3nOjGsI1A2pP--PDlMAPx7Lg-DM9WruNBTd29tGaAfF7f6DwBJ_lALnkKPJEWJz-hwxBt_2AAqmVZwzvHFL3fDxKaE1uFN1ESFVLQrylCIbNpKQzaXAHb11CWvsAJbZq4_YIC7B-aAHQbPqvsfxck_rbNxnBJNrKYcllDhPxBzD8nNp9D26HCtPq5PZDo97jI4DQCvkz6EwcQjM9Z09-APrak1y1TYJsr2c6dPEt9_auNWLKkhdcSXgk/http%3A%2F%2Fverisigninc.com%2F>

From: Tobias Sattler <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 6, 2021 at 12:29 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-12.txt

Thanks Michael and Jim.

I’ve made the adjustment on GitHub for your review.
https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt<https://secure-web.cisco.com/1qHhn9m_n0q1Aop-LvX59fsy8JV04r9d-NS_iCDZ5x8vZ_ZXeJt2CO7oDXK27hsU8Mr8S_41nsjRPFrjYDAiFveBRZ3ZkF5Nw_uo2v2SnNYXN7rkMl6JYfcd0O3CGnC0_kwrvWmTkqx6cPzh6l4_7icShqr4GYvhj7rqXvmaccBz2M5PDzZm--ziQiAUKihBIGtyIJkMdPi33ApZBYhIAqUSMx1C5YFQyxN622sUqjir77szIdHyTOIdQrMiPLsb6/https%3A%2F%2Fgithub.com%2Fseitsu%2Fregistry-epp-maintenance%2Fblob%2Fmaster%2Fdraft-ietf-regext-epp-registry-maintenance.txt>

Tobias

On 6. Apr 2021, at 14:21, Gould, James <jgould=[email-masked]<mailto:jgould=[email-masked]>> wrote:

If the intent is to support a list of description elements, then my recommendation is to update the schema, as previously noted with maxOccurs="unbounded", and update the description of the element with something similar to:

Zero or more OPTIONAL free-form descriptions of the maintenance...

--

JG

James Gould
Fellow Engineer
[email-masked]<mailto:[email-masked]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

Verisign.com<http://verisign.com/> <http://verisigninc.com/<http://secure-web.cisco.com/1q-u3_Fr2541unEM2O8NdJxYqFh-WP_FpSuHAnIlW4rGpTehTzsSVd_qpsRWqNaHhOnOwxg6faxqvKocTCBIu91LoZVv_J_kw1nC2UsaEML6NrC3QKXRfXGhRa2bpkKVVR6rxisAdEeCN5_wuXAs58cVUua-wGK4zjIMlgZpfeSCqA4JTmRfBdUhBQcg1jYXcsyK5sZXzT7K2BFB0_DUbc1h4YT-Vd5yi8GGR6IdM3hqyirKu_MwDUGUBUVo6E2R_/http%3A%2F%2Fverisigninc.com%2F>>

On 4/6/21, 5:50 AM, "regext on behalf of Michael Bauland" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

   Hi Jody,

   thanks for your answer.

   I agree with your comments, but there is still an issue with the
   descriptions in multiple languages. You said:

<< JWK
The maint:description element is unbounded.  If descriptions in different languages are needed, they can be sent on the same poll message.

   I think this is not the case according to the schema:

        <complexType name="maintDataType">
          <sequence>
            <element name="id" type="maint:idType"/>
            <element name="type" type="maint:typeType" minOccurs="0"/>
            <element name="pollType" type="maint:pollType" minOccurs="0"/>
            <element name="systems" type="maint:systemsType"/>
            <element name="environment" type="maint:envType"/>
            <element name="start" type="dateTime"/>
            <element name="end" type="dateTime"/>
            <element name="reason" type="maint:reasonEnum"/>
            <element name="detail" type="anyURI" minOccurs="0"/>
            <element name="description" type="maint:descriptionType"
             minOccurs="0"/>
            <element name="tlds" type="maint:tldsType" minOccurs="0"/>
            <element name="intervention" type="maint:interventionType"
             minOccurs="0"/>
            <element name="crDate" type="dateTime"/>
            <element name="upDate" type="dateTime" minOccurs="0"/>
          </sequence>
        </complexType>

   There is no maxOccurs element and the default is maxOccurs="1".
   My suggestion is to update the schema and allow unbounded occurrences to
   support multiple languages in one notification.

   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]<mailto:[email-masked]>
        Software Development        E-mail: [email-masked]<mailto:[email-masked]>

                                    Register Court:
                                    Amtsgericht Dortmund, HRB 13728

                                    Chief Executive Officers:
                                    Dietmar Knipp, Elmar Knipp

   _______________________________________________
   regext mailing list
   [email-masked]<mailto:[email-masked]>
   https://secure-web.cisco.com/15k4MSsRmzO-vHkCwzCFTssa7wd6ube1TSVU9nPxSO0AvM5DSo-tqeF_QM-BOhHtQTCvYiN1Vu5caHJVGataZX93gVy4Td_WfFf5P69l-KZVWCTZeL63FrxS3j4izOnCXW-UkcYj9gZZxKHR8n7ECnYRg01JPweXW12kVqhxtE6z8By7KHJXHqSb4Grl_-1b_WDL_WAddOkE8Unkkb_601jo0hsbojViwdeVAB0mLY90OJBdLKj7DeW6hTQwwrxZQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1t1Mm63QHoesElH_rgYhj1VOuhl1Xf95jZvS69-Uk37ZmdOd9w8sGWQxFGyidDuYiCL7NMilUg0Lix0_w-jdqVE_IEs7as_sOq-1NHpuflRtUZ14f_atH7PHYcaBMiQZEZnIl3ZlRQr2Tf5-m1X-8eUev1XdM-OZv_XbT5DFxyekAQJ74dC54uzxf-JhQJ_ckG-74T26sMTnrmZfARA8d1YUIj_EFmeQ4t-r_iMMJS0gwiNitLTDxBAGPN1eor-Yb/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

---

From: Michael Bauland <[email-masked]>
Date: Wed, 7 Apr 2021 08:26:07 +0200

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

     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:

---

From: Jody Kolker <[email-masked]>
Date: Wed, 7 Apr 2021 12:11:05 +0000

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,

> 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.,

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

                                 Register Court:

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Wed, 7 Apr 2021 12:48:09 +0000

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://verisigninc.com/>

On 4/7/21, 8:11 AM, "Jody Kolker" <[email-masked]> wrote:

    Hi Jim and Michael,

    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

    Hi Jim,

    Best regards,

    Michael

                                     Register Court:

    _______________________________________________
    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

---

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

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,
>