[regext] Roman Danyliw's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 06 October 2021 15:58 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 9630C3A1E7B; Wed, 6 Oct 2021 08:58:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-regext-epp-registry-maintenance@ietf.org, regext-chairs@ietf.org, regext@ietf.org, James Galvin <galvin@elistx.com>, galvin@elistx.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <163353588801.29502.15150455017019718859@ietfa.amsl.com>
Date: Wed, 06 Oct 2021 08:58:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/XwzEvRPffihG0Vkni7OVA9dhcow>
Subject: [regext] Roman Danyliw's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)
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 15:58:09 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-epp-registry-maintenance-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Melinda Shore for the SECDIR review.

** Section 7.

"If a client queries for a maintenance identifier, per Section 4.1.3.1 "Info
Maintenance Item", that it is not authorized to access, the server MUST return
an EPP error result code of 2201 [RFC5730]."

Should this be softened to give a server the flexibility to alternatively
return a 2303 error ("Object does not exist") so the existence of a maintenance
updates would remain unknown to unauthorized users? If not, this (likely minor)
risk of leaking the existence of maintenance windows should be noted.

** Section 7.  These could be read as conflicting.

(a) Section 7.  “a server MUST only provide maintenance information for clients
that are authorized.”

(b) Later in Section 7. “The list of top-level domains or registry
   zones returned in the "Info Maintenance Item" response SHOULD be
   filtered based on the top-level domains or registry zones the client
   is authorized.”

(a) seems to say that a client must only get the information for which it is
authorized, but (b) suggests that this filtering for those TLD/zones to
restrict it only to authorized clients is only a should.