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

["Gould, James" <[e-mail]>]

Jody,

Yes, I confirmed the update, which addresses the issue with the poll message type.  One recommendation is to make a reference to the <maint:pollType> element in section 3.1.4, such as:

“For the Registry Maintenance Notification, there are three types of poll messages, defined by the <maint:pollType> element in Section 2.3.”

Thanks,

--

JG

[cid:image001.png@01D6D91A.7FFF8E80]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

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

From: Jody Kolker <[e-mail]>
Date: Wednesday, December 23, 2020 at 9:39 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] RE: RE: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Thanks Jim – We’ve chosen option 2 and updated the doc and included the other changes.  Let us know if you have any other questions.

Thanks,
Jody.

From: Gould, James <[e-mail]>
Sent: Wednesday, December 23, 2020 7:47 AM
To: Jody Kolker <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: RE: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Notice: This email is from an external sender.


Jody,

I provide a response to your comment below.

--

JG

[cid:image002.png@01D6D91A.7FFF8E80]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<http://secure-web.cisco.com/1L2O2KaytcwoXyskLxiIAhZqWBJ-73UutaZWF0nr7yQ0z-rmdIdEF_Ezv4OeEYnezw4ETRLs_yZolC4fmWK9_luXPWxUqT5N0pyqKFkJgr1_SoIDiQhgsqCRHPzAXVv0s1qRAiPTgjpuXdlH0meSJu249dfCYWfxcrkPBE8xlDeIYef4NLNUB405PjYoEi9GHkHUQ41dLZuXAmvCfM2hb1yEd4-WGNCu530TEVrvEzWOeKSUaxb-wFsWv0hhA8RxFGSjtbPoaARDHZ9tbJGD5eYhGNSd7cYX3iyOZUjX0Vjg/http%3A%2F%2Fverisigninc.com%2F>

From: Jody Kolker <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 23, 2020 at 7:41 AM
To: James Gould <[e-mail]<mailto:[e-mail]>>, “[e-mail]<mailto:[e-mail]>” <[e-mail]<mailto:[e-mail]>>
Cc: “[e-mail]<mailto:[e-mail]>” <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Thanks for the feedback Jim.

I’ve got a question for you below.

Thanks,
Jody Kolker.

From: regext <[e-mail]<mailto:[e-mail]>> On Behalf Of Gould, James
Sent: Tuesday, December 22, 2020 10:57 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Notice: This email is from an external sender.


Tobias,

In reviewing the diff from GitHub, I have the following feedback with the GitHub draft-ietf-regext-epp-registry-maintenance-08:


1.       Section 2.3 “Maintenance Elements”

a.       Check on the consistency with how the elements are described with the use or non-use of “The”.  I personally don’t have an issue with the use of “The”, as in “The OPTIONAL…” or “The value…” versus “OPTIONAL…” or “value…”.

b.       Nit – For the <maint:environment> is needs to be “the name of the custom environment”.  I probably left the “of” off in my prior feedback.

c.       Nit – Change “freeform” to “free-form” for the <maint:description> element.

d.       For the <maint:tlds> element, change “The <maint:tlds> element…” to “The OPTIONAL <maint:tlds> element…”, since it’s optional in the XML schema.

e.       For the <maint:upDate> element, change “The date and time…” to “The OPTIONAL date and time…”, since it’s optional in the XML schema.

2.       Section 3.1.3.2 “Info Maintenance List”

a.       In describing the child elements for the Info Maintenance List Response, I would use the same syntax and phrasing that you use to describe the child elements in section 2.3 “Maintenance Elements”.  For example:

                                                                                                               i.      <maint:id>
        The <maint:id> element defined in Section 2.3.

3.       Section 3.1.4 “EPP <poll> Command”

a.       There is a reference to “three types of poll messages”, but there is no indication of how each type is represented.  The example looks to be for a created maintenance based on exclusion of the <maint:upDate> element, but it’s not clear.  I believe the biggest challenge is the deleted maintenance case, where the poll message shows the state of the maintenance prior to the delete.  The Change Poll Extension [RFC 8590] could be leveraged to define the what, when, who, and why, but that would require adding a dependency to it within the Registry Maintenance draft.  The other alternative is to provide similar kind of features for the maintenance poll message response.  At a minimum, the operation would be useful with the possible values of “create”, “update”, and “delete”.  Since the info response is reused for the poll message, the next question is whether the poll message specific elements are added to the info response as optional elements used only for poll messages.  A poll message specific response element could be defined that includes support for returning the <maint:id> child element for deleted maintenances, and the <maint:item> child element for created or updated maintenances, where a created maintenance would not include a <maint:upDate> element and an updated maintenance would include a <maint:upDate> element.  The <msgQ> <msg> free-form description could clearly define the type in the examples, but I would not predefine the values for the clients to parse.

JWK – The github has been updated to include a better description of the create, update and delete messages.  I would suggest that the <msg> also contain a better description if the maintenance is to be deleted, such as “Registry Maintenance Notification – Deleted Maintanence” in order to state the maintenance has been deleted.  I’m curious though why the message should not be predefined?

JG – I agree that the <msg> free-form text should be updated to better describe the type of poll message.  The issue with using a predefined <msg> value is that clients will need to parse the free-form text to infer meaning, which should only be used if there are no other alternatives.  We used the pre-defined text in the Unhandled Namespaces draft and the Login Security Extension to address specific use cases, but I believe for draft-ietf-regext-epp-registry-maintenance there are better and more explicit ways to signal to the client the reason for the poll message.  The following are some possible alternatives:

1.       Use the Change Poll Extension (RFC 8590) for the maintenance poll messages, which provides additional meta-data about the what, when, who, and why.  The disadvantage is creating a dependency to a command response extension when defining a new object extension.  The <changePoll:operation> value is the most relevant here, where the change poll operation values of “create”, “update”, and “delete” with the “op” attribute set to “purge” match-up to the three types of “create”, “update”, and “delete” defined for the maintenance poll message.

2.       Since the maintenance poll message uses the Info Maintenance Item Response, add an optional Info Maintenance Item element that is only used for poll messages, which defines the type with the enumerated values of “create”, “update”, and “delete”.  My recommendation would be to add the <maint:pollType> element after the <maint:id> element in section 2.3 “Maintenance Elements”, which would include a description such as “The OPTIONAL type of Registry Maintenance Notification poll message; values MUST either be “create”, “update” or “delete”.  For the “create” and “update” types, the server includes the state of the maintenance after the create or update, and for the “delete” type, the server includes the state of the maintenance prior to the delete.  This element MUST be present only for poll messages.”

3.       Define a maintenance poll response type (e.g., <maint:pollData>) that is includes the <maint:pollType> element as the first element with a choice between a <maint:id> for the “delete” type and a <maint:item>, as defined in section 2.3, for the “create” and “update” types.  Additional poll elements can be added prior to the choice to address the when, who, and why similar to what is defined in the Change Poll Extension.
Of the 3 options, option 2 is the simplest and may serve the purpose, while option 3 is the most explicit and provides the most flexibility.  My recommendation is to go with option 2 based on its simplicity of adding one optional element to the maintenance item info response.

4.       Section 4.1 “Registry Maintenance EPP Mapping Schema”

a.       Nit – For the documentation element, change “Extensible Provisioning Protocol v0.2” to “Extensible Provisioning Protocol v1.0”.

                                                                                                               i.      That is the version of EPP and not the version of the extension.

b.       For the “host” element in the “systemType”, it should be of type “eppcom:labelType”

                                                                                                               i.      This means that the “addrType” and the “addrStringType” types can be removed from the XML schema.
--

JG

[cid:image003.png@01D6D91A.7FFF8E80]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<http://secure-web.cisco.com/1P53U4L1b4hWqAVb5DpyBcCcHFmeb_Z128UxFNkpjy9HSpt53elm9G0ZOX0hbJutXadbx6kxPYUKfYDA5Nut7wh4gQGXr09cUVGo-M1arJPPiuh87rqe_j30WSZd-0kxv40WcIcUGCWfdHDytUvwj_dqc9-c8FPjLD5LsYn1kEjlOU8yCmNnV2vDV9LqAO7qR2L3WtSRv4Ot2ZaMaiPXA5FolG7Am6rIoKONKuKDUxbR9R0YL8YmzfjThiOeeCV7aSOUUcvovN9mvxiLAvLw2J-sm-QQ-kJ4bh4xgoo6iRdY/http%3A%2F%2Fverisigninc.com%2F>

From: Tobias Sattler <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 22, 2020 at 2:43 AM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Hi Jim,

I prepared a new version on GitHub in the interim.
https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt<https://secure-web.cisco.com/1DN-OOnhk7XRCuFeO097w67zF7Dert9RS-qITvCzFxpj4nf6iOkKLevo56UcKRU7QKfRbpMDHRw16Vc7A1pkwn6my5K2_tIrbJg_O30PyOf1yRZ2b0nkt0ASruJrFWa8PMrVZuAhXa89ph3X42O_Ano99fPujL7HUBRuC3Es9ElNXyrZEOhaB-awI8G4c3gFt5hypaS8JKAaTuXpWSvDBAiaDwCLP-rIpSur7lBv4eiflU7PfrBGfcQWNrNCqln0yl1KCROGIpAiMpM1Nc9EQTg/https%3A%2F%2Fgithub.com%2Fseitsu%2Fregistry-epp-maintenance%2Fblob%2Fmaster%2Fdraft-ietf-regext-epp-registry-maintenance.txt>

I addressed your feedback, with two exceptions:

1.) <maint:start> and <maint:end> shouldn’t be optional, therefore, I removed the minOccurs in the schema. We set it to zero, when trying to figure out how to handle the inactive status. With removing the status, we reverted it back.

2.) In terms of "Migrating to Newer Versions of This Extension”, we need a bit of time to check that.

Thanks,
Tobias

On 22. Dec 2020, at 07:43, Tobias Sattler <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jim,

Thanks for your feedback.

We will prepare a new version, and address your points.

Best,
Tobias

On 21. Dec 2020, at 23:00, Gould, James <[e-mail]<mailto:[e-mail]>> wrote:

Tobias,

Thank you for the update.  It looks like you addressed my feedback.  In reviewing draft-ietf-regext-epp-registry-maintenance-07, I have the below additional feedback:


1.       Section 1.1 “Terminology and Definitions”

a.       The first key words paragraph needs to be revised to the following based on the latest published EPP RFCs:
                                                              i.      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14<https://secure-web.cisco.com/1W_pyvbPN6G46lMDquVtJcbWysY5cJfp3leXTygzSPbDIVV4_hAuavWo6hS_tTVYkuluu03Q3SHT-ADqiSvVWuHyyE4CXJMciVgnmr10wyepqUnnKciEbQZwG6YkAv2uQ64oSV4jtrrc6xfFX5VG2QKK2GQfkMuy4r940o-FyblizEFlUZ89T6dtU3k-68v8TLrpn_x4O4Pn6qYpSoOVsdwV8BSFUfH-66mSt2-vdq0ncbK2L_hoCb4eTZbGdlAlUKL3S_-j6LxqGC3wojEf5t8wDihjmZyQd1PwnosL1Xxk/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp14> [RFC2119<https://secure-web.cisco.com/1xuOgXF--CaBpHH-KucegmFv3aHa_bidITryLob1yg7Ml6O9myRJ_0iB7NIj3-AIWdjYlvcddUEHueWaTZ7Rq4UyigZDyGFAbMqUnX9kw1-GDkMkEqlVsLIiN7dg7fr_paVeh3kpk2ptLYwJqd1vJk0AluukDlzcYpW3fySXxndGEGxDRHXZjPX_IsFMz-hfK39sxXfYHAirmBpvs5cy5fYUaLlGkHBW6F6W6-_IDQ40EIbPAi2tNJ4Crvdp6UUwzSI9Ef6pJyFIwI6q6lUS-Bjfbpy7rE15utRZS9h4vKpo/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2119>] [RFC8174<https://secure-web.cisco.com/1jjIjI2JwpOn269vNInDSnnOGjqzdRkKdX4YssQ6nvB__Hpy53TcpclffQQ1f8YfAL2o30Ey_-8GOJ8lhQRioCp-1SEyDMJk197MopWJfPFkp8eBelgITImL8luZkZBp3LQD7tqXTRbxy3B71eeTWoYHAjk5gAKaEkNjhW_aVc-mbcR6by1QiDZOOWbg3U3uW3BFXQ8wTRwqQBeRUVOy7P9CkLSINTsrPuiB_FOADLdInC-RbNsdWL_ZLUgCRYwcfCCMitklpaV_UIr80mZfYC5ptS1MWjfyvRGLpA-60Lhc/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8174>] when, and only when, hey appear in all capitals, as shown here.

b.       I’m not sure what drove the change to the use of “C:” and “S:”, but I would revert it to the way it was in draft-ietf-regext-epp-registry-maintenance-06.  The way it was in draft-ietf-regext-epp-registry-maintenance-06 matched what has gone through the RFC editor for the latest EPP extensions.

2.       Potential Need - Section 2 “Migrating to Newer Versions of This Extension”

1.       The latest EPP extensions included a Migrating to Newer Versions of This Extension” section to provide guidance on how to support transitioning to a newer version of the extension.  One difference is that the Login Security Extension and the Registry Fee Extension RFCs are command response extensions and the Registry Maintenance Notifications draft is an object extension, so transitioning is slightly different.  One aspect that is unique with the Registry Maintenance Notifications is the poll messages.  What happens when the client supports multiple versions of the maintenance extension that is supported by the server and what happens of the client doesn’t support any of the versions supported by the server.  My recommendation is to return the latest version supported by the client and server, and to leverage draft-ietf-regext-unhandled-namespaces (section 6) for the latter case.

2.       Section 2.3 Maintenance Elements

1.       The word Indicates can be removed when describing each of the elements.  For example, for the <maint:systems> element could read “One or more <maint:system> elements…”, and the <maint:name> element could read “The name of the affected system…”.

2.       Use “an A-label according to [RFC5891]” instead of “A-label according [RFC5891]”, such as for the <maint:host> element, “…which SHALL be an A-label according to [RFC5891]”.

3.       For the <maint:environment> element, update ‘…attribute type is…’ to ‘…attribute “type” is …’, and update “…SHOULD either be…” to “…MUST either be…”, since the environment element is an enumerated value in the XML schema.  I would reuse the language for the “name” attribute from the Launch Phase Extension, such as ‘For extensibility, the <maint:environment> element includes an OPTIONAL “name” attribute that can define the name the custom environment when the <maint:environment> element “type” attribute has the “custom” value.  For example, for the custom “marketing” environment, the <maint:environment> element should be <maint:environment type=”custom” name=”marketing”/>’.

4.       For the <maint:end> element, revise “…equal or greater than…” to “…equal to or greater than…”.

5.       For the <mait:reason> element, update “…SHOULD either be…” to “…MUST either be…”, since the reason element is an enumerated value in the XML schema.

6.       For the <maint:detail> element, update “Contains URI…” to “OPTIONAL URI…”.

7.       For the <maint:description> element, update “A freeform description…” to “OPTIONAL freeform description…”.

8.       For the <maint:tlds> element, update “…contains the following child elements.:” to “…contains one or more <maint:tld> child elements:”

9.       For the <maint:tld> element, you may want to broaden this past a TLD; although I realize that the vast majority of the maintenances will be associated with TLDs.  In the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry<https://secure-web.cisco.com/1-B4S9Zi-_HkaBGOaJMq6C3spbbN-nFUTJiR33GABPjdEnMEC4n9hple9BKzDSYx5ZJLxRuoebD99NCA4WlHA01Ysorwrc8dHVfebH2lsLeXUbJiougGwztlDiGKBj995JjoKJJd2EBWQU-sNsLc-2Dx3h9FPeZ868qU3FdHD0laSLj1kWDbuHX7ofPtLpXI0xjx95-t6IAD6-ZO8o0-AoXxGroQ7FyivzqQH8WugQDnAQBqKSbv2OFHTqD0U_0v84-rdZfVFhreoseLTk_WX4tlKaBHkRuxY4RbHQ6Y3umA/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gould-carney-regext-registry>), the term “zone” was used instead with a description as typically being a top-level domain name.  I’m not proposing to change the element name, but to broaden the description to support a broader set of authoritative zones.  An example is “The affected top-level domain name or registry zone, which SHALL be an A-label according to [RFC5891].”

10.   For the <maint:invention> element, update “The <maint:intervention> element…” to “The OPTIONAL <maint:intervention> element…”.

2.       Section 3.1.3.2 “Info Maintenance List”

1.       From the XML Schema it also looks like the <maint:start> and <maint:end> elements are optional, so I would update them to include the “OPTIONAL” key word like what was done for the <maint:upDate> element.  Is it intended for the <maint:start> and <maint:end> elements to be optional?

2.       Section 4.1 “Registry Maintenance EPP Mapping Schema”

1.       The addrType element removed the “ip” attribute and the reference to the “maint:ipType”.
                                                              i.      The associated “ipType” type can be removed from the XML schema
                                                            ii.      The XML namespace should be bumped up from 0.1 to 0.2, as in “urn:ietf:params:xml:ns:epp:maintenance-0.2” throw-out the draft, since this is a material XML schema change.

6.       Section 5.1 “XML Namespace”

a.       The maintenance schema registration needs to be changed from version “1.0” to “0.1”, but will actually change to “0.2” based on the feedback above.  Eventually “0.2” will be changed to “1.0” when the draft is ready for WGLC, but for now it should reflect the namespace version defined in the draft.

--

JG

<image001.png>

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<http://secure-web.cisco.com/14DO2wQ-CTlxqgzvrrnuAB15YNBEncoC0Itmov7GTl1mx1wuN6Q_uF6IZbXSpSnerwcOMxqupr4KPS2WECjQv9OV19V4sjMNPyJYbXN9-7L7MRm6Z4Yl8YiLyTk45DFAmLbdXEG-xelVKLRgojhJGGqORrfvq0L8EUN4GJ8VFfk7eT5Fy7cIB_3B6gtNVF8lc_xY1T2IFrUy31mVSGR9FCHFTm-mfHPhGNrCy9YxNok14cahq1iUCW0uBVTEyi5pivInIHHkOpZQsOYjK9s5NHRUnS8zckO7U651k90OjVm8/http%3A%2F%2Fverisigninc.com%2F>

From: Tobias Sattler <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 11, 2020 at 5:06 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Hi Jim,

We addressed your feedback and submitted the new version 07.

Thanks,
Tobias



On 9. Dec 2020, at 08:37, Tobias Sattler <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jim,

Thank you for your additional feedback. We are currently preparing a new version, and will incorporate that too.

Best,
Tobias



On 8. Dec 2020, at 21:42, Gould, James <[e-mail]<mailto:[e-mail]>> wrote:

Tobias,

I reviewed the updates made in draft-ietf-regext-epp-registry-maintenance-06 and they look to have addressed my last feedback.  I have some additional feedback below:

1.       Section 2.3 “Maintenance Elements”
a.       The sentences “For creating a new maintenance the attribute <maint:crDate> MUST be set and the attribute <maint:upDate> SHALL NOT be present.” and “For updating a maintenance the attributes <maint:crDate> and <maint:upDate> MUST be set.” seem out of place.  I recommend removing these sentences and leave the definition of when the <maint:upDate> is set when describing that element.
b.       I would default to the elements be required like other EPP RFCs and defining the optional elements using the OPTIONAL key word.  For example:
                                                                                                                                       i.      <main:id>
1.       Server unique identifier for the maintenance with an OPTIONAL “msg” attribute that includes a human-readable description of the maintenance.  When the “msg” attribute is set, an OPTIONAL “lang” attribute MAY be present to identify the language if the negotiated value is something other than the default value of “en” (English).
a.       The “lang” attribute is defined in the XML schema but not described in the text.
                                                                                                                                     ii.      <main:systems>
1.       One or more <maint:system> elements that are affected by the maintenance.  The <main:system> element contains the following child elements:
a.       <maint:name>
                                                                                                                                                                                                               i.      Indicates the name of the affected system, which as “EPP”, “WHOIS”, “DNS”, “Portal”, etc..
b.       …
c.       <maint:start>
                                                                                                                                                                                                               i.      Contains the date and time that of the start of the maintenance.
1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
d.       <maint:end>
                                                                                                                                                                                                               i.      Contains the date and time of the end of the maintenance.  The <maint:end> element MUST be equal to or greater than the <maint:start> element.
1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
e.       …
f.        <maint:description>
                                                                                                                                                                                                               i.      A freeform description of the maintenance without having to create and traverse an external resource defined by the <maint:detail> element.  An OPTIONAL “lang” attribute MAY be present to identify the language if the negotiated value is something other than the default value of “en” (English).
1.       The “lang” attribute is defined in the XML schema but not described in the text.
g.       <maint:crDate>
                                                                                                                                                                                                               i.      Contains the date and time of maintenance object creation.
1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
h.       <maint:upDate>
                                                                                                                                                                                                               i.      Contains the date and time of the most recent maintenance-object modification.  This element MUST NOT be present if the maintenance object has never been modified.
1.       The format of the date and time is already covered by section 2.2 “Dates and Times”.
2.       Section 3.1.3 “EPP <info> Command”
a.       I would revise the second paragraph to read like:

                                                    i.   The <maint:info> element MUST contain a child element. It is either the <maint:id> element, described in Section 3.1.3.1, to query for a specific maintenance item or the <maint:list> element,  described in Section 3.1.3.2, to query all maintenance items.
3.       Section 3.1.3.1 “Info Maintenance Item”
a.       I would revise the first paragraph to read like:

                                                    i.   The information on a specific maintenance item can be retrieved by using the <info> command with the <maint:info> element and the <maint:id> child element, defined in Section 2.3.  If the maintenance identifier does not exist, the server MUST return an EPP error result code of 2303 [RFC5730].

1.   The second paragraph can be removed.
4.       Section 3.1.3.2 “Info Maintenance List”
a.       I would revise the first paragraph to read like:

                                                    i.   The information for a list of maintenance items can can be retrieved by using the <info> command with the <maint:info> element and the empty <maint:list> child element.  Server policy determines if previous maintenances will be included in the list of maintenance items.

b.  Change “The <maint:infData> element contains the <maint:list> element a list of <maint:listItem> elements.” to “The <maint:infData> element contains the <maint:list> element with zero or more <maint:listItem> child elements.
5.       Section 3.1.4 “EPP <poll> Command”
a.       Revise the sentence “The poll message applies whenever the domain name registry creates, or delete maintenance” to “A poll message applies when a maintenance is created, updated, or deleted.”.
                                                                                                                                       i.      The domain name registry is not defined anywhere and it typically is referred to as “the server”.
b.       I would revise the second paragraph to read like and I would include it as the last sentence of the first paragraph:
                                                                                                                                       i.      The <maint:infData> element contains the <maint:item> element defined in Section 2.3.
c.       I would remove the third paragraph “Please see the definition of <maint> elements in Section 2.3”.
6.       Section 4 “Formal Syntax”
a.       I would replace BEGIN with <CODE BEGINS> and END with <CODE ENDS>.
                                                                                                                                       i.      This change was requested by the IESG with the Login Security Extension (https://tools.ietf.org/html/rfc8807<https://secure-web.cisco.com/1NXfHrMjEk_QThvoDHxgqlNjDR89du6BXWlcuvLZEf8UDoNHYzdwww7OYtf_3_svVaQ168qCYexcP6r2b-7GdMbStC2R4Z1CsNNFre2O-FdOgOpStyCVZYsQkdW1x_DCxZzoxLIAiIr34tuigeSCYjouXSpWvsp-i9Z8cVn7s0C5q3rlJYucPdkISwMbbNcN6_DKXWzL87TcxSnviE9u3W9h1u7vyhIxyKkfmFB9uFLFTC0zhPBU2Wq9qRm74l1396z6bs1dtsqRenPCRMmw7zXMCoywlGlS0cH_lzxdNRR8/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8807>)

Thanks,

--

JG

<image001.png>

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

Verisign.com<http://secure-web.cisco.com/1cy2sYeZLPXNvVtqZme9DO8ubODoFoMGL5cjZ5vGsY_WFi7opO-75vcCXp1Bw9ATUxjGHIOyrut4txTnMabLKdtWilNolpHWPpa67U8zG37n6yC75Wjjz3axmYjzrWsQf-RoSnsA3mqegJg5mVosvtoQ3HsOEYTptUPF4XQ0SSYgBsQP26ukNHDijUFCf1XyfDeL1tv4KhQqE2heXlyJigGuk3sAhsxtYHigNeJc84Jk3NRqTO_6ajqJO0UNqWbL_Iyeeuo5QVqpzwGsjTHQZyZ7BdaNoOuvjTirap30G8ek/http%3A%2F%2Fverisigninc.com%2F>

From: Tobias Sattler <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 8, 2020 at 3:09 AM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-registry-maintenance-05.txt

Hi Jim,

We addressed your feedback and submitted the new version.

Thanks,
Tobias




On 1. Dec 2020, at 15:58, Tobias Sattler <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jim,

Thank you for your swift feedback.

We will go through it and make the adjustments where needed.

Best,
Tobias




On 1. Dec 2020, at 15:35, Gould, James <jgould=[e-mail]<mailto:jgould=[e-mail]>> wrote:

In reviewing draft-ietf-regext-epp-registry-maintenance-05, below is my feedback:


1.       Replace “defnition” with “definition” in two places.

2.       Section 2.3 Maintenance Elements

a.       I would modify the description of the <maint:item> element.  Specifically, change the second sentence to read like “This element is used in a maintenance item EPP <info> response and <poll> message.”.

3.       Section 3.1.3.1 “Query one maintenance item”

a.       The name “Query one maintenance item” could be shortened to “Info Maintenance Item”.

b.       I would explicitly define the Info Maintenance Item command element (<maint:id>) without making the reference to Section 2.3, since Section 2.3 defines the Info Maintenance Item Response.

c.       The command example incorrectly references <maint:impact>blackout</maint:impact> instead of <maint:impact>full</maint:impact>.

d.       The dates in the response example should be updated to more recent dates (e.g., update 2017 to 2020)

e.       I would define the response similar to:
                                                               i.      When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <maint:infData> element that identifies the maintenance namespace.  The <maint:infData> element contains the <maint:item> element defined in Section 2.3.

4.       Section 3.1.3.2 “Query maintenance list”

a.       The name could be updated to “Info Maintenance List”.

b.       I would explicitly define the Info Maintenance List element (<maint:list/>), which is an empty element to indicate an Info Maintenance List command.

c.       The dates in the response example should be updated to more recent dates (e.g., update 2017 to 2020)

d.       I would define the response similar to:
                                                               i.      When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <maint:infData> element that identifies the maintenance namespace.  The <maint:infData> element contains the <maint:list> element with a list of <maint:listItem> elements.  The <maint:listItem> element contains the following child elements:
1.  <maint:id>: <maint:id> defined in Section 2.3.
2.  <maint:start>: <maint:start> defined in Section 2.3.
3.  <maint:end>: <maint:end> defined in Section 2.3.
4.  <maint:crDate>: <maint:crDate> defined in Section 2.3.
5.  <maint:upDate>: OPTIONAL <maint:upDate> defined in Section 2.3.

5.       Sect 3.1.4 “EPP <poll> Command”

a.       The dates in the poll response example should be updated to more recent dates (e.g., update 2017 to 2020)

--

JG



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

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

Verisign.com<http://verisign.com/> <http://verisigninc.com/<http://secure-web.cisco.com/1Q7FeDJQhN16gb_93Fht5OZbhpGmfeKUcS0zReQ25sb0CY45l_P0DxHSTU-CpHKvynF3t7biGXCqV74SwtWXpTdeyLPeGF4wuSFs-eOdyUaG2ECdXp9yRPUXKIRvHVQMQTGNXCETjvIgcgjx2UfVz1r7VK5AwnUIL88iY1a9SMqNCNRy6EhkW-Z2Ee4JHOCCs96Jy0RBIn6annwmp7E8dKYWo2r1KSGXwgkLrSB65l2yCKhTTfx67G2_mtmalqeRqbCgPwXB5fMMJayvqMmp5mTY2jM8e0Tf4tMdRyBIv170/http%3A%2F%2Fverisigninc.com%2F>>

On 12/1/20, 7:32 AM, "regext on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Registration Protocols Extensions WG of the IETF.

            Title           : Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP)
            Authors         : Tobias Sattler
                              Roger Carney
                              Jody Kolker
                Filename        : draft-ietf-regext-epp-registry-maintenance-05.txt
                Pages           : 20
                Date            : 2020-12-01

    Abstract:
       This document describes an Extensible Provision Protocol (EPP)
       mapping for registry's maintenance notifications.


    The IETF datatracker status page for this draft is:
    https://secure-web.cisco.com/1li8mLoCxeVjC53-tGvYzKD4YcjkoE6Ev-IZRxp8KydPQ9dy_dgHOxizxSu23hsx4RZVoh7T-GMHV8zzq0pNGEZqcIUucZuoE6CiU1K8nM-bkcRygXmVdp3F6IUnzumkKuauScX42WmKG3nZr5M5pzix-u_BLsV61qGnHT0yCC-E7kdUw4ZjoJ_Gs8-hgv9eabShu15czchF07EvEhnXBjZGQ3xXpcztwDy3pitq834n2SIblYBWUMsF2dJUQTlJi7Q9o-v8tOLMf5xtlZWSLcA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F

    There are also htmlized versions available at:
    https://secure-web.cisco.com/1S6_PU9v_ZkWX9nWp6WP47Od0hWHICawFbyNoykQ6CD7yvG7EpPWyV2XcTGNB60pzVywp_LjRV-wPBbVt7XptxNhGqCGxm4Zihg4MoaiCDcHXbrQPw3IzXF30wCX4DTMCQD2S9PmF2mpQ9i74fwPzhclx0RtAyhDG-mI0VwhiH9_PzB9t57cO3jvzWA3fEIgSL6H6z71YjNr5CgarKpreOKxtbWxyy2gQw1kAfy1waFnV5vIif11v_zgPjEL7IUsUNva6DcWIjZMhYqspuhwKAaSa8M5u8D3iJ5Jj7ByMf-8/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05
    https://secure-web.cisco.com/1XNpISpXfN8MQw1PEsPccAZ0_sZLESxXSKZD_sTvZwJ0QIufYJqXbGF7wdOTdR-pMMnOEH9LNrozfFZ1A4is0CHnJTuDLvhWgwwQ6ZQnpUxrk49oTY2HM7dgf9sbMhl_d2NuioFX8zj9eDSza6SYpZNMAQWA6mWsaobZSEHoaDcBsvWALD0as2Ko7xiWtIyrzb8YC5d0FfZnjNNkjDeILwCeXKqeU6UPGFZ1_1-2vHpW1yad8vgx2YnKBz42vnOcggnzk5g6kBEpntmhY1sKUkA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-registry-maintenance-05

    A diff from the previous version is available at:
    https://secure-web.cisco.com/1KSWNQPojpKmLvO_WIQ_irF2tlGnvVG0NPX5XV846TrqHNQ1N4Nnh4PreFg5v0DC0wn9U0sbBn1u2ZrTcuObqRweYR6CvUQFmHQTv8zi_xPnobTWzspaoT_WO3Hmp5APY41nDiHh4IuQkqTPiXNq6tATib3PopqsT9kHFgCTslmKqRe9GH3jhJgNoPxh4lTox7f5sDssSMM_Sx3dUV40K0iag_k-wRIhnkeBZwf9P6Dw7kl1tClmighR8iEjHf2cO1gZhmKA_WTzmYvg_vwL-vvEtrutRQMo0TyWX7OTMgOk/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-epp-registry-maintenance-05


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org<http://secure-web.cisco.com/1VYNKwPIGDGqP4zEybRxweq-ZAXkhaUb5DyFGW-xpwvzPr9V58uziKa0EH4p5F5Pdz9cu6fXJevjifJ7vkdf8bD2E-TkxqnhdCDhshvDBkZBFZNkqmsUZAQ8kSseoXCU-XoX2gRoh8iDMfVLR0wZxo7kIKoagrwKGI0OBbbrprvBiwp9r0dr1kESUpXETHie4_I_bQOplX6ySaWjRmUjuHa9CcqOqgXTsrWcJGXDVV5yRgoRl010b9xHjEwXk0CriP6EV_pX_5i3gzJK6VoqGy0Ud8pgRtDOU9V5qLtA1Ybw/http%3A%2F%2Ftools.ietf.org%2F>.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/


    _______________________________________________
    regext mailing list
    [e-mail]<mailto:[e-mail]>
    https://secure-web.cisco.com/1v2GmNiRW6LGBp9t0VmF4qf64EGWy5imLishTLvSm672F9aofELXoa5Vvzw1jGfadWXdD85jL-lLbbuTU_ugz0VCc3te-397rOJjLDv0NR80D6etQe8LMdvw1kjzNczvhvXphV0JlOT7ke70TQWpwNhQZbRG2bUBJ2VdVkHRsWCc-5mRwbrwOS6uEMUXD4CDYxVLSUsWuLlQ7rOH5viQJMbIasArywqdHgWETm7pcWtK-vh4Ryzg6QJFYoaSFdee8QhZ0jU7QcWc7RqVs4wPHeUGtcrcAic59uemX_otwo8s/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

_______________________________________________
regext mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1Y_PQMq7QTR4iihjpm3df5cR1Qq7sXkxY5gP3Y6KD_2icfo7jpLfQN9Fcnek1QSAPnhiynbR6pC2rmwO60bbuzjONQleO-rjKpTuTOBbY6kJrDhq44dqKX24ZJagzEa2Xv2OrJGAVwLmC8Jnd56n5SZIaD6CEgq0MFVkntEt-BDoiGpcJS-30v-y7RKUaac00nKwRCvhOeyuDMTNJn15VbdMMMdTqR9Za00Xlq_VaVIcn6MSmXLSPrPc6wEzJcX6muH0Bwmx0H9ejnOBx8rK0aTvF54Wzu6Ul-gEuXqOOd3k/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>



_______________________________________________
regext mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1iPrqxvF7Qbh9Ebzr-DEm3TOwxaBjHAGIxINgnyH1ERSdhgqj-BvQCMTjh1Q9RSQwVjN2Ran0RD2Juhh6zoQ2TxT6vMXtalmq2D5QeAsL_nFiZwcKPLv2dOo2A58IUYeWztyiZSwdIOb3-JPo_G636EbjXWBALpoREtjGXIHAm0WJNBmi26G5YAJ8GXPM5kz1bdBdwkgACa_XytTlp-VoxHDuD07sn8H3EyxJKAEFgpfckU-A91m8y690bHlHhky23orBAc_TgyB1u6uUuoHwp7xCa_v45eLrS7jfB0P4NQQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

_______________________________________________
regext mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1ZdzBB8636DUMAajF_wwHKJH2riJ1UjNGTerRbWgbxGQqcivWfVtV_JwH9Ap0jkE0O_QJ469EfyRiImSV17ib86ZQGxuOK8H2pcS9YOqaHSoYZGzl0AQOQ7rN9Q-YJcWua74QYdwRlEwBm01xvIUJndI7V6jDnTNod0mv3D7_2DVBlcZs0n8spjyRDQKXM7UWvz-AQOOSuw37DKN_BXLXwrZegY6XddNciQW53N3wbUW53BzEz5wKol1hH-WXKxfr4_n9Fsn9BmfKYtNQhbsxhA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>