Re: [DNSOP] [Ext] Authoritative servers announcing capabilities

Patrick Mevzek <mevzek@uniregistry.com> Fri, 11 September 2020 23:44 UTC

Return-Path: <mevzek@uniregistry.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A8A3A09B0 for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 16:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniregistry.com
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 migGgB6zjUHa for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 16:44:25 -0700 (PDT)
Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B493A091F for <dnsop@ietf.org>; Fri, 11 Sep 2020 16:44:25 -0700 (PDT)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a-mx.uniregistry.com
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1599867865; bh=kwlU6aJH8Ifxi1UfD3eE6N4nZIOiNVOZLnH2yt0n8M8=; h=Subject:To:References:From:Date:In-Reply-To; b=nKkEc5U4kdqnvt0P6+Oe86AEJjKSAaQpx5RS5yVKWu4X4hU7DsRfp17rzaHq6JsQq k2whLMR0V9KmEv1jx9zg8G3e6ZN6jrbK4QAoMRyVINizSDmWWDp8dRNb+zYK3EAZqK 9J6+sFetJ+j1vJ0j/zOfDeaH4sjkvh46pX3HEvvDBA7wpxGvJi1L58ZTtQejGWmhwK xfB8KaerYwKBNYN9GTbzdGYJ8lTxOltGED5UrDq7hcsNGXVzb3qDsd/YMd6oLW+IaC sxNqnjfhT+hX4SGRRHp+Oz7WWYkASV6E+5A21O8m2hy+K6huBLV1SGXoQdeukyx5m2 n1oTn0A05W8dw==
Received: from [10.8.204.86] (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 08BNiNfa036030 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 11 Sep 2020 23:44:24 GMT
To: "dnsop@ietf.org" <dnsop@ietf.org>
References: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org> <294f8ab0-285b-d5f2-705f-5db8c0da584d@uniregistry.com> <815E7487-C48D-4120-AD22-C77D893EB6E7@icann.org>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <c2956819-cce4-4db9-c2e3-f4587c068677@uniregistry.com>
Date: Fri, 11 Sep 2020 18:44:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <815E7487-C48D-4120-AD22-C77D893EB6E7@icann.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CtsbtKrTuhTwHe0Z4hIIFUyoxHc>
Subject: Re: [DNSOP] [Ext] Authoritative servers announcing capabilities
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 23:44:27 -0000

On 11/09/2020 18:39, Paul Hoffman wrote:

>> Plus, why couldn't this be extended in the future to recursive nameservers as well? In which case, the name should be resolver genre agnostic.
> 
> There is already a draft for RESINFO. The difference is important, because a single host might be both a resolver and an authoritative server.

I don't believe two separate types are needed. As you return formatted 
data, information on the type (recursive vs authoritative) can certainly 
be in the data and there should probably be enough space in that data to 
store both cases, as needed.

>> Maybe something like "CAPABILITIES" or "ABILITIES"?
>> (or shorter version)
> 
> And you're thinking those aren't used in other protocols? :-)

The difference probably being on the fact that EPP is also very tied to 
the same area, aka domain names.
So the idea is not just to use a unique name across the whole word, but 
at least not a name already extensively used in another protocol in the 
same "world" of domain names.

That was just my suggestion (do not reuse authinfo name), feel free to 
ignore.

(but your email triggered that reflex in me as I have seen, in the realm 
of just EPP, so much abuse or misunderstanding of the authInfo term, 
that I wanted to convey the idea that even more confusion could be a curse).

-- 
Patrick Mevzek