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 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 element be of type anyURI or is it free-form
text?
* The 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 element is required per the XML schema with inclusion
of at least one element, but it’s defined as a SHOULD.
* The element is required per the XML schema with
inclusion of both the and boolean
elements, but it’s defined as a SHOULD.
* Does it make sense for and 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 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 element instead of the “normalizedString” type.
* The description of the element needs to be revised. I
don’t believe that the description of needs to say “MUST be
present at least once”, since the parent element already
indicates that there MUST be one or more elements.
* For the 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 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 element specifies that it contains
or , but the XML schema does not include a choice between the
two, but instead requires the element and provides the option
for the element. Should the element consist
of a list of addresses (e.g., set maxOccurs=”unbounded”)? What is the purpose
of the element and if supported shouldn’t it be a list of host
addresses?
* The 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 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.
