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

Wes Hardaker <wjhns1@hardakers.net> Thu, 10 October 2024 16:48 UTC

Return-Path: <wjhns1@hardakers.net>
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 8EE31C14F614; Thu, 10 Oct 2024 09:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.62
X-Spam-Level:
X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_C=1.486, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 nQYbWhsS8lmm; Thu, 10 Oct 2024 09:47:58 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA69C14F5F8; Thu, 10 Oct 2024 09:47:58 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 916A522C9E; Thu, 10 Oct 2024 09:47:57 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 916A522C9E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1728578877; bh=orilW3BeTzq/Uuz1XqqP0xmwIS8e+fJHbAdq0jUTwXM=; h=From:To:Cc:Subject:Date:From; b=DRjkP7OtNmEULCxjsrmr3O274MIcj9W7WFQAqdbTtMcJW4Mpj1SJUhSqLh0SHJEbo 5CWl7Vt7VoIT4VwvLrKoYagJo49Bwu0BmdBvoyAIE2kfbWukSMCa+vr24IbaciFzI2 iZAKp6NkUDq7Pn1WVMWufQHKM/EPdF10EJkvPKFM=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Gavin Brown <gavin.brown@icann.org>, Orie Steele <orie@transmute.industries>
Date: Thu, 10 Oct 2024 09:47:57 -0700
Message-ID: <ybl7cafucoy.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: QBDBFRXJPNSZ43NHP5BPOMWBZUFGQ5J6
X-Message-ID-Hash: QBDBFRXJPNSZ43NHP5BPOMWBZUFGQ5J6
X-MailFrom: wjhns1@hardakers.net
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: Wes Hardaker <wjhns1@hardakers.net>, "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/3EPSxPl9bHO6_gbx-CV1EAAiZrI>
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>

Apologies for the delay in responding Gavin, I was sure I had already
sent this (but have been proven very wrong):

> That was not discussed explicitly. The document describes a policy
> discovery mechanism (see Section 2.1.1.2) which allows clients to learnt
> the min/default/max values, but it does not provide a way to discover
> if/when a server might reset a non-default value.
>
> EPP would not be particularly well-suited to provide this information, as
> the audience for such information would be much wider than just EPP client
> operators. However, the RDAP extension (see draft-brown-rdap-ttl-extension,
> which I plan to bring to regext once this document is published) does
> provide a way for a registry to publish its policy in a way that is
> discoverable for all interested parties, not just those who can connect to
> its EPP server.

I suspect that's the best you're going to do, yes.  I do think it would
be important for some sort of policy to be published to avoid surprises,
but I understand (and agree) that EPP may not be the right place to
return policy statements.

> 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."

I think the rest of the discussion is resolved, so I won't re-quote that here.
-- 
Wes Hardaker
USC/ISI