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

From: "James Galvin" <[email-masked]>
Date: Fri, 02 Oct 2020 16:57:16 -0400

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

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/

This WG last call will end at close of business, Friday, 16 October 
2020.

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

---

From: Tobias Sattler <[email-masked]>
Date: Mon, 5 Oct 2020 13:23:48 +0200

+1

> On 2. Oct 2020, at 22:57, James Galvin <[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:
> 
> This WG last call will end at close of business, Friday, 16 October 2020.
> 
> 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.
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Roger D Carney <[email-masked]>
Date: Mon, 5 Oct 2020 11:56:49 +0000

+1

________________________________
From: regext <[email-masked]> on behalf of Tobias Sattler <[email-masked]>
Sent: Monday, October 5, 2020 6:23 AM
To: James Galvin <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

Notice: This email is from an external sender.

+1

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 5 Oct 2020 14:54:32 +0200

Hi all,

I have a couple of comments about this document:

1) Don't understand which maintenance notifications should be returned  
by an info command including the <maint:list/> element. I mean, only 
those about both ongoing and future events or also about past events? In 
the latter case,  could it be helpful to add optional attributes to the 
<maint:list/> element which allow clients to specifiy a preferred time 
interval?  For example, "createdAfter" and "createdBefore".

2) The document makes no assumption on which <maint:maint> child 
elements should be presented in the response to an info request 
including the <maint:list/> element. However, the example in section 
3.1.3 seems to suggest that servers should return a subset of the full 
information. Should the document define the minimum information which 
servers are required to provide and clients could expect?

Best,

Mario

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Gould, James" <[email-masked]>
Date: Tue, 6 Oct 2020 19:27:41 +0000

Hi,

I did a review of draft-ietf-regext-epp-registry-maintenance and the following is my feedback:

  1.  Section 1.1 Terminology and Definition
     *   Since the draft has moved to WGLC, this is somewhat a non-applicable point, but the latest practice for EPP extensions has been to use a pointed XML namespace (e.g., “urn:ietf:params:xml:ns:maintenance-0.X”) up until the draft moves to WGLC, when the XML namespace moves to 1.0 (e.g., “urn:ietf:params:xml:ns:maintenance-1.0”).  Using the pointed XML namespace will enable making XML schema changes without impacting existing implementations.  Backward compatibility can be broken based on WG feedback when using the non-pointed XML namespace.
  2.  Section 2.3 Maintenance Elements
     *   I would describe the Maintenance Elements in the description of the info response (section 3.1.3 EPP <info> Command) and then for the poll message, I would reference the use of the info response.  See how the poll messaging is described for the section 2.5 of the Launch Phase Mapping (https://tools.ietf.org/html/rfc8334#section-2.5).
     *   My recommendation is to only define SHOULD for elements that are not required per the XML schema, since some of the SHOULD elements in the description are for required elements in the XML schema.  The other EPP Extension RFCs default to the elements being required, but explicitly define optional elements using the OPTIONAL keyword.
     *   Should the <maint:detail> element be of type anyURI or is it free-form text?
     *   The <maint:description> is not defined as a “token” and does not include an optional “lang” element with a default value of “en” like other EPP extensions.
     *   The <maint:tlds> element is required per the XML schema with inclusion of at least one <maint:tld> element, but it’s defined as a SHOULD.
     *   The <maint:intervention> element is required per the XML schema with inclusion of both the <maint:connection> and <main:implementation> boolean elements, but it’s defined as a SHOULD.
     *   Does it make sense for <maint:start> and <maint:end> to be required per the XML schema for an inactive maintenance?
     *   When are inactive maintenances returned?

                                                              i.      I would assume that only active maintenances would be returned in the maintenance list, but when querying for a specific maintenance that has been deleted, can the inactive status be returned?

                                                            ii.      How long should deleted maintenances be kept around for?

                                                          iii.      Wouldn’t it be better to return that the deleted maintenance does not exist instead of having the concept of an active and inactive status?

                                                          iv.      The Change Poll EPP extension (https://tools.ietf.org/html/rfc8590) could be used in combination with the maintenance mapping to address the deletion use case, where the previous version of the maintenance is returned with the change poll reason that the maintenance was deleted.

     *   The <maint:id> element includes a human readable “msg” attribute, which also means that there is the need for the optional “lang” attribute with a default value of “en”.  The “msg” attribute seems to only apply to the responses and not the command, but the “idType” type is also used for the info command in the “infoType” type.  It would be better to use the “token” type for the <maint:id> element instead of the “normalizedString” type.
     *   The description of the <maint:system> element needs to be revised.  I don’t believe that the description of <maint:system> needs to say “MUST be present at least once”, since the parent <maint:systems> element already indicates that there MUST be one or more <maint:system> elements.
     *   For the <maint:environment> element, should the “type” attribute and the “name” attribute be placed in double quotes?  Should the “name” attribute be defined as a MUST when using the ‘custom’ type?
     *   The <main:impact> is an enumerated value of either ‘blackout’ or ‘partial’ in the XML schema, so the SHOULD needs to be a MUST.  I would define what is meant by “blackout” or “partial” impact.  Would the use of “full” be better than “blackout”?
     *   The <maint:host> element specifies that it contains <maint:hostname> or <maint:hostAddr>, but the XML schema does not include a choice between the two, but instead requires the <maint:hostname> element and provides the option for the <maint:hostAddr> element.  Should the <maint:hostAddr> element consist of a list of addresses (e.g., set maxOccurs=”unbounded”)?  What is the purpose of the <maint:hostAddr> element and if supported shouldn’t it be a list of host addresses?
     *   The <maint:hostName> states that it SHALL be Punycode according to [RFC5891], but that would only apply to IDN host names.  I recommend updating the description to support both non-IDN and IDN host names.
  1.  Section 3.1.3 EPP <info> Command
     *   I would first describe the info command with the info command examples, followed by describing the info response with the info response examples.  The info response is not described and are mixed in with the info command examples.
     *   I would break out the <maint:id> info command and response separate from the <maint:list> info command and response either as sub-sections or more explicitly.  An example of the use of sub-sections is defined in the multiple create forms in section 3.3 of the Launch Phase Extension (https://tools.ietf.org/html/rfc8334#section-3.3).  An example of being more explicit is the multiple info command types and responses in section 3.1.2 of the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry-04#section-3.1.2).
     *   I don’t see a description of the <maint:maint> element contained in the <maint:list> element, which is defined by the “maintItemType” in the XML schema.  The “maintItemType” type contains a subset of the elements defined by the “maintDataType” type in the XML schema.  I would recommend defining the two forms of the maintenance info commands and responses.
  2.  Section 3.1.4 EPP <poll> Command
     *   Revise the language somewhat.  For example, “The poll message applies whenever the domain name registry creates, updates, or deletes a maintenance”.
     *   I would also specify that the poll message is an info response for an individual maintenance change (create, update, or delete).
  3.  Section 4.1 Registry Maintenance EPP Mapping Schema
     *   XML schema should be able to define the infoType “list” element as <element name=”list”/> instead of including the <complexType/> sub-element.
     *   Comment for the idType can be corrected, which currently reads “Human-readable text may be expresses the maintenance”.
     *   The “host:addrType” in the XML Schema is not defined, since the host XML namespace is not imported.  My recommendation is to not create a hard dependency to the host XML schema and simply copy the “addrType”, “addrStringType”, and “ipType”   definitions into the XML schema.  The following elements were added / updated in the XML schema:

<complexType name="systemType">
  <sequence>
    <element name="name" type="token"/>
    <element name="host" type="maint:hostAttrType"/>
    <element name="impact" type="maint:impactEnum"/>
  </sequence>
</complexType>

<complexType name="addrType">
  <simpleContent>
    <extension base="maint:addrStringType">
      <attribute name="ip" type="maint:ipType"
       default="v4"/>
    </extension>
  </simpleContent>
</complexType>

<simpleType name="addrStringType">
  <restriction base="token">
    <minLength value="3"/>
    <maxLength value="45"/>
  </restriction>
</simpleType>

<simpleType name="ipType">
  <restriction base="token">
    <enumeration value="v4"/>
    <enumeration value="v6"/>
  </restriction>
</simpleType>

--

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 10/2/20, 4:57 PM, "regext on behalf of James Galvin" <[email-masked] on behalf of [email-masked]> wrote:

    https://secure-web.cisco.com/14WoNaSzKUxwiQvyFtivmhki2NRUkzRYQ7LL4wBCuxotHDT9vwzv8GABAlrm9-cxdSpu6MVB0P4OfGeG4RiXSLDcaJ7CIonnYniQxYMXAoMLNWUnyDKY2UathW7ulM87ls59KsczLcucYAzmCwvDLs73JUgk2FFvB-wMfndbW4axgl6shfqdsgW1QGMqUtCYK1LkxmCfP9jTc53yPQItk8E3InKLboiR4DShC33Yo_OtXZlSoy16RITasjytx4oZ0kxgcKdb0MJqU-K9k2_ZpKA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F

    2020.

    Regards,

    Antoin and Jim

    regext mailing list

    [email-masked]

    https://secure-web.cisco.com/1DJzCb9ui1hohfJj4BRZEe91VteUi4Ekqzw2TzFZY6cqp3Tzb5UGSpfjZZ9v2x3q4oYQPar_h2ypEbIdNN8-2OSqRu07Ldg03NzaXHCHmPcrCg1d-rjx1w7f32X0K-vxTDuIgeoeY4A12f8iolWIDv1-ifZmOaragpNhE6k5w16dHwdff_WVR6XOWH9Q6xZEbwdj86NyXaZwwFgUkOeHVIF2SVRSKZcOudsWNNPQIXX_V7_K-pLcsArFiPH62utkQtZvbKR5v5eIUIQgXusplTyyHqviyNlaL327kQ8SmME0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Oct 2020 12:54:46 +0000

One other item that is important is the chosen namespace URI.  Based on the latest EPP RFCs, IANA wants the namespace URI to be scoped with “epp”, so the namespace URI needs to be changed to “urn:ietf:params:xml:ns:epp:maintenance-1.0”.  We made a similar change to the Registry Fee Extension in draft-ietf-regext-epp-fees-13.  Adding the needed “epp” scoping will help with making XML schema changes based on WG feedback without breaking existing implementations.

--

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: regext <[email-masked]> on behalf of "Gould, James" <jgould=[email-masked]>
Date: Tuesday, October 6, 2020 at 3:27 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

Hi,

a.       Since the draft has moved to WGLC, this is somewhat a non-applicable point, but the latest practice for EPP extensions has been to use a pointed XML namespace (e.g., “urn:ietf:params:xml:ns:maintenance-0.X”) up until the draft moves to WGLC, when the XML namespace moves to 1.0 (e.g., “urn:ietf:params:xml:ns:maintenance-1.0”).  Using the pointed XML namespace will enable making XML schema changes without impacting existing implementations.  Backward compatibility can be broken based on WG feedback when using the non-pointed XML namespace.

a.       I would describe the Maintenance Elements in the description of the info response (section 3.1.3 EPP <info> Command) and then for the poll message, I would reference the use of the info response.  See how the poll messaging is described for the section 2.5 of the Launch Phase Mapping (https://tools.ietf.org/html/rfc8334#section-2.5<https://secure-web.cisco.com/1x5Z_N1Qz_yXOXdtz5_xTlKwuRfdGje1sf2Z8Sf_2S5OAB03Vfg5p8_NoxkFvFQS5CUkEgIYH-cOZ-A9B-tn7yKzxtj2crBubdeY65TgvDp82FEqevJKznQ4SrakK-EkUopn9aZOHJJpFiBL0ItXkwsfq7Q1W5BuSla9d_nIHz8GIcMaMSKzJH92lDlhfm1AsFDcYHdgs8nF_uRgwxHQYXSL8HLjhctw9cSWDsPQkRqJbFaMm7QBmn3IXS1km6VUNDrGzZxVmM4E68jk0X7KILML4KcCURyASCoNKHUqinp4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8334%23section-2.5>).

b.       My recommendation is to only define SHOULD for elements that are not required per the XML schema, since some of the SHOULD elements in the description are for required elements in the XML schema.  The other EPP Extension RFCs default to the elements being required, but explicitly define optional elements using the OPTIONAL keyword.

c.       Should the <maint:detail> element be of type anyURI or is it free-form text?

d.      The <maint:description> is not defined as a “token” and does not include an optional “lang” element with a default value of “en” like other EPP extensions.

e.      The <maint:tlds> element is required per the XML schema with inclusion of at least one <maint:tld> element, but it’s defined as a SHOULD.

f.        The <maint:intervention> element is required per the XML schema with inclusion of both the <maint:connection> and <main:implementation> boolean elements, but it’s defined as a SHOULD.

g.      Does it make sense for <maint:start> and <maint:end> to be required per the XML schema for an inactive maintenance?

h.      When are inactive maintenances returned?

                                                                                   iv.      The Change Poll EPP extension (https://tools.ietf.org/html/rfc8590<https://secure-web.cisco.com/1otunZ7PpcOjLQ0ob5C5xlTGrhDmiviy6KE7B8gGV15HV7Z9etGBeZVZ0Nffffi4QGsi1PXKaOPEkWN8TFdCpq5fyMwzgqy3_pv3yTTZew7rnrOiCqvQRGE_C61FCAcT5lzK_juGkGIcVSurna-y_IjDgaJJL-VUpc3LOIwrBKDbzwpITbJuLfXQAWvFER7F-VxiTKLKVNsZt1WzsXVMdDOrOfAYctC5x0OljffiaLxN3HR7L9hbgvUAj-eKXygXXoo-EGngow5YzXtuYn-VsCJjXNxT4AWYR_NqTBA51Doc/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8590>) could be used in combination with the maintenance mapping to address the deletion use case, where the previous version of the maintenance is returned with the change poll reason that the maintenance was deleted.

i.        The <maint:id> element includes a human readable “msg” attribute, which also means that there is the need for the optional “lang” attribute with a default value of “en”.  The “msg” attribute seems to only apply to the responses and not the command, but the “idType” type is also used for the info command in the “infoType” type.  It would be better to use the “token” type for the <maint:id> element instead of the “normalizedString” type.

j.        The description of the <maint:system> element needs to be revised.  I don’t believe that the description of <maint:system> needs to say “MUST be present at least once”, since the parent <maint:systems> element already indicates that there MUST be one or more <maint:system> elements.

k.       For the <maint:environment> element, should the “type” attribute and the “name” attribute be placed in double quotes?  Should the “name” attribute be defined as a MUST when using the ‘custom’ type?

l.        The <main:impact> is an enumerated value of either ‘blackout’ or ‘partial’ in the XML schema, so the SHOULD needs to be a MUST.  I would define what is meant by “blackout” or “partial” impact.  Would the use of “full” be better than “blackout”?

m.    The <maint:host> element specifies that it contains <maint:hostname> or <maint:hostAddr>, but the XML schema does not include a choice between the two, but instead requires the <maint:hostname> element and provides the option for the <maint:hostAddr> element.  Should the <maint:hostAddr> element consist of a list of addresses (e.g., set maxOccurs=”unbounded”)?  What is the purpose of the <maint:hostAddr> element and if supported shouldn’t it be a list of host addresses?

n.      The <maint:hostName> states that it SHALL be Punycode according to [RFC5891], but that would only apply to IDN host names.  I recommend updating the description to support both non-IDN and IDN host names.

3.       Section 3.1.3 EPP <info> Command

a.      I would first describe the info command with the info command examples, followed by describing the info response with the info response examples.  The info response is not described and are mixed in with the info command examples.

b.      I would break out the <maint:id> info command and response separate from the <maint:list> info command and response either as sub-sections or more explicitly.  An example of the use of sub-sections is defined in the multiple create forms in section 3.3 of the Launch Phase Extension (https://tools.ietf.org/html/rfc8334#section-3.3<https://secure-web.cisco.com/1curA80ya5swRku-0hjmH-1wmDXZspOXSnvUmn6owCWhXSsYPgIoXXCQoNT_F1DSn3XluSESjeUFsErZVXyk81U86hcuc5gUaDka495CDGY4Qs0yUYZOmj9CBqMU0KSzdVWhZNlgK5v0B1LqafUU3FbcTaWqcdfGA4Zf0YL50Zk7sP5ri2OKEpNg4BJb0NzbrLLuzA6Fc4qOG7A6Y8juStvnIwfK-qgy5MAz6v71fb_2rhmF_bL99LW25rPFdcslKh3kT8bRhk1hdXCFfvSW3m5QnSn-UBesjqBB2GPX00Yg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8334%23section-3.3>).  An example of being more explicit is the multiple info command types and responses in section 3.1.2 of the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry-04#section-3.1.2<https://secure-web.cisco.com/1pCTRoFZ8ANVbjPUKisKP07_SXZgSeTVlBFB9PwGJylFK9qEN45Te-NrkfaYDjFJKb8pajme2cXRcCE-XWK9Qp1Ecqp8a6fMHLZXejHUwKC8OOUKyL5hNGpNSicQVp-pD7DjpEnQpx8JVChK8BbNvBclkasmoyU1IMRqgwi-scAZlRadqjQY1oXrg1LcBV46IilWZhTLrNWz637mvjs9mrnf_RpYY5K0pE26hyg2BW3VFtTO0hIJPDgQDiXsj4lUoA9KNb0Q1vPMvkJPqs64ybjSLYA4HKSsmg95Qf7CnkWE/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gould-carney-regext-registry-04%23section-3.1.2>).

c.       I don’t see a description of the <maint:maint> element contained in the <maint:list> element, which is defined by the “maintItemType” in the XML schema.  The “maintItemType” type contains a subset of the elements defined by the “maintDataType” type in the XML schema.  I would recommend defining the two forms of the maintenance info commands and responses.

4.       Section 3.1.4 EPP <poll> Command

a.       Revise the language somewhat.  For example, “The poll message applies whenever the domain name registry creates, updates, or deletes a maintenance”.

b.       I would also specify that the poll message is an info response for an individual maintenance change (create, update, or delete).

5.       Section 4.1 Registry Maintenance EPP Mapping Schema

a.       XML schema should be able to define the infoType “list” element as <element name=”list”/> instead of including the <complexType/> sub-element.

b.       Comment for the idType can be corrected, which currently reads “Human-readable text may be expresses the maintenance”.

c.       The “host:addrType” in the XML Schema is not defined, since the host XML namespace is not imported.  My recommendation is to not create a hard dependency to the host XML schema and simply copy the “addrType”, “addrStringType”, and “ipType”   definitions into the XML schema.  The following elements were added / updated in the XML schema:

--

JG

James Gould

Fellow Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    2020.

    Regards,

    Antoin and Jim

    regext mailing list

    [email-masked]

---

From: Jody Kolker <[email-masked]>
Date: Thu, 8 Oct 2020 13:02:31 +0000

Thanks for the feedback Jim!  We are reviewing and will get back to you

From: regext <[email-masked]> On Behalf Of Gould, James
Sent: Thursday, October 8, 2020 7:55 AM
To: [email-masked]; [email-masked]
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

--

JG

James Gould
Fellow Engineer

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

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of "Gould, James" <jgould=[email-masked]<mailto:jgould=[email-masked]>>
Date: Tuesday, October 6, 2020 at 3:27 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

Hi,

--

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

On 10/2/20, 4:57 PM, "regext on behalf of James Galvin" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    2020.

    Regards,

    Antoin and Jim

    regext mailing list

    [email-masked]<mailto:[email-masked]>

---

From: Jody Kolker <[email-masked]>
Date: Fri, 23 Oct 2020 21:16:03 +0000

Thanks for the detailed feedback Jim and apologies for the late reply.

Responses are inline.

Please let us know if you have any questions.

Jody.

From: regext <[email-masked]> On Behalf Of Gould, James
Sent: Tuesday, October 6, 2020 2:28 PM
To: [email-masked]; [email-masked]
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

Hi,

JWK – Thanks for the feedback We will keep in mind for future drafts.  I don’t believe we can change from 1.0 now?

  1.  Section 2.3 Maintenance Elements

JWK – As the elements are defined in 2.3, a reference was added to section 2.3.  We would like to only display the descriptions to the elements once instead of in both poll and info command sections.

JWK – Agreed and updated.

JWK – Updated to “anyURI”.

JWK – Updated.

JWK – Updated schema to minOccurs = “0”.

JWK – Updated schema.

JWK – Updated to not be required.

JWK –  Yes.

JWK –  These seems like server preference, 12 months may be a good standard.  Would like to hear additional opinions from the list.

JWK – Would like more input from the list as the authors and I can see either way.

            iv.     The Change Poll EPP extension (https://tools.ietf.org/html/rfc8590) could be used in combination with the maintenance mapping to address the deletion use case, where the previous version of the maintenance is returned with the change poll reason that the maintenance was deleted.
JWK – Sounds reasonable, should it be described here?  We are agreeable to either way.  Could this be a server option?

     *   The <maint:id> element includes a human readable “msg” attribute, which also means that there is the need for the optional “lang” attribute with a default value of “en”.  The “msg” attribute seems to only apply to the responses and not the command, but the “idType” type is also used for the info command in the “infoType” type.  It would be better to use the “token” type for the <maint:id> element instead of the “normalizedString” type.
JWK – Agreed and updated.

     *   The description of the <maint:system> element needs to be revised.  I don’t believe that the description of <maint:system> needs to say “MUST be present at least once”, since the parent <maint:systems> element already indicates that there MUST be one or more <maint:system> elements.
JWK – We would like to reinforce that the “maint:system: needs to be included.

     *   For the <maint:environment> element, should the “type” attribute and the “name” attribute be placed in double quotes?  Should the “name” attribute be defined as a MUST when using the ‘custom’ type?
JWK – Name attribute updated to a MUST if type is “custom”.   Replaced single quotes with double quotes.

     *   The <main:impact> is an enumerated value of either ‘blackout’ or ‘partial’ in the XML schema, so the SHOULD needs to be a MUST.  I would define what is meant by “blackout” or “partial” impact.  Would the use of “full” be better than “blackout”?
JWK – Replaced blackout with “full” and SHOULD changed to MUST.

     *   The <maint:host> element specifies that it contains <maint:hostname> or <maint:hostAddr>, but the XML schema does not include a choice between the two, but instead requires the <maint:hostname> element and provides the option for the <maint:hostAddr> element.  Should the <maint:hostAddr> element consist of a list of addresses (e.g., set maxOccurs=”unbounded”)?  What is the purpose of the <maint:hostAddr> element and if supported shouldn’t it be a list of host addresses?
JWK – Updated “or” to “and OPTIONAL and updated the host:addr to be unbounded in the schema.

     *   The <maint:hostName> states that it SHALL be Punycode according to [RFC5891], but that would only apply to IDN host names.  I recommend updating the description to support both non-IDN and IDN host names.
JWK – Doesn’t Punycode support both non-IDN and IDN names?

     *   I would first describe the info command with the info command examples, followed by describing the info response with the info response examples.  The info response is not described and are mixed in with the info command examples.
JWK – Section has been reformatted.

     *   I would break out the <maint:id> info command and response separate from the <maint:list> info command and response either as sub-sections or more explicitly.  An example of the use of sub-sections is defined in the multiple create forms in section 3.3 of the Launch Phase Extension (https://tools.ietf.org/html/rfc8334#section-3.3).  An example of being more explicit is the multiple info command types and responses in section 3.1.2 of the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry-04#section-3.1.2).
JWK – Is anyone else having an issue with clarity on this section?  Would like to here more responses from others on the list.

     *   I don’t see a description of the <maint:maint> element contained in the <maint:list> element, which is defined by the “maintItemType” in the XML schema.  The “maintItemType” type contains a subset of the elements defined by the “maintDataType” type in the XML schema.  I would recommend defining the two forms of the maintenance info commands and responses.
JWK – Updated – please review.

  1.  Section 3.1.4 EPP <poll> Command

JWK – Updated.

JWK – Can you provide more information as to what/where this should be placed?

  1.  Section 4.1 Registry Maintenance EPP Mapping Schema

JWK - <complexType/> has been removed.

JWK – Updated.

JWK -  Updated.

--

JG

James Gould

Fellow Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    2020.

    Regards,

    Antoin and Jim

    regext mailing list

---

From: Mario Loffredo <[email-masked]>
Date: Sun, 25 Oct 2020 17:44:03 +0100

Hi authors,

I provided feedback but I haven't received any response yet, but never mind.

I note that both the points were addressed by either version 04 or the 
reply to James's feedback.

Best,

Mario

-------- Messaggio Inoltrato --------
Oggetto: 	Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03
Data: 	Mon, 5 Oct 2020 14:54:32 +0200
Mittente: 	Mario Loffredo <[email-masked]>
A: 	James Galvin <[email-masked]>, [email-masked]

Hi all,

Best,

Mario

---

From: "James Galvin" <[email-masked]>
Date: Mon, 26 Oct 2020 10:23:56 -0400

The Chairs would like to extend this WG Last Call for an additional two 
weeks, to close on Friday, 30 October 2020.

Although there have been 2 indications of support, James Gould provided 
some extensive comments, most of which have been addressed in version 
-04 of the document.  However, Jody Kolker indicated in his response 
that he’d appreciate some additional comments on a few items.

The Chairs would like to see some discussion of the remaining items.  
Would others please indicate their point of view in the active thread 
between Jody and James.

Thank you,

Antoin and Jim

On 2 Oct 2020, at 16:57, James Galvin wrote:

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