[regext] Opsdir telechat review of draft-ietf-regext-epp-registry-maintenance-17

Joe Clarke via Datatracker <noreply@ietf.org> Wed, 06 October 2021 19:29 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 762703A0839; Wed, 6 Oct 2021 12:29:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-regext-epp-registry-maintenance.all@ietf.org, last-call@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163354856438.11198.16545686382778306553@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Wed, 06 Oct 2021 12:29:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/1hbT8GXQ3HDFuKYLqyDgjSukFzo>
Subject: [regext] Opsdir telechat review of draft-ietf-regext-epp-registry-maintenance-17
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2021 19:29:25 -0000

Reviewer: Joe Clarke
Review result: Has Nits

I have been tasked to review this document on behalf of the OPS Area
Directorate.  This document describes an EPP extension for conveying
maintenance events to EPP clients.  Overall, I find the document mostly ready,
but I do have a few questions, and I found a few typos.

===

Section 3.3

What is the use case for having <maint:start> be equal to <maint:end>?  I would
think you'd always want the end time to be in the future to be a relevant
maintenance event.

===

Section 3.3

s/negotiated value is something other then the/negotiated value is something
other than the/

===

Section 3.3

If one of the intervention elements is true, how does one find out the details
of the connection or implementation-related intervention?  I imagine the URI
would provide that, but I was expecting to see it stated in this document in
the description of these elements.

===

Section 4.1.4

s/command and response is defined/command and response are defined/