[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