Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Patrick Mevzek <> Mon, 02 November 2020 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A093D3A0AC6 for <>; Mon, 2 Nov 2020 08:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=fO3T2twH; dkim=pass (2048-bit key) header.b=L9prCDgW
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FJg-l4Kcdx0s for <>; Mon, 2 Nov 2020 08:09:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C870D3A0982 for <>; Mon, 2 Nov 2020 08:09:23 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id D607D5C0219 for <>; Mon, 2 Nov 2020 11:09:22 -0500 (EST)
Received: from imap22 ([]) by compute3.internal (MEProxy); Mon, 02 Nov 2020 11:09:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=5lm7aZoebiZKvuMpUj1m2Wu/vD60qM+ 7iDqRYSv2o0I=; b=fO3T2twHHhD3rH/N7BwinY9w9XMVU5knZ4GbnYI8ebPon6Z U2b0OZw5TGmkQLs2RWrY6eHkO6+uBcX2ac2oV4QUqB7fz/EC0kO9b+Oq/d/DNWY8 +4eTQ1mp80qWOOgO18xhNrscfdGnuS+BsIEtE8E5K/B+Z3JIM/BRwS6jJd2aeReX VQ0PziTA51/QksV+0/t79jsKTcJlPG+hzwzO5+ehPB9tm3BUliLcb08x2pC/q9/e Fe0Fg5Coz3t6nioF6gqoE9mxhwsplCxfYXsSGIcA1gWWUP7AoADLMiqU5Fu7m+45 R+WzXxlE+XoeQg4oKVqPLHEGKhApuB+1/5Gu4fA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=5lm7aZ oebiZKvuMpUj1m2Wu/vD60qM+7iDqRYSv2o0I=; b=L9prCDgWdJRsVa8xH9Zqrx qXusPPj8G2IJ0Qq2vRpMzhmrUcwyBAG0rEV8PA1VkeiN8DF6Wz2+5fjEa+ymky5N f2B5shgglB8D7hSqvx0gK1SJfPcI5u0J+QcNO3SdbhAffCMLl8G5pggn42xhT/to kklUnTkHYnWAQgitJ4IGLv+kDlonx0HAujwsbcScSoK14CamWZVHoxKaMvIaSlhl TOT3YrHT/f64ir6e37WW8kg3+b4mZbC0EqfvGqucMpOc6VLwTRYrizsiJYHcneCW uNk+mGXY73NVT96SAiDks2DYtLBx62QIEgT3q1rtKSuqBNlr0LD0BY0ICsadfH/g ==
X-ME-Sender: <xms:MS-gXwKfPuR_bm3nduf59jrm-e2awAqOGAisWZQx_NnIEwPo5Ws4thuGf_4> <xme:MS-gXwKcUwskV9eVmGFCoHTEkrRdGGtMA5pUSStSgG8-FoeTEWhJpbIMu684S04zn Ud6HcFC8SdTEKVRuA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtuddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:Mi-gXwuR-3VmKkylUtP9oCJhE5vhM94MV3Uhu1cXCNEvaKhuQrc6Fw> <xmx:Mi-gX9YPdMV8iYxn1QptgvFSbHMjD5FEVhaKcvtFTntqQl2Cd6Mu2A> <xmx:Mi-gX3bGMMLx1jX5Eg26FmGDRcgz_7amZJ-204V6HHATUkmqOQtG3g> <xmx:Mi-gXwkobxYw_gUnuKhtXK7S55B_7NWLv3k9lS8yGffqhQqFyCtX3g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 992216680073; Mon, 2 Nov 2020 11:09:21 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Mon, 02 Nov 2020 11:09:01 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2020 16:09:27 -0000

On Mon, Nov 2, 2020, at 10:42, Gould, James wrote:
> Do you mean it's better to fail the login if the client doesn't support 
> all of the possible EPP extensions supported by the poll queue?

Between this and the specification as currently presented, I prefer the login failure,

No option is perfect, each is a compromise.

> I view that option as being highly impactful to the clients

If a sudden change by a registry, without formal agreement by the registrar at login,
start to make it not follow RFC 5730 anymore, I think this is also very impactful to
the clients.

> and provides the 
> extension to the client in a protocol compliant manner for later 
> processing if desired.  

I disagree with the "protocol compliant manner". You redefine RFC 5730 at least twice.

> There has been no indication from the working group of a technical risk 
> with implementing draft-ietf-regext-unhandled-namespaces. 

This is incorrect. I indicated 2 points where the draft redefines what is in
RFC 5730.
This is a technical risk.

As any risk, no matter how big it can be, one has of course to judge the probability
of it happening, and the consequences if it happens. Based on that, the risk
can be considered "not worth to address". It doesn't mean it doesn't exist
or can't come back later under different circumstances, just that based on
current circumstances the probability or the consequences are considered
low/small enough that one decides to just go over that risk.

It may not happen, or not happen yet, from one registry reporting on the list
(thanks Mario for the data), but the fact that it was not seen does not mean
the risk does not exist.

I guess we will see later, when/if the extension gets deployed by other registries.

>I agreed to add text to explicitly state that draft-ietf-regext-unhandled-namespaces extends the use of the <extValue> element within section 3 "Use of EPP <extValue> for Unhandled Namespace Data", and to add an Implementation Considerations section to cover the recommendation of client and server monitoring to mitigate a client ignoring content returned by the server.

Thanks for that, could help... those reading this specification.
Now take into account anyone having written an EPP client in the past, based
on the specifications in the past, so RFC 5730 and siblings, and not aware AT ALL
of your new specification. You may see it should be announced in advance by registries,
but in practice that does not happen always (changePoll was introduced by some for example
without notifications), and even so, it can still happen some people won't be aware
of the change.
That is exactly the risk, because the change is not 100% aligned with what was
in past specifications.

As I said already I don't think there is pretty much anything else/again to discuss.
The consensus is clear considering the silent majority, so the process part has been
covered, let's go forward.

  Patrick Mevzek