Jody, I reviewed the draft updates and your responses. I provide my feedback embedded below. I believe there are still changes that need to be discussed and agreed to prior to closing out the WGLC.
Thanks, -- JG [cid:image001.png@01D6AE15.51B08F00] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Jody Kolker <jkol...@godaddy.com> Date: Friday, October 23, 2020 at 5:16 PM To: "regext@ietf.org" <regext@ietf.org>, James Gould <jgo...@verisign.com>, "gal...@elistx.com" <gal...@elistx.com> Subject: RE: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03 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 <regext-boun...@ietf.org> On Behalf Of Gould, James Sent: Tuesday, October 6, 2020 2:28 PM To: gal...@elistx.com; regext@ietf.org Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03 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 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. JWK – Thanks for the feedback We will keep in mind for future drafts. I don’t believe we can change from 1.0 now? JG – I believe the best method to address this now is to include the epp scoping (urn:ietf:params:xml:ns:epp:maintenance-1.0) in the namespace, which will be requested by IANA later. 2. Section 2.3 Maintenance Elements 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/1ssIITfHP2Ks9_OfL2Sckw8wvwT1ZpnOeH-HJCvx5jsStA39gPm3h1hX3qYCXkHnFs2RI9Qy-Z-7U43ydg92IRFHBdpJ163bOkBBAa-eCUE8XNDdxOK7VN_RNh042kUt9Th3eEa45jVcnj4yCC47ewclZr_gzpaFOy3hUGezdvT3LWozp68k8HEJ_UW6GBYiod46opvORbcNujMAw7Ids88slmghRBUulx1dwu-8HzfekkRpqiXkEkAVWf7-NhdrdbaV8s4ZqDmoWTZTFTSM7LsuQfr-d9D5N4Nn0-eJZuNc/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8334%23section-2.5>). 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. JG – I believe the second sentence in 2.3 needs to be modified to read something like “This element will be used for EPP <poll> message and for the EPP <info> response.”. The remaining issue is that there are two forms of Maintenance Elements with the <maint:maint> element. You could make it clearer by defining the two forms in section 2.3, where an individual maintenance could use the <maint:maint> element and the maintenances included in the list could use the term maintenance item and an element like <maint:maintItem> to clearer separate them. Both forms of maintenance elements could be described in section 2.3, or the two forms could be defined in section 3.1.3 “EPP <info> Command”, where the list of maintenance items only applies to the info command and not the poll message. There are multiple ways to cover, this but the inclusion of two forms of info commands and responses should be made explicit. 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. JWK – Agreed and updated. JG – I noticed that the use of SHOULD remain and the XML schema was updated to ensure that the SHOULD elements are made optional instead of required. One element that is not in sync is the <maint:connection> element which is defined as a SHOULD, but is required in the XML schema. My recommendation is to change the element to a MUST, since it’s a boolean value. Another item is the value of the <maint:environment> element is defined as a SHOULD (e.g., “SHOULD either be …”),which it’s a MUST in the XML schema with the use of an enumeration. My recommendation is to change the SHOULD to a MUST. c. Should the <maint:detail> element be of type anyURI or is it free-form text? JWK – Updated to “anyURI”. JG – I confirmed the change. 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. JWK – Updated. JG – I confirmed the change. 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. JWK – Updated schema to minOccurs = “0”. JG – I confirmed the change. 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. JWK – Updated schema. JG – I confirmed the change. g. Does it make sense for <maint:start> and <maint:end> to be required per the XML schema for an inactive maintenance? JWK – Updated to not be required. JG – I confirmed the change. h. 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? JWK – Yes. JG – That makes sense. ii. How long should deleted maintenances be kept around for? JWK – These seems like server preference, 12 months may be a good standard. Would like to hear additional opinions from the list. JG – I believe it would be best only to include active maintenances and to delete the maintenances instead of marking the maintenance as “inactive” prior to deleting it. 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? JWK – Would like more input from the list as the authors and I can see either way. JG – I believe the absence of a maintenance equites to an “inactive” maintenance, so I view only including active maintenances easier for the client and server. iv. The Change Poll EPP extension (https://tools.ietf.org/html/rfc8590<https://secure-web.cisco.com/1km9KBmgcOCvbgMS0DYqUjKfaOdl9g3UVQZfGWqmc-BLI7Zhj2WUNPmeQLG2vsmukitKQHtLBWDkRWCxcvOqpwwzRUpeEizaf5dJeRIRqYk4jGfAqENRuiUlouZk2cZ4YG4Z3Rbcfbp6vYN2lh2vzcTCRMHcBp1P6gHj2NRVrl3atLDcsVzsiBYxA_uigoIxrPeGBYNJuvPafYn90yjHuwUa4L-R1HO39Ak8gt7YGs2O14HCuACfYJSmqWBiOhkI5KqpGl9OCv6rSdLHx0c677OYVmHTNxG229wR8a_NMc1s/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. JWK – Sounds reasonable, should it be described here? We are agreeable to either way. Could this be a server option? JG – If a notice needs to be provided to the client that a maintenance has been deleted without the use of an “inactive” status, then the Change Poll EPP extension would be the best approach to handle the delete poll message. We haven’t included references to extensions when defining a new EPP object mapping, so this would be a first. The alternative is to support the “inactive” status for use only in the poll message. 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. JWK – Agreed and updated. JG – I confirmed the change, but support for the optional “lang” attribute with the default value of “en” is not included in the description for the <maint:id> element in section 2.3. The <maint:id> element using the “maint:idType” is used in the info command and the info / poll response, where the “msg” attribute and its associated “lang” attribute is only applicable in the responses. I recommend defining the “id” element in the “infoType” to be of type “token” instead of “maint:idType” to remove support for the “msg” and “lang” attribute in the info command; although the maintenance id returning in a maintenance item could not be directly used in a subsequent info command for the individual maintenance without getting pulling the id value. I don’t see this as a big deal, to ensure that the “msg” and “lang” attribute are never passed in the info command. 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. JWK – We would like to reinforce that the “maint:system: needs to be included. 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? JWK – Name attribute updated to a MUST if type is “custom”. Replaced single quotes with double quotes. 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”? JWK – Replaced blackout with “full” and SHOULD changed to MUST. JG – I confirmed the update in the XML schema. The examples (poll response and info response) need to be updated to reference “full” instead of “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? JWK – Updated “or” to “and OPTIONAL and updated the host:addr to be unbounded in the schema. JG – It looks like the <maint:host> was changed to a simple element with an optional “ip” with a enumeration of “v4” or “v6”, and a default “ip” attribute value of “v4”. It’s not clear whether the <maint:host> element is supposed to be a host name or a host IP address. Based on the use of the “addrStringType”, it looks like it should be an IP address, but the example uses a host name. My recommendation is to set the host name only. If an IP address is desired, a single “ip” can be provided to use an “ip” attribute of type “addrType” and an “ipType” attribute of type “ipType”. I question the need to supply the IP address though. 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. JWK – Doesn’t Punycode support both non-IDN and IDN names? JG – I believe that the use of Punycode encoding would only apply to IDN domain names (e.g., “xn—"). I would specify the use of the host name that uses Punycode for an IDN host name. 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. JWK – Section has been reformatted. JG – The section still does not explicitly cover the two forms of the info command (list and id). I recommend stating that the info command supports the two forms and that place the two forms in sub-sections that includes the description of the command and response with the associated 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/12Gv8PtGMIWhmj9VgfW0aAG5d8IoQ9AkHQdJ28K0QAXhOmFXjBIAXyBLd78ANtZpURJAKDYhfXVp5avA9c_fYcWu50zyvcJG8WLcObPh72rIh4OqQ_5gDFlU2PrTyt22AmCgtkH1kmrloR__JUK8bxuAMlJrJw4oO6HUojU2SiyOWjnFOxbNH3vIRRbH30NoctnlVhuiuBh2X4-fmmckNjZ2n56b-ZgFgXGe9bF1NfIzRv4r0C2xYRiqbnT0b8SxE-1HeNkvRi0p5x9m7yKUQRFJIDQiA9sRyAVUIO--vpYc/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/1TmD4WOHRlOwaWfUxDKssxou4IGSo0sNZqMYL4ggzoqezrGC2fFtz3Et9Xd6Mq_Ysl03IxDGf7xDFJadw3JPSh9h8PQT93LQ6Yjqp3sHHWyi7NIpz8I0xqMm8vK11o8PF0pmAkIX8a0GlQ2B7jrM-FP9z88Xzp-qX0cYIv3zQuX_QmmmS10PV6jsIYEM30EPiqpNZauy8XRwUIasNBN6k603kb4-kucexhzNyu9_rxKgANNaVO4R81budZp79zAGFP1O8EdjZlno_KFBVdY4WzAVlX9_DRX2rBYdEQVdVCJI/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gould-carney-regext-registry-04%23section-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. JG – I did implement the entire draft, and my feedback is based on the lack of clarity of the support for the two forms. The only way I figured it out was by looking at the XML schema and reverse engineering the forms. 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. JWK – Updated – please review. JG – It’s better, but I still prefer splitting out the two forms into sub-sections. 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”. JWK – Updated. JG – I confirmed the update. b. I would also specify that the poll message is an info response for an individual maintenance change (create, update, or delete). JWK – Can you provide more information as to what/where this should be placed? JG – If you provide a full description of the info response for a maintenance id, then you really don’t need to repeat anything for the poll message. The poll message could be described as being a maintenance id info response, where a sub-section would be a useful reference, that is inserted when a maintenance is created, updated, or deleted. 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. JWK - <complexType/> has been removed. JG – I confirmed the update. b. Comment for the idType can be corrected, which currently reads “Human-readable text may be expresses the maintenance”. JWK – Updated. JG – I confirmed the update. 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: <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> JWK - Updated. JG – I confirmed the update. -- JG James Gould Fellow Engineer jgo...@verisign.com<mailto:jgo...@verisign.com> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/<http://secure-web.cisco.com/1DXIdtM9_tJqM9bsUfRBUJPF3PneqG_VTa8FHXVNAIE80uThSMxv-xJYSCDta9NCzRbFktVaYJl2jbPA1IVBuNntu6bHhG8CNp_wqZ-_Cgm79FhygwNkeigM5e7kJ4XpC3QIh42qTWkT3KDyolDm4xvzgiwUOD2Q8bxCx_k4m4JfljtKKn8Wroh6cuBTwWbJwXD9Yn4QxNP5VwVNquQ5r0o7pMl9cKJbVcWNAZcac9oYDjEzfCK_U-lIl685G__H5B1gCrhXR_m89YGqVGBtLpw/http%3A%2F%2Fverisigninc.com%2F>> On 10/2/20, 4:57 PM, "regext on behalf of James Galvin" <regext-boun...@ietf.org on behalf of gal...@elistx.com<mailto:regext-boun...@ietf.org%20on%20behalf%20of%20gal...@elistx.com>> 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/14WoNaSzKUxwiQvyFtivmhki2NRUkzRYQ7LL4wBCuxotHDT9vwzv8GABAlrm9-cxdSpu6MVB0P4OfGeG4RiXSLDcaJ7CIonnYniQxYMXAoMLNWUnyDKY2UathW7ulM87ls59KsczLcucYAzmCwvDLs73JUgk2FFvB-wMfndbW4axgl6shfqdsgW1QGMqUtCYK1LkxmCfP9jTc53yPQItk8E3InKLboiR4DShC33Yo_OtXZlSoy16RITasjytx4oZ0kxgcKdb0MJqU-K9k2_ZpKA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-registry-maintenance%2F 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 _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://secure-web.cisco.com/1DJzCb9ui1hohfJj4BRZEe91VteUi4Ekqzw2TzFZY6cqp3Tzb5UGSpfjZZ9v2x3q4oYQPar_h2ypEbIdNN8-2OSqRu07Ldg03NzaXHCHmPcrCg1d-rjx1w7f32X0K-vxTDuIgeoeY4A12f8iolWIDv1-ifZmOaragpNhE6k5w16dHwdff_WVR6XOWH9Q6xZEbwdj86NyXaZwwFgUkOeHVIF2SVRSKZcOudsWNNPQIXX_V7_K-pLcsArFiPH62utkQtZvbKR5v5eIUIQgXusplTyyHqviyNlaL327kQ8SmME0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
