From nobody Wed Oct 6 11:29:53 2021 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E4D3A0365; Wed, 6 Oct 2021 11:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9YxYOTpA4c2; Wed, 6 Oct 2021 11:29:37 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130071.outbound.protection.outlook.com [40.107.13.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09563A0366; Wed, 6 Oct 2021 11:29:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WDu7cJU8gTvJ3gIVjCFLKHV1bTa65NyEeW3At4QArvghfxBwjJjCkF4qK9tudfZxRhHE4J/boW/XePF4r8yVR+iwOn1Ov+G1m2fXd9QcFKExe7hjwgL/w7WD5IKz+eX9bXSixf4I7Eor+XondebGGw2sPuex6sBtSsmdJ9clMILup4Xl+jC45cOedIJEQb9g8lJWmcOiJIBR2yDG/c0Bxq55GrCNiAfJVZPmOOqsf9wDQjWV0hEgdlTvdiFJf527L7Er3U104XO7FJzB04KMZBY1+N3AMfAmV9O3+f18WTMnj1sh1MaSFE1Ykt6Kt5FPASBeDkvCuqTsZC0/Sq1/+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t/yRqHiWZNi0e235JDXrh6meUcI9zU3BA+8E3042Qrg=; b=PeF1sZhtPnUeKblmI52dS3IpJMjoymPMbdOuMs/Vr41ohz/bx3zwwrV2P3EavcSubXv1IDSrF3lA6WHA7JdauJkKJRTyWYI2B1jGkwypclcHvT3HePlmurOIfOzpXj2pytxZgm11hAeoEIuMxYA2E7rn0bZJTavWF6Rruk2KtGysRrLsnONun8F4gzdyyIYUETK7+JNsBHP3GufVod2U/o25l1/YIYdbYgQkHMUWXMR69Tp4btP8aHm7LEhknB5Q9jwpkfDqtF91WSkOPu3luq0AJMKSvgDSXknhANop5/9cGfVsUXZXw9FgRGoypYZaC+IUSde3SwtZUiGRqyrvww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t/yRqHiWZNi0e235JDXrh6meUcI9zU3BA+8E3042Qrg=; b=pB8pbqLDtJnY/XILrYf4EbDSVxgwK/D35McyqMZLmNH9KYjTll/n2afxPZXRgbokOk1COlznz0ndZjGTNfOrBkKPdpq8YhC1WRA2bjVNHsalgvKPXL/sHhEoiAHdLK1T0BYsdHMg8ITvGCw60ZtKm0tx9J6Bzcfl9TV0y7JugZ8= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2540.eurprd07.prod.outlook.com (2603:10a6:3:75::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.13; Wed, 6 Oct 2021 18:29:27 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::94b7:db6b:3aa3:8875%5]) with mapi id 15.20.4587.016; Wed, 6 Oct 2021 18:29:27 +0000 From: Francesca Palombini To: Tobias Sattler , Harald Alvestrand CC: Jody Kolker , "art@ietf.org" , "draft-ietf-regext-epp-registry-maintenance.all@ietf.org" , "regext@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] [regext] Artart last call review of draft-ietf-regext-epp-registry-maintenance-17 Thread-Index: AQHXqHdj1lccgE1K30OiyeuZxYzWmquhy3YAgAAVF4CAAA6xAIAkfyS7 Date: Wed, 6 Oct 2021 18:29:27 +0000 Message-ID: References: <163152086092.21721.1892292751200949140@ietfa.amsl.com> <0813befe-75b9-c083-8a9e-d4e52f9e1173@alvestrand.no> <561E0DE0-189B-42C3-A567-BD66BF053F50@tobiassattler.com> In-Reply-To: <561E0DE0-189B-42C3-A567-BD66BF053F50@tobiassattler.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tobiassattler.com; dkim=none (message not signed) header.d=none;tobiassattler.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6379449-4ea2-474c-aee2-08d988f73afa x-ms-traffictypediagnostic: HE1PR0701MB2540: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WXeeUiAr6iXOU1fhLTy92UoTW4/huKUKVEImBKLFhq41jsy8a7Vx9BJQ7s1os/uScHFXcMDfs4EyvS48EhXHjvb3HZw5FXdgxykNSF7SHF4xYKFaC4d5TpzbuvVdxzEhlRH7r/KsCAUsUl6P7RsitXhDtcuxNVeWlEWuXBhvc8DDoKqS8nsbM9XSu1T7zIkIqelDlaOTukVv/nAuqeT7sK+V/BlNCwZGV7TeBRV0eRyXAhbJijGAwqJCFME1VC6HaUw4p6t4iXCDcz5g8gmeE6zLQ5zaxucVmgZ2v5sL2UoOugHX2YDpGjtX/Vv+SYPZno/QTzP0fo42c81i+xgMBlQcPT2+9diFx9LVastzhxLlCDtCyZIZAieGmMZh/uXK0+0HG83J5maPD98Pd0x+nnSRHVjKTPuJ+5G32VUIxegZBDBJdBnw/75wjTteZFwOb0wnkH/u7bw+OGqrCCIuVVllM+y+1kwMchyoox+89/TbFwlofHudKnqTMRk0HDrjKcav7j81aEjG+7Jvna1Y5SWv3gYLwFO9TXqVC8robS+0T+kKMgshbjECj/AeMzW3NTGmfcqYbZJw2foeCNS7tgA3NcbqcfaKeoLxk0BQCiadkDP99KM7fMu0uXsmvCjyc4WNAjUgGS1PmwOYDs73zV7QgmqpAB2wXwNA4B7VCfS5ANaH9aSoX2dVC0Rb5BGdx5rtZMv8VYCMkHrziPmJaeV8K1CUGOmKQS58Fe0KojPOr5tTSAsTEUcOkUPSDQKJ+8B41KkWd56SBZN/A0YtUuEJWdz1JzShxqZc97RhWMMAk799FmWAHuY+6OeXg+jGNX+rN2d6wrUr10e3ycHUJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(2906002)(186003)(8936002)(8676002)(166002)(122000001)(54906003)(83380400001)(110136005)(38100700002)(4326008)(86362001)(316002)(6506007)(53546011)(38070700005)(71200400001)(508600001)(966005)(52536014)(76116006)(44832011)(33656002)(55016002)(9686003)(5660300002)(66946007)(66556008)(66446008)(66476007)(64756008)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?wNSJJFyKqyK2VrToaE2WHacx/0ygX6Rphh3FolfpIOStQhvEST5nPREl?= =?Windows-1252?Q?h4lV0ybNg+URVfwltgIRZsvYzm0POACti4in83ikcQQOLe/AN6j9PK7E?= =?Windows-1252?Q?xGkhTqc3IdL1Gt5kUWgobCpVIOyDGDcURxVKw4qmxLyjs/yOIx45+OVL?= =?Windows-1252?Q?dOdx80sutalrAsfv8CMJqwRJ+jFhYQ3QNE8zTtOAlfz+2EA1tQ4v2nw1?= =?Windows-1252?Q?nt81BSDNl+scSk43xWMsSoocVHfH1JCOMasavRaFLplNLekvoq1C0a7U?= =?Windows-1252?Q?eZGRYlXm95nHBz1DyifDcVXT+rvHGfyYuNc+pM0JiEHtWl7INuSuJW+1?= =?Windows-1252?Q?3xn15ulV0zeDAsE6278VLRzihOLyeRpzQHfm+5lfB7s6INFmUYc3Haah?= =?Windows-1252?Q?qMV3ge2AVvyryfVLz7auSbG+NxcodpFh3pmPaIMxT4oMcq31PEwqMlkK?= =?Windows-1252?Q?dB+nTKly06xYW8MXhF2G2Ui17byqYYQ3HIuNNijXHFoqR9vnpbJYiNoF?= =?Windows-1252?Q?+N7D9/Y340EsmF8+Uukr2wpefoiC7jQocku2d89LGYGXUO6XRJeWRArS?= =?Windows-1252?Q?rI6OrMAb0UvPBoNKLv4uFJNbWH5maQeeqGI1RajqOkw/HahXrQXEe1TN?= =?Windows-1252?Q?H7lZjENIpJiyhwZCj+FSJlHaTMoz+iV0Mrj13weXPZyUFbG6ob67x2QT?= =?Windows-1252?Q?+haKqmQb7HrpwFN8kMH2oqYRAO1xw/dDZtlHbBfnoNE/5Lf7B2N2Wnxv?= =?Windows-1252?Q?YpT4UVek9yithELRu/iSMi5xIAL298Sijo9p3TdSeN4uP4wy/SWvsd8R?= =?Windows-1252?Q?kI4Ciz8ZjeaxIeblkkyd6LLhjgDDhQOJwfVovAu5rzdff0mP1yJaLhFm?= =?Windows-1252?Q?m/BXdTqan9I8XIxX2XisgQMwwarCMga+PBYnX1NTZd3t23Rh9DywpIag?= =?Windows-1252?Q?+0KIQpQ+o+5YeU1Q8gMztZ9qR208LXgFceWy2id5KQPvu2VtrOBxork8?= =?Windows-1252?Q?wrZBr7klkSmVonI7u6eGenlVeDeah8BjV7iEEKjZd3YiPcoNtIpGoAXZ?= =?Windows-1252?Q?chIpbYeyictZbDLJ7M8yo5l7PnUfkdqWpBBgBCXYwvtOD4LN/n5UJew+?= =?Windows-1252?Q?jFU6XHvHpC7YozaKeTlHRwf/peIsX9SF9iq072Dz3AY/X8x4Eztl3HeL?= =?Windows-1252?Q?1l1Xo6JqchQy9sTC5ioSSoMSjdD4azrfajXtNEvugKtciNuu5/ax8OcA?= =?Windows-1252?Q?O8VK+k2IMTMdJjyTruf7qgvaekvc7hMN+cWxDtQCHY+hbkuHrXE5uoCf?= =?Windows-1252?Q?3gpvFv+O9TB1R3xqHb10hnUnHPlrxP5OJx/WhXJsQmUHMA3hbqaUBxQo?= =?Windows-1252?Q?PsnW9Voab4KXsvxWat1mn4JEBxVeR4Bt+GZu8P5NlPRG/LEszRobLANl?= =?Windows-1252?Q?euBAAhZ4Rijif+rvbnVDzRL25zyfUcyzq/51RDtN5bl7HdBdXVbR94E1?= =?Windows-1252?Q?+X3M75+Kd/XCIyFDmPD7Hlg6aKDOfg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4217FC6A2336803938C9DDDC98B09HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6379449-4ea2-474c-aee2-08d988f73afa X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 18:29:27.5573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UbPjWeXUceyNB+ld5TqvMRGZLMVK4p6jehIKcKnUWLVz55QzLDVN0DlU7mDqvxZCjMn3kMLXUvxFZoHOMZhXgCUvLkrp4u7WGHux5yzDgMdWggjle5Y9TrO/OM733Ky9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2540 Archived-At: Subject: Re: [art] [Last-Call] [regext] Artart last call review of draft-ietf-regext-epp-registry-maintenance-17 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 18:29:44 -0000 --_000_HE1PR07MB4217FC6A2336803938C9DDDC98B09HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Harald: thanks very much for the ART review. I have balloted DISCUSS while = waiting for v-18 of the draft addressing your comments. Authors: thank you for answering Harald=92s points. I=92m glad there has al= ready been resolution and I=92ll lift the DISCUSS once the update is publis= hed. Francesca From: last-call on behalf of Tobias Sattler Date: Monday, 13 September 2021 at 15:07 To: Harald Alvestrand Cc: Jody Kolker , art@ietf.org , draft-i= etf-regext-epp-registry-maintenance.all@ietf.org , regext@ietf.org , last-ca= ll@ietf.org Subject: Re: [Last-Call] [regext] Artart last call review of draft-ietf-reg= ext-epp-registry-maintenance-17 Hi Harald, Thank you for your swift feedback. We have incorporated the changes on our GitHub repository (https://github.c= om/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-regist= ry-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 > wrote: On 9/13/21 12:57 PM, Jody Kolker wrote: Thanks Harald for the detailed review of the document. Please see our comm= ents in line below. Thanks again! Jody Kolker -----Original Message----- From: Harald Alvestrand via Datatracker > Sent: Monday, September 13, 2021 3:14 AM To: art@ietf.org Cc: draft-ietf-regext-epp-registry-maintenance.all@ietf.org; last-call@ietf.org; regext@ietf.org Subject: Artart last call review of draft-ietf-regext-epp-registry-maintena= nce-17 Caution: This email is from an external sender. Please do not click links o= r 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 en= ough for interoperable implementation. There is also one confusing formatti= ng error that should be fixed before publication. Weak definitions: - "Maintenance event" is never defined. From context, it is possible to inf= er that a maintenance event refers to some service being partially or wholl= y unavailable in the time interval given; given that this is the whole poin= t 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. The= se updates are pushed to various registry environments during time frames t= hat are communicated to registrars as "maintenance events". Registries usu= ally inform registrars for maintenance events in various formats, none of w= hich =85.. 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 qui= te complex and not possible in all places - the text proposed seems to assu= me that all updates require maintenance events. " It should also be explicit that the service will be either fully and correc= tly available or not available at all, and that no harm (apart from being d= enied service) will come from trying to access the service in the maintenan= ce interval; "maintenance" that, for instance, puts a test database up wher= e 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, t= he registry should not be allowing registrars to connect to the system by t= aking a "full" maintenance. I don't believe we have ever experienced any m= aintenance 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 d= escribed. They may refer to having to reconnect the EPP service or to upgra= de the EPP schema in use, but since the "maint:name" element of "maint:syst= em" seems to encompass WHOIS and others, the actions that may be required are n= ot clear; an instruction to "do something connection-related" cannot be int= eroperably implemented. Suggestion: Either delete these elements or (if int= ended to be consumed by a human) add the option to add a text description o= f 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 explaini= ng actions the registrar will be effected by regarding the maintenance. Ad= ding a description to both of these elements seems to duplicate the informa= tion that should be in the maint:description element. We would like to sug= gest this edit to the document: From: The value SHALL be boolean and indicates if a client needs to do something that is connection-related, such as a reconnect. The value SHALL be boolean and indicates if a client needs to do something that is implementation-related, such as a code change. To: The value SHALL be boolean and indicates if a client needs to perform an action that is connection related, such as a reco= nnect. 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 element above. 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 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 outstand= ing maintenance events, with the value "create" returned the first time the= server tells the client about the event. This implies that the server is r= equired 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 in= tended, 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 t= ype of maintenance events. On reading RFC 5730, I see that the command has a queue of events th= at can be retrieved, which will then constitute the memory of what the clie= nt has received or not; if it's still in queue, it hasn't been received. An= d for this scheme to work at all, there has to be one distinct queue of not= ifications per client. In that context, the "pollType" sounds much more rea= sonable. Consider this comment dropped. Formatting issues: In the list of elements in section 3, the indentation of and the succeeding elements indicates that it is an element of . Examples indicate that it is an element of , 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-tim= e 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=3D"= 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 bei= ng boring and using "updateDate". << This document is following the same pattern used to signify the date the st= ate of a domain was updated, from RFC 5731, which we consi= dered 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 immed= iately following the introduction. However, we will update this document t= o 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 th= e document against common styles for EPP extensions. If comments touch on t= hings that are mandated by common EPP practices, feel free to consider thes= e comments overridden. Hope this is helpful. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext --_000_HE1PR07MB4217FC6A2336803938C9DDDC98B09HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Harald: t= hanks very much for the ART review. I have balloted DISCUSS while waiting f= or v-18 of the draft addressing your comments.

&nbs= p;

Authors: = thank you for answering Harald=92s points. I=92m glad there has already bee= n resolution and I=92ll lift the DISCUSS once the update is published.=

&nbs= p;

Francesca=

&nbs= p;

From: last-call <last-call-bounces@ietf.org= > on behalf of Tobias Sattler <mail@tobiassattler.com>
Date: Monday, 13 September 2021 at 15:07
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Jody Kolker <jkolker@godaddy.com>, art@ietf.org <art@ie= tf.org>, draft-ietf-regext-epp-registry-maintenance.all@ietf.org <dra= ft-ietf-regext-epp-registry-maintenance.all@ietf.org>, regext@ietf.org &= lt;regext@ietf.org>, last-call@ietf.org <last-call@ietf.org>
Subject: Re: [Last-Call] [regext] Artart last call review of draft-i= etf-regext-epp-registry-maintenance-17

Hi Harald,

 

Thank you for your swif= t feedback.

 

 

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 <harald@al= vestrand.no> wrote:

 


On 9/13/21 12:57 PM, Jody Kolker wrote:

Thanks Harald for the d= etailed review of the document.  Please see our comments in line below= .

Thanks again!
Jody Kolker

-----Original Message-----
From: Harald Alvestrand via Datatracker <noreply@ietf.org>
Sent: Monday, September 13, 2021 3:14 AM
To: art@ietf.org
Cc: draft-ietf-regext-epp-registry-maintenance.all@ietf.org; last-call@ietf.org; regext@ietf.org
Subject: Artart last call review of draft-ietf-regext-epp-registry-maintena= nce-17

Caution: This email is from an external sender. Please do not click links o= r 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 en= ough for interoperable implementation. There is also one confusing formatti= ng error that should be fixed before publication.

Weak definitions:

- "Maintenance event" is never defined. From context, it is possi= ble to infer that a maintenance event refers to some service being partiall= y 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. Introductio= n"

"Registries routinely update systems to ensure a higher quality of ser= vice, implement new services, or upgrade protocols to the newest standards.=  These updates are pushed to various registry environments during tim= e frames that are communicated to registrars as "maintenance events".  Registries usually inform registr= ars for maintenance events in various formats, none of which =85..


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 technolog= y, but quite complex and not possible in all places - the text proposed see= ms to assume that all updates require maintenance events.


"
It should also be explicit that the service will be either fully and correc= tly available or not available at all, and that no harm (apart from being d= enied service) will come from trying to access the service in the maintenan= ce interval; "maintenance" that, for instance, puts a test database up where the normal database is would b= e just a broken service, not "maintenance" in this sense. (If bro= ken 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 maintenanc= e events, the registry should not be allowing registrars to connect to the = system by taking a "full" maintenance.  I don't believe we h= ave ever experienced any maintenance event of the type described above.



I certainly hope not! Calling out that expectation may be good.


- "maint:connectio= n" and "maint:implementation" make very little sense as desc= ribed. 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 n= ot clear; an instruction to "do something connection-related" can= not 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 sh= ould review the maint:description element in the response for further detai= ls explaining actions the registrar will be effected by regarding the maint= enance.  Adding a description to both of these elements seems to duplicate the information that should be in the maint:de= scription 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
            rec= onnect.

         <maint:implementat= ion>
            The= value SHALL be boolean and indicates if a client needs
            to = do something that is implementation-related, such as a
            cod= e 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:implementat= ion>
            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 att= ribute 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 th= e 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 outstand= ing maintenance events, with the value "create" returned the firs= t time the server tells the client about the event. This implies that the server is required to keep state of what it h= as 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 n= ot 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 eve= nts that can be retrieved, which will then constitute the memory of what th= e client has received or not; if it's still in queue, it hasn't been receiv= ed. And for this scheme to work at all, there has to be one distinct queue of notifications per client. In that co= ntext, the "pollType" sounds much more reasonable.


Consider this comment dropped.



Formatting issues:

In the list of elements in section 3, the indentation of <maint:environm= ent> 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&= quot; and "Z"
characters defined in ISO 8601 [RFC3339] MUST be used to represent date-tim= e 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=3D"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 bei= ng boring and using "updateDate".

<<
This document is following the same pattern used to signify the date the st= ate of a domain was updated,  <domain:update> from RFC 5731, whi= ch we considered to be the standard to be followed.



Ack! Tradition rules.


Having migration consid= erations before item descriptions looks a bit weird when reading the docume= nt 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 immed= iately following the introduction.  However, we will update this docum= ent 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 th= e document against common styles for EPP extensions. If comments touch on t= hings that are mandated by common EPP practices, feel free to consider thes= e comments overridden.

Hope this is helpful.



_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

 

--_000_HE1PR07MB4217FC6A2336803938C9DDDC98B09HE1PR07MB4217eurp_--