Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces

"Patrick Mevzek" <pm@dotandco.com> Tue, 28 January 2020 17:13 UTC

Return-Path: <pm@dotandco.com>
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 025B7120018 for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 09:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=BaEC5YBA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qq/TeF3M
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OvcKiF1IC7j for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 09:13:25 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A89012002E for <regext@ietf.org>; Tue, 28 Jan 2020 09:13:25 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 657F021FE5 for <regext@ietf.org>; Tue, 28 Jan 2020 12:13:24 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Tue, 28 Jan 2020 12:13:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=oh0mDuBKO4OTxhUfhAiYiJqcNqRY487 cp1hYaK//Eng=; b=BaEC5YBAy3bmLSr2wrU17hlDwyZ7AynN1PoWfCv+Ub2/dqJ YFpQe3HMskAat4pzkBZl1Cbw064CZAFiGMMTcWh7Gok/u0Wo/tknLhArMCjL5yoG RvDzR+LbuUeY2c6LXLdG9J17pSS26809FBs3SHYnm0lN1t0+sO+mAdSnCKYDeigj W1mEAwAvK5o8bDPjCEQxxBOgIwTgMdTqIVGrNYgJWg1uTY1HxXhvqC/3BEgcYnB1 cNCQ2wy2A9N6FqqtkTRMTY8Bwp8y2Zh+EGoazhb7ikX4Mv4OqPnjn44kzHEixAA9 zHzDe1G0GNKInBNDcNTIR1ANdklf3QXIeWFBOXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=oh0mDu BKO4OTxhUfhAiYiJqcNqRY487cp1hYaK//Eng=; b=Qq/TeF3MCg0a4AgpPr3se2 JDTvcU0GandwJPbBCiaSLqUepFDRRUDl6dEDoldixXF39mb5FnAMybcTQ7v7wWLR w0K5qKF1BRvsrEWYtR2feN0cK4smrdi0wcZdDsQRUBzhh6zL4ksuBv++PEbPuBxB +k6t7p98DniMb+WOvrh7naryG396FK693Yx6CrwOVhv7iXmI1lcM0FQnTUfopXIY uk0uTtxcjMGNBzbf54aYNhvtGItwH4C8AhzfN9EIW8hc0u3qXiBT8e4MCMqCt1N3 6urNsA1qoLCdKEqRI2lvvV/HxQLcZxT8s+ZAGDThaj7pXYEyAw6w6MStj/1bEwkg ==
X-ME-Sender: <xms:s2swXkEl1u4mpPYl6GKefPgR0QiRArvEEATMkLxqgkOcUpaN1oysiBXE3FQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeeggdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmseguohht rghnuggtohdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutgho rdgtohhm
X-ME-Proxy: <xmx:s2swXvNjf2TnnzpB3U7I-thYB4q9ouARJQqDs0ku8JbHeBqqXdon1A> <xmx:s2swXtyuq9Uv6nPngHj-647N86nFsnTXGSCg2yMqquru6RdgMCyjLw> <xmx:s2swXi21wZPQnb_yTqFIAiMoFrIAIr17xDsa1KxrVgNqXOMFYGmhqg> <xmx:tGswXi_qfbDp9Zh5tL3FMunjIlD5UgZFkfaz_2OcINPwHi29cI4rkg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D94E7C200A4; Tue, 28 Jan 2020 12:13:23 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-781-gfc16016-fmstable-20200127v1
Mime-Version: 1.0
Message-Id: <27f5f218-74ed-4082-aea5-ea7775a80ea4@www.fastmail.com>
In-Reply-To: <BD597A01-7394-4FA7-B6E6-24DEEC56DE70@verisign.com>
References: <7498F6EF-3BDD-4FEE-B30E-53BDCB3B9B8D@antoin.nl> <94998f24-4736-47f9-9da7-d0653d1f0676@www.fastmail.com> <BD597A01-7394-4FA7-B6E6-24DEEC56DE70@verisign.com>
Date: Tue, 28 Jan 2020 12:13:03 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Qfm4jqz7JPx08A-schYLwMeajQg>
Subject: Re: [regext] =?utf-8?q?CALL_FOR_ADOPTION=3A_draft-gould-casanova-reg?= =?utf-8?q?ext-unhandled-namespaces?=
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 28 Jan 2020 17:13:27 -0000

On Tue, Jan 28, 2020, at 11:51, Gould, James wrote:
> JG - This topic came up with the introduction of a new poll message 
> with the Change Poll Message in https://tools.ietf.org/html/rfc8590.  

But the problem existed far before it (and it didn't bother, for
good or bad reasons)

One case among others (putting aside the problem of transfers for domains with attached DNSSEC configuration):

- registrarA has domainX with secDNS data
- registrarB transfers the domain; registrarB login to EPP server DOES NOT include
secDNS-1.1 as it is optional
- registrarB does a domain:info, now what to expect in reply?
Should it include the secDNS part or not?
This is the whole debate, and the problem is not trivial.
Notifications are just a specific case among the whole problem
(which is truly more just about feature negotiation at session beginning).

Notifications are asynchronous. They can be produced at time T1 where
registrar was having an EPP session where extension X1 was negotiated, but
the message can be retrieved far later, at time T2, where registrar has
another EPP session where that extension was not used. Now, the notification
needs to be processed in some way because it blocks all the queue
otherwise.

> It's primarily an issue associated with the poll queue, where it's 
> unclear how the server can introduce a new poll message without 
> breaking the protocol.

The problem is ABSOLUTELY NOT just tied to poll messages. I would prefer
all parts of the problem to be addressed, OR at the very least if not
possible then the document clearly mentioning it deals only with part
of the problem and leaves the rest for sometimes later/somewhere else.
But in my mind that lowers its usefulness.

>     However, as discussed previously, in its current form this draft 
> will
>     introduce interoperability problems[1], so this just exchanges one 
> problem with another.
>     
>     So I am mildly convinced work is required, and mildly unconvinced that
>     the draft as it stands completely address the issue.
>     
>     [1] TL;DR: a registrar has no way to automatically discover
>     a registry is using the mechanism outlined in this document,
>     as not announced in the greeting part.
> 
> JG - draft-gould-casanova-regext-unhandled-namespaces addresses a 
> protocol and subsequently an interoperability issue,

(that no one took care to document or even raise on the mailing list
for like 16 years...)

> since the server 
> will be capable of fully honoring the services the client includes in 
> the login command.  I'm not sure how a practice that fully follows the 
> EPP RFCs and fully honors the client login services will introduce an 
> interoperability problem based on the lack of discoverability of the 
> practice in the greeting.  

Again: because the client has no way to know if the registry it is talking
to right now, implements this "extension" or not. So it has no way of knowing
what to do with the <extValue> it gets (if it should start to parse them,
if it should start to be worried to get extValue content when it didn't have
any in the "past", etc.)
(and no, parsing of "reason" node does not count as discoverability)
And clients, are clients to multiple registries. They have to accommodate all
of them, even if they do their internal hall of fame/shame based on their
preferences, they still have to accommodate if they want to do business...

I am sure you can imagine that not all registries will implement it even
if it becomes a full fledged RFC, so
registrars have to discriminate. If they can not, they have to do heuristics.
This makes the current situation more fragile, and hence poses an interoperability
problem (and will, in my view, lessen the probability that many registries
will implement it, feeling that the status quo - again not worrisome enough
for 16 years for anyone to work on that before - while not perfect is certainly
good enough and not worse than what is proposed in the draft).

If you say: big deal, registrars can just ignore the <extValue> content in that case
then: why even bothering sending it?

I will leave it at that for now, and see further discussions if the
draft is adopted by the working group.

-- 
  Patrick Mevzek
  pm@dotandco.com