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

From: Michael Bauland <[email-masked]>
Date: Tue, 6 Apr 2021 11:49:39 +0200

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

                                 Register Court:
                                 Amtsgericht Dortmund, HRB 13728

                                 Chief Executive Officers:
                                 Dietmar Knipp, Elmar Knipp

---

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

Michael,

My feedback in embedded below.

-- 
 
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, 2:26 AM, "Michael Bauland" <[email-masked]> wrote:

    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?

JG - The impact element is associated with the impact to availability.  There may be a maintenance that includes logic changes on the backend and subsequently the <maint:intervention> <maint:implementation> element would be flagged as true, but there is no impact to the availability.  If there is intermittent unavailability during the maintenance it would be "partial" or if there continual unavailability during the maintenance it would be "full", but how is a maintenance that doesn't impact availability get communicated?  My recommendation is to add the option for the "none" impact to cover this use case.

    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>

JG - The intent of the "none" impact is not to specify what is not associated with the maintenance, but to reflect the availability impact to the system that is associated with the maintenance.  If there is an EPP maintenance, the non-applicable systems for the maintenance are not included in the maintenance notification.  

    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

                                     Register Court:

---

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

Tobias,

Yes, the intent is to indicate the availability impact for systems that are affected by the maintenance.  

-- 
 
JG

James Gould
Fellow Engineer

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

On 4/7/21, 10:46 AM, "Tobias Sattler" <[email-masked]> wrote:

    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,
    > 
    > 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
    > Verisign.com <http://secure-web.cisco.com/1wX8Zx4kt8KS1az5Kl-NvgiYpkG2n8aAsxkF53XTienT3B4VH_4oflD7xcc4Jw4FUeBeLOqVsHCFk1u3SXbwtB_g3HSmW2_3KH4nAu9o7wHoAnHxBtWXPQ72T1dN-mbtOHxxIcqyx1ItvcAijFR1ddOwUv8fhPIHJGlVYVba9OI8lfTa6nuD4571LZCHNXasboXqHcLwigt3VP6pRmW8xj40OmHgYhQPTMs2M8OeFlU-Oritd6LwO-nswOo2ZJawG/http%3A%2F%2Fverisigninc.com%2F>
    > 
    > 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
    >> 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,
    >> 
    >>   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
    >> 
    >> 
    >>   --
    >>   _______________________________________________
    >>   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
    > 
    >