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). > > 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> 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> >>> Sent: Monday, September 13, 2021 3:14 AM >>> To: a...@ietf.org >>> Cc: draft-ietf-regext-epp-registry-maintenance....@ietf.org; >>> last-c...@ietf.org; 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 >> https://www.ietf.org/mailman/listinfo/regext >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
