[dns-privacy] [IANA #1223683] Re: Last Call: <draft-ietf-dprive-dnsoquic-08.txt> (DNS over Dedicated QUIC Connections) to Proposed Standard
Sabrina Tanamal via RT <drafts-lastcall@iana.org> Tue, 25 January 2022 22:58 UTC
Return-Path: <iana-shared@icann.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249D83A144B for <dns-privacy@ietfa.amsl.com>; Tue, 25 Jan 2022 14:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.625
X-Spam-Level:
X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L3=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 P2GZ5u7TND4Y for <dns-privacy@ietfa.amsl.com>; Tue, 25 Jan 2022 14:58:14 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (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 DCBC73A1449 for <dns-privacy@ietf.org>; Tue, 25 Jan 2022 14:58:14 -0800 (PST)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 75E4CE087A; Tue, 25 Jan 2022 22:58:14 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 6F93820735; Tue, 25 Jan 2022 22:58:14 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: Sabrina Tanamal via RT <drafts-lastcall@iana.org>
Reply-To: drafts-lastcall@iana.org
In-Reply-To: <rt-4.4.3-20370-1643144117-1150.1223683-37-0@icann.org>
References: <RT-Ticket-1223683@icann.org> <RT-Ticket-1221797@icann.org> <164191280859.637.2764847661326111244@ietfa.amsl.com> <rt-4.4.3-12032-1643049551-886.1221797-37-0@icann.org> <ce1e3553-7420-6a1a-05b1-950b734fef85@huitema.net> <rt-4.4.3-20370-1643139413-1317.1223683-37-0@icann.org> <933d72b0-7534-a881-60f4-2448f40aeacc@huitema.net> <rt-4.4.3-20370-1643144117-1150.1223683-37-0@icann.org>
Message-ID: <rt-4.4.3-20371-1643151494-1193.1223683-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1223683
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
CC: huitema@huitema.net, tjw.ietf@gmail.com, sara@sinodun.com, evyncke@cisco.com, ek.ietf@gmail.com, dns-privacy@ietf.org, brian@innovationslab.net, allison.mankin@gmail.com
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Tue, 25 Jan 2022 22:58:14 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/3v7_SLEJPSFWUcBStsrLM8EdtzU>
Subject: [dns-privacy] [IANA #1223683] Re: Last Call: <draft-ietf-dprive-dnsoquic-08.txt> (DNS over Dedicated QUIC Connections) to Proposed Standard
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2022 22:58:19 -0000
Hi Christian, These changes look good. Thank you! Best regards, Sabrina Tanamal Lead IANA Services Specialist On Tue Jan 25 20:55:17 2022, huitema@huitema.net wrote: > Hello Sabrina, > > Yes, reading the section 10.2 again, I see that there is some leftover > text from previous iterations, and it creates confusion. I just > proposed > a set of changes on our github repo -- > https://github.com/huitema/dnsoquic/pull/140. The changes affet > section > 10.2 as follow: > > 1) Remove the line "IANA responded to the early allocation request > with > the following TEMPORARY assignment:", since IANA did not do anything > like that. > > 2) Remove the line "The TEMPORARY assignment expires 13th December > 2022." There is no such temporary assignment. > > 3) Delete section 10.2.1, which was already slated for removal. This > removes the confusing references to port number 784. > > Would that address your concerns? > > -- Christian Huitema > > > On 1/25/2022 9:36 AM, Sabrina Tanamal via RT wrote: > > Hi Christian, > > > > See [ST] below. > > > > On Tue Jan 25 02:04:28 2022,huitema@huitema.net wrote: > >> On 1/24/2022 8:39 AM, Sabrina Tanamal via RT wrote: > >>> (BEGIN IANA COMMENTS) > >>> > >>> IESG/Authors/WG Chairs: > >>> > >>> The IANA Functions Operator has completed its review of draft-ietf- > >>> dprive-dnsoquic-08. If any part of this review is inaccurate, > >>> please > >>> let us know. > >>> > >>> The IANA Functions Operator has a question about one of the actions > >>> requested in the IANA Considerations section of this document. > >>> > >>> The IANA Functions Operator understands that, upon approval of this > >>> document, there are four actions which we must complete. > >>> > >>> First, in the TLS Application-Layer Protocol Negotiation (ALPN) > >>> Protocol IDs registry on the Transport Layer Security (TLS) > >>> Extensions registry page located at: > >>> > >>> https://www.iana.org/assignments/tls-extensiontype-values/ > >> The registry is located at: > >> https://www.iana.org/assignments/tls-extensiontype-values/tls- > >> extensiontype-values.xhtml#alpn-protocol-ids. > >> > >> That registry is under the title "TLS Application-Layer Protocol > >> Negotiation (ALPN) Protocol IDs" > >> > >>> a new registration is to be made as follows: > >>> > >>> Protocol: DoQ > >>> Identification Sequence: 0x64 0x6F 0x71 ("doq") > >>> Reference: [ RFC-to-be ] > >>> > >>> As this document requests registrations in an Expert Review (see > >>> RFC > >>> 8126) registry, we will initiate the required Expert Review via a > >>> separate request. This review must be completed before the > >>> document's > >>> IANA state can be changed to "IANA OK." > >>> > >>> Second, we will update the description and list this document as an > >>> additional reference for UDP port 853: > >>> > >>> Service Name: domain-s > >>> Port Number: 853 > >>> Transport Protocol(s): UDP > >>> Assignee: IETF DPRIVE Chairs > >>> Contact: Brian Haberman > >>> Description: DNS query-response protocol run over DTLS or QUIC > >>> Reference: [RFC7858][RFC8094] This document > >>> > >>> In addition, the Description field for the corresponding TCP port > >>> 853 > >>> allocation will be changed to 'DNS query-response protocol run over > >>> TLS'. > >>> > >>> IANA Question: We understand from Section 8.1.1 of RFC 6335 that > >>> the > >>> IESG should be listed as the assignee and the IETF Chair as the > >>> contact for an IETF-stream document. Can you confirm that this is > >>> correct? > >> Yes. > >>> IANA Question: Since we didn't make a temporary early allocation > >>> request for the above port, can the early allocation language be > >>> removed from the document? We will make the changes as agreed with > >>> the port experts when the document is approved for publication. > >> Please explain what you mean by "the early allocation language." > > [ST] Section 10.2 says, “IANA responded to the early allocation > > request with the following TEMPORARY assignment:” and states that the > > allocation expires on 13 December 2022. However, on 13 December 2021, > > the determination by the port experts was that the existing port > > would be modified when the document was approved for publication, not > > that an early allocation or modification would be made. Can this > > section be rewritten to reflect that a modification is being > > requested by the document? > > > >>> IANA notes that section 10.2.1 contains notes for implementer of > >>> early experiments and no instructions for IANA. > >> Section 10.2.1. should be removed once the allocation is done. The > >> text > >> says "(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE > >> PUBLICATION)". > >> It might have been better to describe an IANA action rather than at > >> RFC > >> EDITOR action, but the intent is clear. > > [ST] If a port allocation is required here, please clarify what the > > IANA actions should be. > > > > Thank you, > > > > Sabrina Tanamal > > Lead IANA Services Specialist > > > >>> Third, in the Extended DNS Error Codes registry on the Domain Name > >>> System (DNS) Parameters registry page located at: > >>> > >>> https://www.iana.org/assignments/dns-parameters/ > >>> > >>> a new registration will be made as follows: > >>> > >>> INFO-CODE: [ TBD-at-Registration ] > >>> Purpose: Too Early > >>> Reference: [ RFC-to-be ] > >> Yes. > >>> Fourth, a new registry is to be created called the DNS over QUIC > >>> Error Codes registry. The new registry will be located on the > >>> Domain > >>> Name System (DNS) Parameters registry page located at: > >>> > >>> https://www.iana.org/assignments/dns-parameters/ > >>> > >>> The registration rules for the new registry are: > >>> > >>> 0x00 - 0x3f require Standards Action or IESG Approval > >>> > >>> Permanent registrations for values larger than 0x3f, which are > >>> assigned using the Specification Required policy (as defined in > >>> [RFC8126]) > >>> > >>> Provisional registrations for values larger than 0x3f, which > >>> require > >>> Expert Review, as defined in Section 4.5 of [RFC8126]. > >>> > >>> There are initial registrations in the new registry as follows: > >>> > >>> +==========+=======================+================+============================+ > >>> |Value | Error |Description | Specification | > >>> +==========+=======================+================+============================+ > >>> |0x0 | DOQ_NO_ERROR |No error | [ RFC-to-be; Section 5.3 ] | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> |0x1 | DOQ_INTERNAL_ERROR |Implementation | [ RFC-to-be; Section > >>> 5.3 > >>> ] | > >>> | | |error | | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> |0x2 | DOQ_PROTOCOL_ERROR |Generic protocol| [ RFC-to-be; Section > >>> 5.3 > >>> ] | > >>> | | |violation | | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> |0x3 | DOQ_REQUEST_CANCELLED |Request | [ RFC-to-be; Section 5.3 ] > >>> | > >>> | | |cancelled by | | > >>> | | |client | | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> |0x4 | DOQ_EXCESSIVE_LOAD |Closing a | [ RFC-to-be; Section 5.3 ] | > >>> | | |connection for | | > >>> | | |excessive load | | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> |0xd098ea5e| DOQ_ERROR_RESERVED |Alternative | [ RFC-to-be; Section > >>> 5.3 ] | > >>> | | |error code used | | > >>> | | |for tests | | > >>> +----------+-----------------------+---------------- > >>> +----------------------------+ > >>> > >>> The IANA Functions Operator understands that these are the only > >>> actions required to be completed upon approval of this document. > >> Yes. > >>> Note: The actions requested in this document will not be completed > >>> until the document has been approved for publication as an RFC. > >>> This > >>> message is meant only to confirm the list of actions that will be > >>> performed. > >>> > >>> Thank you, > >>> > >>> Sabrina Tanamal > >>> Lead IANA Services Specialist > >>> > >>> (END IANA COMMENTS) > >> Thank you! > >> > >> -- Christian Huitema > > _______________________________________________ > > dns-privacy mailing list > > dns-privacy@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-privacy
- [dns-privacy] [IANA #1221797] Last Call: <draft-i… Sabrina Tanamal via RT
- Re: [dns-privacy] [IANA #1221797] Last Call: <dra… Christian Huitema
- [dns-privacy] [IANA #1223683] Re: Last Call: <dra… Sabrina Tanamal via RT
- Re: [dns-privacy] [IANA #1223683] Re: Last Call: … Christian Huitema
- [dns-privacy] [IANA #1223683] Re: Last Call: <dra… Sabrina Tanamal via RT
- Re: [dns-privacy] [IANA #1223683] Last Call: <dra… Sara Dickinson