DNS Multiple QTYPEs
draft-ietf-dnssd-multi-qtypes-14

[Ballot comment]
Hi Ray, all,

Thank you for the discussion and changes made in [1]. These looks good to me and addresses comments in my previous ballot [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnssd-multi-qtypes-12&url2=draft-ietf-dnssd-multi-qtypes-14&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/dnssd/HauqxyB_GbDcUXUUTMP1JR4L6BA/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnssd-multi-qtypes-12. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the DNS EDNS0 Option Codes (OPT) registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

two existing registrations will have their references updated to [ RFC-to-be ] as follows:

Value: 20
Name: MQTYPE-Query
Status: Optional
Reference: [ RFC-to-be ]

Value: 21
Name: MQTYPE-Response
Status: Optional
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-dnssd-multi-qtypes-12
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnssd-multi-qtypes-12.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Many thanks to Barry Lieba for the ARTART review.

## Comments

I am balloting "Yes" on this draft and concur with Paul Wouters: "Thanks for the draft. I wish we had done this years ago when the idea was first brought up".

[Ballot discuss]
Hi Ray,

Many thanks for this useful piece of work. I will be definitely balloting YES.

Please find below some few discussion points. I tagged some nits that I will send you in a PR (feel free to grab whatever useful there).

# Section 3.2: Control when to disable coalescing queries

CURRENT:
  The choice of when a client implementation should attempt to coalesce
  queries for multiple QTYPEs using this method is implementation
  specific and not discussed further herein.

Leaving this solely to clients may induce negative effects on application experience. Some coordination might be needed to be in place with the underlying resolution library.

I appreciate that you don’t want to be strict on how a decision to use the feature is made, but I think that at least an application that invoke a client library should be allowed to disable the feature if supported by the client. This would set a minimum behavior that prevents side effects when not wanted by applications.

# Section 3.4: Conditional MUST?

CURRENT:
  A conforming server that receives an MQTYPE-Query option in a query
  MUST return an MQTYPE-Response option in its response, even if that
  response is truncated (TC=1). 

Is this MUST supposed to be followed independent of whether an error is encountered?

[Ballot comment]
# Reference DNS terminology (RFC 9499)

# Section 3.1: Preserve the same format as sketched in 6891

CURRENT:
  The overall format of an EDNS option is shown for reference below,
  per [RFC6891], followed by the option specific data:

Given the wording above, it is better to use the same format as in RFC6891.

NEW:
                  +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                          OPTION-CODE                          |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |                        OPTION-LENGTH                        |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    4: |                                                              |
      /                          OPTION-DATA                          /
      /                                                              /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Using this format is even better given the MSB mention in that section per:

CURRENT:
  A list of 2-octet fields in network order (MSB first) each specifying
  a DNS RRTYPE that must be for a data RRTYPE as described in
  Section 3.1 of [RFC6895].

# Section 3.1: QTx notation

Add a mention to indicate that any of the QTs in the list will be referred to as QTx.

# Section 3.2: implementing vs enabled

CURRENT:
  DNS clients implementing this specification MUST generate packets
  that conform to the server request parsing rules described
  immediately below.

A client may implement the spec, but the feature can be disabled for a resolver, etc.

Maybe consider something such as (or similar constructs):

NEW:
  DNS clients coalesce queries MUST generate packets
  that conform to the server request parsing rules described
  immediately below.

# Section 3.3: Additional errors

CURRENT:
  If an MQTYPE-Query option is received in any inbound DNS message with
  an OpCode other than QUERY (0) the server MUST return a FORMERR
  response.

Maybe worth remind that the error cases discussed in RFC6891#section-7 are assumed and are not repeated here.

# Section 3.3: factorize FORMERR response

The current description of the error cases is repetitive. You may consider factorizing such as:

NEW:

In addition to the error cases discussed in Section 7 of [RFC6891], the server
MUST return a FORMERR response if the server receives:

* An MQTYPE-Query option in any inbound DNS message with an OpCode
  other than QUERY (0).

* An MQTYPE-Response option in any inbound DNS message.

* More than one MQTYPE-Query option in a query.

* An MQTYPE-Query option in a query that contains no primary question
  (i.e., QDCOUNT=0).

* An MQTYPE-Query option in a query where the primary question is a non-data
  RRTYPE (e.g., ANY or AXFR).

* An MQTYPE-Query option with an empty QT list.

* An invalid QT in the query (e.g., one corresponding to a Meta RRTYPE).

* A duplicate QT (or one duplicating the primary QTYPE field) in a query.

# Operational Considerations

You have already an operational consideration for servers to control QT limit (embedded in the Security Considerations). I wonder whether some additional operational considerations can be added. Some items that may be considered:

* potential impact on the resolution delay? Impact on the message size?
* need to cache server capability or not?
* need for clients to expose to applications whether the option is supported?
* side effect on other procedures such as Happy Eyeball, if any?
* servers to log failure counters related to MQTYPE options?

Cheers,
Med

[Ballot comment]
Thanks for the draft. I wish we had done this years ago when the idea was first brought up (although to use of _prefix has diminished its use case a bit)

The following Last Call announcement was sent out (ends 2026-02-16):

From: The IESG
To: IETF-Announce
CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-multi-qtypes@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Multiple QTYPEs) to Proposed Standard


The IESG has received a request from the Extensions for Scalable DNS Service
Discovery WG (dnssd) to consider the following document: - 'DNS Multiple
QTYPEs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a method for a DNS client to request
  additional DNS record types to be delivered alongside the primary
  record type specified in the question section of a DNS QUERY
  (OpCode=0).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/



No IPR declarations have been submitted directly on this I-D.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnssd-multi-qtypes-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the DNS EDNS0 Option Codes (OPT) registry in the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

the existing Option Codes registered by an earlier version of this document will have their references changed to [ RFC-to-be ].

Value: 20
Name: MQTYPE-Query
Status: Optional
Reference: [ RFC-to-be ]

Value: 21
Name: MQTYPE-Response
Status: Optional
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-01-02):

From: The IESG
To: IETF-Announce
CC: dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-multi-qtypes@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Multiple QTYPEs) to Proposed Standard


The IESG has received a request from the Extensions for Scalable DNS Service
Discovery WG (dnssd) to consider the following document: - 'DNS Multiple
QTYPEs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-01-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a method for a DNS client to request
  additional DNS record types to be delivered alongside the primary
  record type specified in the question section of a DNS QUERY
  (OpCode=0).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

Shepherd: Tim Wicinki

Responsible AD: Eric Vyncke


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The draft originally started in DNSOP, even though the work was more relevant
to what was happening in DNSSD.  The DNSOP chairs at the time felt the work
was worth being done, but there was less interest in DNSOP at that time with
other work going on.  Because of this, and the fact this work also fit into
the charter of DNSSD, DNSSD seemed like the most reasonable place for
the work to happen. The DNSOP chairs commented on this:

https://mailarchive.ietf.org/arch/msg/dnsop/5okVA-DhQZufu4qYQGfT0_zBO0M

In DNSOP, there was some deep discussion on the effects of multi-qtypes in DNSOP,
especially around HTTP/SVCB records:

https://mailarchive.ietf.org/arch/msg/dnsop/sF9UjTlMQWmjOmr_zx_Xoj-Ia1Q

But the discussions appear to reach consensus on the adjustments to the DNS
protocol.  In DNSSD, after reviewing the email discussions, they
were able to reach consensus.

The Working Group Last Call notices went out to both working groups.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Appeals Threatened

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There have been implementations done during the IETF hackathon.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This was also discussed in DNSOP, with no issues raised.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written, correct, and ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early DNSDIR review was done in January
https://mailarchive.ietf.org/arch/msg/dnsdir/vSpfjxJYcWxacamzc37RdZm0mYQ/

All other Last Call Reviews should be fine.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is the requested type and the RFC and Datatracker reflect this.
The reasoning for this is that this introduces a slight change to the DNS protocol that
gives the ability to receive multiple DNS Resource Records in a single response.
This change requires that multiple clients and multiple server implementations are able
to interoperate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All Authors have been reminded of IPR disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All Authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits plus closer inspection have been done. All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references appear correctly labelled.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No normative downward references

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

All Normative references are in a clear state

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Will not change any existing RFCs

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section assigns two new entries in the "DNS EDNS0 Option Codes (OPT)"
Registry.  These have been fully allocated by IANA, and all procedures, registries,
etc. are clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

# Document Shepherd Write-Up for Group Documents

Shepherd: Tim Wicinki

Responsible AD: Eric Vyncke


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The draft originally started in DNSOP, even though the work was more relevant
to what was happening in DNSSD.  The DNSOP chairs at the time felt the work
was worth being done, but there was less interest in DNSOP at that time with
other work going on.  Because of this, and the fact this work also fit into
the charter of DNSSD, DNSSD seemed like the most reasonable place for
the work to happen. The DNSOP chairs commented on this:

https://mailarchive.ietf.org/arch/msg/dnsop/5okVA-DhQZufu4qYQGfT0_zBO0M

In DNSOP, there was some deep discussion on the effects of multi-qtypes in DNSOP,
especially around HTTP/SVCB records:

https://mailarchive.ietf.org/arch/msg/dnsop/sF9UjTlMQWmjOmr_zx_Xoj-Ia1Q

But the discussions appear to reach consensus on the adjustments to the DNS
protocol.  In DNSSD, after reviewing the email discussions, they
were able to reach consensus.

The Working Group Last Call notices went out to both working groups.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Appeals Threatened

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There have been implementations done during the IETF hackathon.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This was also discussed in DNSOP, with no issues raised.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written, correct, and ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early DNSDIR review was done in January
https://mailarchive.ietf.org/arch/msg/dnsdir/vSpfjxJYcWxacamzc37RdZm0mYQ/

All other Last Call Reviews should be fine.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is the requested type and the RFC and Datatracker reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All Authors have been reminded of IPR disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All Authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits plus closer inspection have been done. All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references appear correctly labelled.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No normative downward references

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

All Normative references are in a clear state

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Will not change any existing RFCs

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section assigns two new entries in the "DNS EDNS0 Option Codes (OPT)"
Registry.  These have been fully allocated by IANA, and all procedures, registries,
etc. are clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

# Document Shepherd Write-Up for Group Documents

Shepherd: Tim Wicinki

Responsible AD: Eric Vyncke


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The draft originally started in DNSOP, even though the work was more relevant
to what was happening in DNSSD.  The DNSOP chairs at the time felt the work
was worth being done, but there was less interest in DNSOP at that time with
other work going on.  Because of this, and the fact this work also fit into
the charter of DNSSD, DNSSD seemed like the most reasonable place for
the work to happen. The DNSOP chairs commented on this:

https://mailarchive.ietf.org/arch/msg/dnsop/5okVA-DhQZufu4qYQGfT0_zBO0M

In DNSOP, there was some deep discussion on the effects of multi-qtypes in DNSOP,
especially around HTTP/SVCB records:

https://mailarchive.ietf.org/arch/msg/dnsop/sF9UjTlMQWmjOmr_zx_Xoj-Ia1Q

But the discussions appear to reach consensus on the adjustments to the DNS
protocol.  In DNSSD, after reviewing the email discussions, they
were able to reach consensus.

The Working Group Last Call notices went out to both working groups.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Appeals Threatened

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There have been implementations done during the IETF hackathon.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This was also discussed in DNSOP, with no issues raised.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written, correct, and ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early DNSDIR review was done in January
https://mailarchive.ietf.org/arch/msg/dnsdir/vSpfjxJYcWxacamzc37RdZm0mYQ/

All other Last Call Reviews should be fine.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is the requested type and the RFC and Datatracker reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All Authors have been reminded of IPR disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All Authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits plus closer inspection have been done. All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references appear correctly labelled.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No normative downward references

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

All Normative references are in a clear state

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Will not change any existing RFCs

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section assigns two new entries in the "DNS EDNS0 Option Codes (OPT)"
Registry.  These have been fully allocated by IANA, and all procedures, registries,
etc. are clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

# Document Shepherd Write-Up for Group Documents

Shepherd: Tim Wicinki

Responsible AD: Eric Vyncke


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The draft originally started in DNSOP, even though the work was more relevant
to what was happening in DNSSD.  The DNSOP chairs at the time felt the work
was worth being done, but there was less interest in DNSOP at that time with
other work going on.  Because of this, and the fact this work also fit into
the charter of DNSSD, DNSSD seemed like the most reasonable place for
the work to happen. The DNSOP chairs commented on this:

https://mailarchive.ietf.org/arch/msg/dnsop/5okVA-DhQZufu4qYQGfT0_zBO0M

In DNSOP, there was some deep discussion on the effects of multi-qtypes in DNSOP,
especially around HTTP/SVCB records:

https://mailarchive.ietf.org/arch/msg/dnsop/sF9UjTlMQWmjOmr_zx_Xoj-Ia1Q

But the discussions appear to reach consensus on the adjustments to the DNS
protocol.  In DNSSD, the discussions were able to reach consensus.

The Working Group Last Call notices went out to both working groups.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Appeals Threatened

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There have been implementations done during the IETF hackathon.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This was also discussed in DNSOP, with no issues raised.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written, correct, and ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early DNSDIR review was done in January
https://mailarchive.ietf.org/arch/msg/dnsdir/vSpfjxJYcWxacamzc37RdZm0mYQ/

All other Last Call Reviews should be fine.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is the requested type and the RFC and Datatracker reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All Authors have been reminded of IPR disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All Authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits plus closer inspection have been done. All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references appear correctly labelled.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No normative downward references

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

All Normative references are in a clear state

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Will not change any existing RFCs

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section assigns two new entries in the "DNS EDNS0 Option Codes (OPT)"
Registry.  These have been fully allocated by IANA, and all procedures, registries,
etc. are clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

Shepherd: Tim Wicinki

Responsible AD: Eric Vyncke


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no controversy and all decisions had solid consensus.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Appeals Threatened

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There have been implementations done during the IETF hackathon.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This was also discussed in DNSOP, with no issues raised.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review needed

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written, correct, and ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

another DNSDIR review wouldn't hurt

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is the requested type and the RFC and Datatracker reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All Authors have been reminded of IPR disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All Authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits plus closer inspection have been done. All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All references appear correctly labelled.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No normative downward references

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

All Normative references are in a clear state

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Will not change any existing RFCs

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section assigns two new entries in the "DNS EDNS0 Option Codes (OPT)"
Registry.  These have been early allocated by IANA, and all procedures, registries,
etc. are clear.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

The document received positive support from many people
Tommy Jensen raised two issues in
https://mailarchive.ietf.org/arch/msg/dnssd/bQkA2274kKrzNcpFRlLoQif2u1M/
that need to be addressed before the document can advance:

(1) It seems to go without saying, but Section 3.3 for Client Response Processing never actually says that clients MUST/SHOULD NOT cache record types it receives that it didn't request. Should we? It seems like an attack vector if we are treating this response as the set as if every type was the QTYPE. This is expected for meta types, but in the case of querying for {AAAA, SVCB}, no client would expect A records to come back which could be cache poisoning for a name that was intended to be IPv6-only.

(2) The security considerations section acknowledges the amplification attack this could enable, but it does not mention what Section 3.3's first bullet says about the server choosing to not process a request because it had too many types. I think it should in the spirit of giving obvious advice to implementors as it is currently implied but not stated. In fact, Section 3.2.2's normatives don't leave much room for an RFC novice to read "but you can also choose to defend against complex queries" from it.