Re: [DNSOP] [Ext] New Version Notification for draft-pp-additional-contents-00.txt

Paul Hoffman <paul.hoffman@icann.org> Wed, 16 June 2021 18:40 UTC

Return-Path: <paul.hoffman@icann.org>
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 AF8453A2259; Wed, 16 Jun 2021 11:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7wWZUSI1Q-EA; Wed, 16 Jun 2021 11:40:18 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 DFA313A2250; Wed, 16 Jun 2021 11:40:17 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa5.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 15GIeG1a016243 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 18:40:16 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Wed, 16 Jun 2021 11:40:15 -0700
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 mapi id 15.02.0858.012; Wed, 16 Jun 2021 11:40:15 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: DNSOP WG <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] New Version Notification for draft-pp-additional-contents-00.txt
Thread-Index: AQHXYtwCiLKMAL1n+kS9qwWyoIY/sasXbbiA
Date: Wed, 16 Jun 2021 18:40:15 +0000
Message-ID: <FA54A299-0D4A-48B2-AE9B-F43E7DC25E5F@icann.org>
References: <162386410269.20738.7972356629825313273@ietfa.amsl.com> <F2AC2969-74BF-452B-8C7A-31D786ED4EE0@icann.org> <CAHbrMsBL4uLbiqJW20sm4tu9oFca8p=ecA7oCdE7EbQM=O-WBw@mail.gmail.com> <9CA01848-10D5-464C-9EBA-0B7CCBF09FB5@icann.org> <CAHbrMsCg-FQ4ZMpHsLebOjrvyM9bjvCFaOP2RxvJYna7PCysHg@mail.gmail.com>
In-Reply-To: <CAHbrMsCg-FQ4ZMpHsLebOjrvyM9bjvCFaOP2RxvJYna7PCysHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_622A6D6D-28F7-4CAF-88B3-E7A9C2637213"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-16_11:2021-06-15, 2021-06-16 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ABjrH0kVp3eD2VGy9h74WuD6M0s>
Subject: Re: [DNSOP] [Ext] New Version Notification for draft-pp-additional-contents-00.txt
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: Wed, 16 Jun 2021 18:40:23 -0000

On Jun 16, 2021, at 11:17 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> OK, but this is bewildering in a different way.

Indeed. See the muddle about "glue" in RFC 8499.

> RFC 2181 is a Standards Track RFC that Updates RFC 1034, and whose title is "Clarifications to the DNS Specification".  In the event of conflict, it supersedes RFC 1034.  As a matter of process, the RFC 1034 definition would therefore seem to be irrelevant for determining the "correct" meaning.

This is an overinterpretation of "updates". An RFC can update another without updating every part of it. Note that RFC 2181 only defines "glue" for its own use "above"; it does not say that it updates the definition in RFC 1034.

> If I were arguing that the RFC 2181 definition is not "correct", I would be looking for an RFC that Updates RFC 2181 and has a different definition of glue.

Such as RFC 8499 (which is a standard), or this one (the, if adopted, is only informational).

>  The DNSSEC RFCs do Update RFC 2181, and appear to use a conflicting definition of glue, although it's not explicitly defined.

And those RFCs kinda conflict with each other on the use of the term "glue".

--Paul Hoffman