Apologies for the slow reply - I have reviewed the diff and found that
it addresses my worries.
I now think this document is ready for publication. Thanks!
Harald
On 9/21/21 7:24 PM, Tobias Sattler wrote:
Hi Harald,
Just checking, are the changes on GitHub fine for you?
Thanks,
Tobias
Am 13.09.2021 um 15:06 schrieb Tobias Sattler <m...@tobiassattler.com>:
Hi Harald,
Thank you for your swift feedback.
We have incorporated the changes on our GitHub repository
(https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt
<https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt>).
If this version is fine for you, we will do the update on datatracker.
Best,
Tobias
On 13. Sep 2021, at 14:13, Harald Alvestrand <har...@alvestrand.no
<mailto:har...@alvestrand.no>> wrote:
On 9/13/21 12:57 PM, Jody Kolker wrote:
Thanks Harald for the detailed review of the document. Please see
our comments in line below.
Thanks again!
Jody Kolker
-----Original Message-----
From: Harald Alvestrand via Datatracker <nore...@ietf.org
<mailto:nore...@ietf.org>>
Sent: Monday, September 13, 2021 3:14 AM
To: a...@ietf.org <mailto:a...@ietf.org>
Cc: draft-ietf-regext-epp-registry-maintenance....@ietf.org
<mailto:draft-ietf-regext-epp-registry-maintenance....@ietf.org>;
last-c...@ietf.org <mailto:last-c...@ietf.org>; regext@ietf.org
<mailto:regext@ietf.org>
Subject: Artart last call review of
draft-ietf-regext-epp-registry-maintenance-17
Caution: This email is from an external sender. Please do not click
links or open attachments unless you recognize the sender and know
the content is safe. Forward suspicious emails to isitbad@.
Reviewer: Harald Alvestrand
Review result: Almost Ready
I have reviewed this document as part of the ARTART review team.
Verdict: Almost ready
There are a few things that need better definitions to be
comprehensible enough for interoperable implementation. There is
also one confusing formatting error that should be fixed before
publication.
Weak definitions:
- "Maintenance event" is never defined. From context, it is
possible to infer that a maintenance event refers to some service
being partially or wholly unavailable in the time interval given;
given that this is the whole point of the document, this should be
explicit.
<<
We will add the following to the first paragraph under "1.
Introduction"
"Registries routinely update systems to ensure a higher quality of
service, implement new services, or upgrade protocols to the newest
standards. These updates are pushed to various registry
environments during time frames that are communicated to registrars
as "maintenance events". Registries usually inform registrars for
maintenance events in various formats, none of which …..
Very much more informative!
I'd add "This may require making services unavailable for some
limited time while the upgrade happens." Hitless upgrades are known
technology, but quite complex and not possible in all places - the
text proposed seems to assume that all updates require maintenance
events.
"
It should also be explicit that the service will be either fully
and correctly available or not available at all, and that no harm
(apart from being denied service) will come from trying to access
the service in the maintenance interval; "maintenance" that, for
instance, puts a test database up where the normal database is
would be just a broken service, not "maintenance" in this sense.
(If broken stuff might happen, I think you need a new impact value
in addition to "full", "partial" or "none"
- something like "STAYAWAYYOUWILLREGRETEVENTHINKINGABOUTTRYING").
<< In the case described above and any other similar maintenance
events, the registry should not be allowing registrars to connect
to the system by taking a "full" maintenance. I don't believe we
have ever experienced any maintenance event of the type described
above.
I certainly hope not! Calling out that expectation may be good.
- "maint:connection" and "maint:implementation" make very little
sense as described. They may refer to having to reconnect the EPP
service or to upgrade the EPP schema in use, but since the
"maint:name" element of "maint:system"
seems to encompass WHOIS and others, the actions that may be
required are not clear; an instruction to "do something
connection-related" cannot be interoperably implemented.
Suggestion: Either delete these elements or (if intended to be
consumed by a human) add the option to add a text description of
what should be done.
<< These flags are only meant to indicate that the registrar
should review the maint:description element in the response for
further details explaining actions the registrar will be effected
by regarding the maintenance. Adding a description to both of
these elements seems to duplicate the information that should be in
the maint:description element. We would like to suggest this edit
to the document:
From:
<maint:connection>
The value SHALL be boolean and indicates if a client needs
to do something that is connection-related, such as a
reconnect.
<maint:implementation>
The value SHALL be boolean and indicates if a client needs
to do something that is implementation-related, such as a
code change.
To:
<maint:connection>
The value SHALL be boolean and indicates if a client needs
to perform an action that is connection related, such
as a reconnect.
The attribute should only be used as a flag to indicate connections
will be affected. Servers SHOULD include a description of how the
connetions are affected in the <main:description> element above.
<maint:implementation>
The value SHALL be boolean and indicates if a client needs
to do perform an action thate is implementation related,
such as a code change. The attribute should only be used as a flag
to indicate connections will be affected. Servers SHOULD include
was this meant to say "implementations will be affected"?
a description of how the implmenation is affected in the
<main:description> element above.
- pollType seems somewhat strange. The implicit definition seems to
be that the client polls the server and the server replies with a
list of outstanding maintenance events, with the value "create"
returned the first time the server tells the client about the
event. This implies that the server is required to keep state of
what it has told each client about the event; same goes for event
deletion. If such a state tracking requirement is indeed intended,
this should be explicit.
<<
This type of tracking requirement was not intended. Registries
will not be expected to keep state of what each registrar has
received as far as the type of maintenance events.
On reading RFC 5730, I see that the <poll> command has a queue of
events that can be retrieved, which will then constitute the memory
of what the client has received or not; if it's still in queue, it
hasn't been received. And for this scheme to work at all, there has
to be one distinct queue of notifications per client. In that
context, the "pollType" sounds much more reasonable.
Consider this comment dropped.
Formatting issues:
In the list of elements in section 3, the indentation of
<maint:environment> and the succeeding elements indicates that it
is an element of <maint:systems>.
Examples indicate that it is an element of <maint:item>, which
makes a lot more sense.
<<
Formatting will be updated.
Precision in definition issues:
The incantation "The extended date-time form using upper case "T"
and "Z"
characters defined in ISO 8601 [RFC3339] MUST be used to represent
date-time values." is not precise (I don't know if it's common) -
it seems to claim that RFC 3339 is ISO 8601, which is just
confusing. Suggested format: "The date-time format defined as
"date-time" in [RFC3339], with time-offset="Z", MUST be used".
<<
Text will be updated.
Styllistic issues:
The cuteness of using "upDate" as both meaing "update" and "this is
a date"
hurts the eyes :-) Unless there is tradition for this name, I'd
suggest being boring and using "updateDate".
<<
This document is following the same pattern used to signify the
date the state of a domain was updated, <domain:update> from RFC
5731, which we considered to be the standard to be followed.
Ack! Tradition rules.
Having migration considerations before item descriptions looks a
bit weird when reading the document top to bottom. Would it be
nicer to move it after section 4?
<<
The document is following the same format that is used in RFC 8807
and RFC 8847 where migrations to the new version of the extension
are covered immediately following the introduction. However, we
will update this document to move the migration section to after
section 4 if this is what is needed.
Your call. If it is an existing tradition, you should decide whether
it's a good tradition or a bad one.
I have not attempted to verify the schema, nor have I attempted to
check the document against common styles for EPP extensions. If
comments touch on things that are mandated by common EPP practices,
feel free to consider these comments overridden.
Hope this is helpful.
_______________________________________________
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
