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
Notice: This email is from an external sender.
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.
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
* 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).
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.
* 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.
* Should the <maint:detail> element be of type anyURI or is it free-form
text?
JWK – Updated to “anyURI”.
* 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.
* 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”.
* 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.
* 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.
* 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.
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.
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.
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?
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.
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
* Revise the language somewhat. For example, “The poll message applies
whenever the domain name registry creates, updates, or deletes a maintenance”.
JWK – Updated.
* 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?
1. 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.
JWK - <complexType/> has been removed.
* Comment for the idType can be corrected, which currently reads
“Human-readable text may be expresses the maintenance”.
JWK – Updated.
* 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
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/>
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
