[regext] Re: [Ext] Secdir last call review of draft-ietf-regext-epp-ttl-15

Gavin Brown <gavin.brown@icann.org> Fri, 11 October 2024 09:48 UTC

Return-Path: <gavin.brown@icann.org>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D15C14F6EF; Fri, 11 Oct 2024 02:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5qfx0QdbZKW; Fri, 11 Oct 2024 02:48:27 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) by ietfa.amsl.com (Postfix) with ESMTP id 67EC1C14F6AF; Fri, 11 Oct 2024 02:48:27 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 49B9mPW4020262 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2024 09:48:26 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 11 Oct 2024 02:48:24 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1544.011; Fri, 11 Oct 2024 02:48:24 -0700
From: Gavin Brown <gavin.brown@icann.org>
To: Wes Hardaker <wjhns1@hardakers.net>
Thread-Topic: [regext] [Ext] Secdir last call review of draft-ietf-regext-epp-ttl-15
Thread-Index: AQHbG8K2baIHHC1OM0CZEDtVCWa2ZA==
Date: Fri, 11 Oct 2024 09:48:24 +0000
Message-ID: <AAAEA0C2-61B6-4A5D-930E-66FC54376E77@icann.org>
References: <ybl7cafucoy.fsf@wd.hardakers.net>
In-Reply-To: <ybl7cafucoy.fsf@wd.hardakers.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.47.235]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7E71704EAFFC3C4D9D36E319F7267CF6@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-11_07,2024-10-11_01,2024-09-30_01
Message-ID-Hash: TSZKTLVJET3BS563NYHTEIQ3FCWMQJ3Z
X-Message-ID-Hash: TSZKTLVJET3BS563NYHTEIQ3FCWMQJ3Z
X-MailFrom: gavin.brown@icann.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Orie Steele <orie@transmute.industries>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-regext-epp-ttl.all@ietf.org" <draft-ietf-regext-epp-ttl.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "regext@ietf.org" <regext@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [regext] Re: [Ext] Secdir last call review of draft-ietf-regext-epp-ttl-15
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/JWi4izavO7a-f7awtzNLOUUE22U>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

Hi Wes,

>> Policy changes will almost certainly only happen infrequently, and the
>> omission was intentional on my point. Do you feel it warrants some
>> discussion in the document?
> 
> I think inserting a warning note would be helpful to the reader.
> Something along the lines of "Although a client is requesting a
> particular TTL value that is within the current acceptable range,
> registries are not obligated to maintain that value indefinitely and may
> change the value when, for example, they update their acceptable TTL
> value ranges."

In my working draft[1] I have added a new Section 5.3, which says:

"Registry operators may change their policies relating to TTL values from time to time. Previously configured TTL values may consequently fall outside a newly-applied policy. This document places no obligation on EPP server operators in respect of these values, and server operators may, as part of a policy change, change the TTL values specified by clients for domain and host objects. Section 4 describes how such out-of-band changes should be carried out."

Let me know what you think. If it looks good I can upload a new version.

G.

[1] https://github.com/gbxyz/epp-ttl-extension/commit/b8bf5d56779fb5a0123401558fd6cab654348c85#diff-e81d8d738f47db9115098e0fe66a7a9904ca10821206e12ff5229e5e384b648cR577

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org