Re: [dns-privacy] [IANA #1223683] Re: Last Call: <draft-ietf-dprive-dnsoquic-08.txt> (DNS over Dedicated QUIC Connections) to Proposed Standard

Christian Huitema <huitema@huitema.net> Tue, 25 January 2022 20:55 UTC

Return-Path: <huitema@huitema.net>
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 9E8963A11E7 for <dns-privacy@ietfa.amsl.com>; Tue, 25 Jan 2022 12:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 NbWFnPYCQX7b for <dns-privacy@ietfa.amsl.com>; Tue, 25 Jan 2022 12:54:56 -0800 (PST)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 EC1C93A11DF for <dns-privacy@ietf.org>; Tue, 25 Jan 2022 12:54:55 -0800 (PST)
Received: from xse357.mail2web.com ([66.113.197.103] helo=xse.mail2web.com) by mx257.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nCSq3-000CXl-M4 for dns-privacy@ietf.org; Tue, 25 Jan 2022 21:54:54 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Jjzcl3RNRzD6y for <dns-privacy@ietf.org>; Tue, 25 Jan 2022 12:54:47 -0800 (PST)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nCSpz-0003SI-Ai for dns-privacy@ietf.org; Tue, 25 Jan 2022 12:54:47 -0800
Received: (qmail 20684 invoked from network); 25 Jan 2022 20:54:46 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.84]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <drafts-lastcall@iana.org>; 25 Jan 2022 20:54:46 -0000
Content-Type: multipart/alternative; boundary="------------0F7k7NM4HYx1hs01dABabZ40"
Message-ID: <933d72b0-7534-a881-60f4-2448f40aeacc@huitema.net>
Date: Tue, 25 Jan 2022 10:54:43 -1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: drafts-lastcall@iana.org
Cc: tjw.ietf@gmail.com, brian@innovationslab.net, allison.mankin@gmail.com, iesg@ietf.org, ek.ietf@gmail.com, sara@sinodun.com, evyncke@cisco.com, dns-privacy@ietf.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>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <rt-4.4.3-20370-1643139413-1317.1223683-37-0@icann.org>
X-Originating-IP: 66.113.197.103
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.07)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8Nq4YiBzKxm928EqzSylb5PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zh2yKlFwkOJL4c32G0KduLVjVx0XVkNnHJMw/amoreOSvB nHFO2C20Agb2jY8TN+tJAk4iob8pbYggfh1IwcPnSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVJ8TNu1MO4d8w7zaGH0oFjpotTbzF8bFslzcWfB/84WWaVarp Z0LfU2AP/MzLXlymkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7IBAaAB9SiL80iwHtGBZiikgJ7Yk+SWN8eNDNBlkTeVa3c gpg4z70adpZiaIYxTq1QKK8qgoX3qtqBY7olcAAV8nYUYKqwGwZHdaZ8HwmXaEfTulJRptMnEIdG JW7dfhGq92PNDpgLsd6Ddd/s7VM53oX5hViH4Jz48tESKhglYCwOtp+q3yU+z72+fnpodgpD2SDa Ef8MNkdMMTfysCWr5YmHWIdtTprI+x4E6oFF2rtmMRr+w2X69ygMahiTQMBdjQbZ0192x/fWVCVp eDmdV/oPFZIShBSdpVJW5HbjQTCUIzbw71BPKv8cPtVshTSLr6YHJu91A3avrF49rf9JcoEpejCA XczArXyV+OFXiMtbLPp9n350Mbemie5JWWm/MpxAyl4q1x5O0+PBD/gPmWjXVA9S7TnWXDlmMpVd cwCFwrnT0GQK/7labXRdXAB+MS+4ayUpOtEhdxekWDmK9g==
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/8zhl18dw0o2az33OP0YhN1bPOcQ>
Subject: Re: [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
Precedence: list
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 20:55:01 -0000

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