Hi Christian, 

These changes look good. Thank you!

Best regards, 

Sabrina Tanamal
Lead IANA Services Specialist

On Tue Jan 25 20:55:17 2022, [email protected] 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,[email protected]  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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dns-privacy

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to