Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

From: "Gould, James" <[email-masked]>
Date: Thu, 7 Jan 2021 13:39:13 +0000

Antoin,

I was surprised to see draft-ietf-regext-epp-registry-maintenance move to WGLC based on the work that has been progressing on the mailing list, so at this point I can’t support publication of the document.  The document editors have addressed my prior feedback.  Upon a fresh review, below is my feedback:

  1.  Upon the draft passing WGLC, the version should be updated to “maintenance-1.0”.  This change should not happen now.
  2.  Section 3.3 “Maintenance Elements”
     *   I’m taking the action item to see how the existing registrar notices map to the elements defined in this section.  The registrar notices are free-form currently, but there is some consistency of structure that needs to be evaluated against the formal structure defined in draft-ietf-regext-epp-registry-maintenance.  I anticipate changes to the elements in Section 3.3 “Maintenance Elements” coming out of this mapping exercise.
  3.  Section 4.1.3 “EPP <info> Command”
     *   Nit – Change “either <maint:id>” to “either the <maint:id> child element” and change “or <maint:list> child element” to “or the <maint:list> child element”.
  4.  Section 7 “Security Considerations”
     *   It would be worthwhile to consider the security associated with what maintenance information to return back to the client.  A registry access point may return maintenance information for many top-level domains (or registry zones), where the client has authorization to access a subset of top-level domains.  My recommendation is to define the considerations that take into account authorization of the client.  For example:

                                                               i.      “A server MUST only provide maintenance information for clients that are authorized.  If a client queries for a maintenance identifier, per section 4.1.3.1 “Info Maintenance Item”, that it’s not authorized to access, the server MUST return an EPP error result code of 2201 [RFC5730].  The list of top-level domains or registry zones returned in the “Info Maintenance Item” response SHOULD be filtered based on the top-level domains or registry zones the client is authorized.  Authorization of poll messages is done at the time of poll message insertion and not at the time of poll message consumption.”

                                                             ii.      The poll message use case is a corner case, but I believe it’s important to cover it.

  1.  Section 9 “References”
     *   I believe that draft-ietf-regext-unhandled-namespaces would need to move into the Normative References since it’s referenced in a normative sentence.

--

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 1/4/21, 9:40 AM, "regext on behalf of Antoin Verschuren" <[email-masked] on behalf of [email-masked]> wrote:

    The following working group document is believed to be ready for submission to the IESG for publication as a standards track document:

    https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F

    This WG last call will end at close of business, Monday, 18 Januari 2021.

    Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list.

    The document shepherd for this document is James Galvin.

    Regards,

    Antoin and Jim

    _______________________________________________

    regext mailing list

    [email-masked]

    https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Jan 2021 14:40:35 +0000

I completed the action item to see how existing registrar notices map to the elements defined in this section.  There was a sidebar with the draft editors that I want to ensure gets on the record.  I want to thank the draft editors with being so responsive.  Most of the identified gaps have been addressed in draft-ietf-regext-epp-registry-maintenance-10.  Below is the list of gaps and the status of each gap:

  1.  The name of the maintenance is missing
     *   This change was incorporated into draft-ietf-regext-epp-registry-maintenance-10.
     *   The <maint:id> element included an optional “msg” attribute that had the purpose of representing the human-readable name of the maintenance; although it was referred to as human-readable description.  My recommendation was to change the attribute from “msg” to “name” and to revise the description to reflect the purpose by changing “description” to “name”.
  2.  The type of the maintenance is missing
     *   This change was incorporated into draft-ietf-regext-epp-registry-maintenance-10.
     *   There are maintenance types included in some of the registry agreements that should be included in the notice.  The types are inconsistent, so my recommendation was to add an optional token element for the type.
  3.  Need for a formatted HTML description, since notices currently include formatted HTML content.
     *   We did not come to agreement on this item, so this remains an open gap.
     *   The <maint:description> element is of type “string” and can support plain or HTML text.  The HTML text would use XML escaping, but that is not an issue for the producer or consumer of the notification when using an XML Transformer and XML Parser.  My recommendation was to add a “type” attribute to the <maint:description> element with the enumerated values of “plain” and “html”, with a default value of “plain”.  The use of MIME came up, but I believe that may be too broad to address the gap.    I believe that the description should support either plain text or formatted HTML text.  The use of the link in the <maint:detail> element should not be a requirement to provide a formatted description for the maintenance.  I view the <maint:detail> element as useful when linking to binary content, since the text description (plain or formatted) should be supported by the <maint:description> element directly.
  4.  The impact element values of “full” and “partial” are a little unclear.
     *   No action required unless clarification needs to be made explicit in the draft.
     *   The deployments are typically handled via either bringing down the VIP, which would match “full”, or handled via a rolling deployment, which may match “partial”.  The reply from the editors was “If the system is completely offline, then it is “full”. If it is a rolling update, then it is “partial”.”  I’m fine based on the clarification, but I’m unsure whether this needs to be made explicit in the draft for clarification down the line.
  5.  How to signal the maintenance of an entire system versus the maintenance of an individual or set of TLDs on the system
     *   We did not come to agreement on this item, so this remains an open issue that requires feedback from the WG.
     *   The maintenance object includes the <maint:impact> element with “full” or “partial”, where based on #4 above “full” means that the system is completely offline, and there is the list of <maint:tld> elements signaling which TLDs are part of the maintenance.  If there is a registry system that supports 10 TLDs and only “.example” is being maintained and will be offline.  This means that the VIP is up but a TLD on the system will be unavailable.  The assumption is that the <maint:impact> element would be set to “full” and there would be an “example” <maint:tld> element.  If the system takes a maintenance and the VIP is down, then one option is to set the <maint:impact> element to “full” and include all of the TLDs in the list of <maint:tld> element.  One issue is that the TLDs should only include the TLDs that the client is authorized to access, so the client would not know whether it’s all of the TLDs supported by the system.  My recommendation to signal that the system is down is to set the <maint:impact> to “full” and to have no <maint:tlds> element, which means all TLDs.  If the absence of a <maint:tlds> element signals all TLDs or that the maintenance is at the system-level, then we should revise the description to be explicit about this.  Should there be a new element, such as an empty <maint:system> element as a choice with the <maint:tlds> element to explicitly signal a system-level maintenance versus a TLD-level maintenance?  The side effect of not being explicit is that implementers will take different, inconsistent ways of signaling a system-level maintenance.  Adding a <maint:system> element is most explicit, so that would be my preference.
  6.  Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to maintenance) notices and maintenance end notices.
     *   This change was incorporated into draft-ietf-regext-epp-registry-maintenance-10.
     *   There currently exists courtesy notices that provide reminders for a maintenance and doesn’t reflect a change in the maintenance.  There is also an end maintenance notice that marks that end of the maintenance and doesn’t reflect a change in the maintenance.  The recommendation was to include the “courtesy” and “end” types to the <maint:pollType> element enumerated list with the associated descriptions.

The gaps that are open or require additional consideration include gap #3 “Need for a formatted HTML description”, gap #4 “The impact element values of “full” and “partial” are a little unclear”, and gap #5 “How to signal the maintenance of an entire system versus the maintenance of an individual or set of TLDs on the system”.  I include my preferences embedded above.

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: James Gould <[email-masked]>
Date: Thursday, January 7, 2021 at 8:39 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

Antoin,

a.       I’m taking the action item to see how the existing registrar notices map to the elements defined in this section.  The registrar notices are free-form currently, but there is some consistency of structure that needs to be evaluated against the formal structure defined in draft-ietf-regext-epp-registry-maintenance.  I anticipate changes to the elements in Section 3.3 “Maintenance Elements” coming out of this mapping exercise.

a.       Nit – Change “either <maint:id>” to “either the <maint:id> child element” and change “or <maint:list> child element” to “or the <maint:list> child element”.

a.       It would be worthwhile to consider the security associated with what maintenance information to return back to the client.  A registry access point may return maintenance information for many top-level domains (or registry zones), where the client has authorization to access a subset of top-level domains.  My recommendation is to define the considerations that take into account authorization of the client.  For example:

5.       Section 9 “References”

a.       I believe that draft-ietf-regext-unhandled-namespaces would need to move into the Normative References since it’s referenced in a normative sentence.

--

JG

James Gould

Fellow Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    Regards,

    Antoin and Jim

    regext mailing list

    [email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 18 Jan 2021 15:59:14 +0100

James,

Just to note for the record, I was surprised by your surprise ;-), since the document authors asked us for a WGLC  in December. We waited for January 4th after version 09 was published that addressed your previous feedback. We were aware that the discussion on the mailing list took place with your previous comments.

The WGLC will end today, but seeing your new comments, we don’t think this is ready to be submitted to the IESG just yet.
A formal closure of this WGLC will follow later this week, but so far I can see no consensus yet, and work still needs to be done.

regards,

Antoin

> Op 7 jan. 2021, om 14:39 heeft Gould, James <jgould=[email-masked]> het volgende geschreven:
> 
> Antoin,
>  
> Upon the draft passing WGLC, the version should be updated to “maintenance-1.0”.  This change should not happen now. 
> Section 3.3 “Maintenance Elements”
> I’m taking the action item to see how the existing registrar notices map to the elements defined in this section.  The registrar notices are free-form currently, but there is some consistency of structure that needs to be evaluated against the formal structure defined in draft-ietf-regext-epp-registry-maintenance.  I anticipate changes to the elements in Section 3.3 “Maintenance Elements” coming out of this mapping exercise.    
> Section 4.1.3 “EPP <info> Command”
> Nit – Change “either <maint:id>” to “either the <maint:id> child element” and change “or <maint:list> child element” to “or the <maint:list> child element”.  
> Section 7 “Security Considerations”
> It would be worthwhile to consider the security associated with what maintenance information to return back to the client.  A registry access point may return maintenance information for many top-level domains (or registry zones), where the client has authorization to access a subset of top-level domains.  My recommendation is to define the considerations that take into account authorization of the client.  For example:
> Section 9 “References”
> I believe that draft-ietf-regext-unhandled-namespaces would need to move into the Normative References since it’s referenced in a normative sentence.  
>  
> -- 
>  
> JG
>  
>  
>  
> James Gould
> Fellow Engineer
> [email-masked] <mailto:[email-masked]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[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://verisigninc.com/>>
>  
> On 1/4/21, 9:40 AM, "regext on behalf of Antoin Verschuren" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
>     https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F <https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F>
>  
>     [email-masked] <mailto:[email-masked]>
>     https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/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://www.ietf.org/mailman/listinfo/regext>

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 25 Jan 2021 15:39:51 +0100

This WGLC formally ended last week.
The chairs are concerned that there are still outstanding comments to be addressed.
Also, apart from from the authors, we did not see any support from other WG participants.

We will take back this document into the working group to get this support and to address the outstanding comments. 

Regards

Jim and Antoin

> Op 18 jan. 2021, om 15:59 heeft Antoin Verschuren <[email-masked]> het volgende geschreven:
> 
> James,
> 
>> Op 7 jan. 2021, om 14:39 heeft Gould, James <jgould=[email-masked] <mailto:jgould=[email-masked]>> het volgende geschreven:
>> 
>> Antoin,
>>  
> https://www.ietf.org/mailman/listinfo/regext

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jan 2021 06:39:53 +0000

Hi Antoin and all,

I apologies for my late contribution on this subject, as a backend that has implemented (albeit an older draft) of the maintenance draft, I have the following to share on the list of actions posted by James Gould on 2021-01-15 (that would be my local date in Melbourne, Australia).

  1.  Need for a formatted HTML description, since notices currently include formatted HTML content.

Quoc: I don’t think this is needed, I see the intent to be a machine to machine notification, the presence of an optional URI (maint:detail) provides details that are more human friendly which the client server may pass onto their users as needed. I assume this comment is in relation to HTML formatted email notices sent to Registrars, if this assumption is true, I don’t think that making the maintenance object be like for like with an email notice is needed. Often HTML formatted email is a decision to format the presentation of the information so that it looks “nice” and is formatted to corporate standards. Another use case for this to not be required is that in some emails it contains attachments, there’s no way in replicating that in the maintenance object.

  1.  How to signal the maintenance of an entire system versus the maintenance of an individual or set of TLDs on the system

Quoc: I find the use of maint:impact in combination of maint:tld as reasonable. Our system supports multiple TLDs from a single end point and so we use this combination as needed. For instance if there was maintenance specific for .biz we would only report BIZ in the maint:tld list. Also what I would like to share is what is being referred to as maintenance? Things of a technical nature is pretty straight forward, e.g. software upgrade, so TLDs are hosted on a single system then when there is an upgrade to the backend then maintenance will be performed on ALL TLDs. However what if there is an UPDATE to a TLD which is not software related but more business driven. E.g. if there is a TLD registration policy update, this I don’t see as qualifying as a maintenance but today there would be an email notification to all Registrars with access to the TLD being updated. In spirit of simplicity I only would consider maintenance of a technical nature in the maintenance object.

  1.  Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to maintenance) notices and maintenance end notices.

Quoc: Noting that this is a suggestion for a "courtesy", I find this unnecessary as the consumer here is a machine. So when a maintenance object is created only single object is created and it’s expected that the client server stores the date and time reported and set their own reminders. If this was an email notification for humans to read then that’s a different matter (not to say that reminders are not needed). Of course if the WG thinks it’s good to send out service messages at a 2 week, 1 week, 2 day and 1 day before the maintenance then I’ll be OK to implement as a courtesy however I would suggest that clients that read the message implement a scaling interval that they are comfortable with.

Regards

Quoc Pham
GoDaddy Registry | Senior Product Manager
[https://email-sig.gd-resources.net/img/godaddy-registry-logo-outline.png]
+61398663710
Level 8, 10 Queens Road
Melbourne, Victoria, Australia
3004
[email-masked]<mailto:[email-masked]>

From: regext <[email-masked]> On Behalf Of Antoin Verschuren
Sent: Tuesday, January 26, 2021 1:40 AM
To: [email-masked]
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

Notice: This email is from an external sender.

Regards

Jim and Antoin

Op 18 jan. 2021, om 15:59 heeft Antoin Verschuren <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

James,

regards,

Antoin

Op 7 jan. 2021, om 14:39 heeft Gould, James <jgould=[email-masked]<mailto:jgould=[email-masked]>> het volgende geschreven:

Antoin,

  1.  Section 4.1.3 “EPP <info> Command”

  1.  Section 7 “Security Considerations”

--

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<https://urldefense.com/v3/__http:/verisign.com/__;!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQUfUC-uM$> <http://verisigninc.com/<https://urldefense.com/v3/__http:/verisigninc.com/__;!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQeTxQ5QV$>>

On 1/4/21, 9:40 AM, "regext on behalf of Antoin Verschuren" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F<https://urldefense.com/v3/__https:/secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-regext-epp-registry-maintenance*2F__;JSUlJSUl!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQbxqlD6M$>

    Regards,

    Antoin and Jim
    _______________________________________________
    regext mailing list
    [email-masked]<mailto:[email-masked]>
    https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fregext__;JSUlJSUl!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQY9PEEY0$>
_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQU3N1qRn$>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!N14HnBHF!rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQU3N1qRn$>

---

From: "Gould, James" <[email-masked]>
Date: Fri, 29 Jan 2021 21:25:18 +0000

Quoc,

I provide feedback to your points below.

--

JG

James Gould
Fellow Engineer

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

From: regext <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, January 27, 2021 at 1:40 AM
To: Antoin Verschuren <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-09

Hi Antoin and all,

JG – Since the intent of the draft is to standardize the maintenance notices, does it make sense to disallow inclusion of a formatted description in the EPP notification.  The description is not meant for machine use in both cases of plain text and formatted text, but it’s meant for visualization by users using many possible forms.  If formatted notifications are currently supported, why not support a smooth transition from e-mail notifications to EPP notifications instead of requiring the removal of the formatting or requiring the creation of an external accessible URL that is linked to within the EPP notification?  I don’t believe there is the need for attachments for the maintenance notices generated currently, so I don’t believe that will be an issue.

4.       How to signal the maintenance of an entire system versus the maintenance of an individual or set of TLDs on the system

JG – So how do you communicate the maintenance of your backend that brings down the VIP for all of your TLDs?  Would you return no TLDs or all TLDs?  A VIP being taken down is more impactful than updating a set of TLDs while the VIP is up, so it makes sense to signal the entire system is taking a maintenance.  My recommendation is to either not include the <maint:tlds> element or create an empty <maint:system> element as a choice with the <maint:tlds> element.  My preference would be to be explicit by creating the empty <maint:system> element as a choice.  If exclusion of the <maint:tlds> element is chosen on the signal, then the draft should be explicit with description of the <maint:tlds> element to cover this use case.

5.       Support for courtesy (e.g., 2 weeks, 1 week, 2 days, 1 day prior to maintenance) notices and maintenance end notices.

JG – Support for courtesy notices was added as an option in draft-ietf-regext-epp-registry-maintenance-10.  Just because the client is software doesn’t mean the server knows what is done with the notification.  Courtesy notices are used today, so my recommendation is to ensure that the maintenance EPP draft supports it.

Regards

Quoc Pham

Regards

Jim and Antoin

James,

regards,

Antoin

Antoin,

--

JG

James Gould
Fellow Engineer

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

Verisign.com<https://secure-web.cisco.com/1I5jnsSI6XcebwaI-PrGAE_4pQRgfBnPwuckxwbocnB_EWjZOFLb55L_H7r2NL_sxBhQlIiPlj8XllDlVREY348xUCpw3vzdvzA4PrfRAZpQ30wdQcebkr5IvNyBgoWaP2N9E5TEkktSvUt4LKVz2bTvA6nz5o4Qcw9fGRUkc-j2ACudv5_gbxw7OYhMSg41yMym1FC7m-8jNaFvLMlk0dhDMnBU6jLYwoz1J3q1URyu8AYWYNUj6X3miDmj7p3ziNRcCLRbNAt3q4Y-Rql7cpbA1VUNAa2wE9AmYzGFUnD8/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fverisign.com%2F__%3B%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQUfUC-uM%24> <http://verisigninc.com/<https://secure-web.cisco.com/1-GGEsUeD4YHa5VAQYbac3gKZ9v8OIOpLYXO9YFU0tJ4YNJTNPiKvbD1YPCIahLm2k7tPvJHdqmVgbLJaxYgZ_H83pLQgQOms-GGWceYMDNzCMVe0UswBo9EIyrAGEIpkhq0a2y4ZFAlKvUJ_hP-kyjicUVDdBvs1V_oNbTjp--Mj3erFe76QnX8HcQ9K-yOLUXj6cpvo37cOPTIEjpOh6NJmDbEM51d1STO2cQvyQypz1xl1M1uHbSakK-PXXmXty2PLeDbpapatUazKC5XC_bJuruS7htRyvk6mFfDs-5M/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fverisigninc.com%2F__%3B%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQeTxQ5QV%24>>

    https://secure-web.cisco.com/18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F<https://secure-web.cisco.com/1DSnB1v_TcGkv9i2t7cVz7z8FLutX6HCKGACG5az-Nb3hJyTF4_tZCmAJu1_5TnR3lwpyLvGgqb13b4GkM85y2GAzr0__xeY2zN1r-1tdeJy-rLAEJb68WQ_3VsSXaO4zySMalnPwO1i1QfuWcDfjXUyKAP6sSSSlEWePuS5sGoKZmgYRYHw1pH8xk-eIwZ37Jsuzh5zvQ5aWm6dAYyAZkwX1r5ijel4HHOJSjBdXo2QDU8YSv-q64Aof_NZbR_LiLfJ5sDsHZ9Hy9OjAuWGWBkSPdMD2kUfUr47GqjwUmLM/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fsecure-web.cisco.com%2F18eaw5Rc7eRHLW7NT557WL-OEIuRsuRZfA7LKp3BJ8CRDnwUbnkSep_2VLycXzaOvmv49tji_vZXkav_WSa0LDImf7iVSPHuVnheksrC-Z4yjC-TCdX06-Lys-gkODiVilrOZp1WOmoSapmIw9J5pD0-c_UpkQYAeekRFAzwm17KphqdWz9cW1VprZlDOloub5pH3QB11p7XdAbJQOs_f-_NiiPLxZDEVHyLx2QvUBtzvazi50NwL3TPdpF2dVgB7vFSXzLopwYOp3mnMp-e1dw%2Fhttps%2A3A%2A2F%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fdraft-ietf-regext-epp-registry-maintenance%2A2F__%3BJSUlJSUl%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQbxqlD6M%24>

    Regards,

    Antoin and Jim
    _______________________________________________
    regext mailing list
    [email-masked]<mailto:[email-masked]>
    https://secure-web.cisco.com/1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext<https://secure-web.cisco.com/15PPjLF6cOCZevgTA4I-wXKj8GlLfe96Pkucs2nSvR0EKRZGFNkabztg5yyPum-xsEvLJ279izYkCyISwDkY8i0OuY698Th_D3Q0TBbs8gLgWgGVtH38PWUOo9w9qcVmGhNtfO1LKYAmtwQKbALM22KdjnzCOyHOmzzG_q3hIrzct-JaIn2SXReA1dAm8ofv3PoDhNW3hku84dC1MMNDViNw-tux0jyx3fkgASUfsYehhrtTe4TdoLPhxGRcZTHhSnlZQ8Q-wcOHPmlKzNflcNt5acquNw5Qa5gfSOt1xMlk/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fsecure-web.cisco.com%2F1CE4ls-J9vyi17Z5wA242rs-KkkAsctHnLiGKkA_kgQavoiXTstq55sAh91oQYVV3zS33dzM8y3GY1nYLN4gSGgjfS09ccNXbUlpHFZUgbKtUIvuU45KQpfmOn-jqJA_nGG3Bfz4IRazNKf73lHiol397BADwass3Bi3_isz7AZ066VdhCChq6fGBvIuMmp-d-elI3ur-dS4rOm7bxi21gHhBvucBpJV6ajYIeoANmEpcOT0grGvxyqHJhTTHLr9bUv34eF1HxM1l-LBv3jiguZli7S0kkBSRiHe6IGjd7Hg%2Fhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fregext__%3BJSUlJSUl%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQY9PEEY0%24>
_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1zSASv-nLP9Sts6iQWfaX4kU5DaQbyqv7LzMDYq4R6IeD4qYuJ2dtQWMsSUxp9EFD5orcQN-qCQsQTE4xarasEZrka6etLsToHNQ2KzQflXKk625XeSRq0uy8sqJa4EdbbR2aL1tobTE2hnSpYqw2rklBnLHZbS_VIcmJ-LmGhvLq51gdIYMjazFcEzpyfg4g9NyB0XTDQQEO4oHon-EiqiJ7guMCck7D0tC07tY1UZ8baczTg2CbCjMCysBhGaFeEWAI0Wm-TDl3btxjH4liwSXAB0FCnMnNVrwhYLgqCPA/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext__%3B%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQU3N1qRn%24>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1zSASv-nLP9Sts6iQWfaX4kU5DaQbyqv7LzMDYq4R6IeD4qYuJ2dtQWMsSUxp9EFD5orcQN-qCQsQTE4xarasEZrka6etLsToHNQ2KzQflXKk625XeSRq0uy8sqJa4EdbbR2aL1tobTE2hnSpYqw2rklBnLHZbS_VIcmJ-LmGhvLq51gdIYMjazFcEzpyfg4g9NyB0XTDQQEO4oHon-EiqiJ7guMCck7D0tC07tY1UZ8baczTg2CbCjMCysBhGaFeEWAI0Wm-TDl3btxjH4liwSXAB0FCnMnNVrwhYLgqCPA/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext__%3B%21%21N14HnBHF%21rXciEdr0y7e4Tn3TRxCq-cIibUCvHOuqi6EnnXD8hOttUMJWl_QgzJRXuOrasCiqQU3N1qRn%24>