[dnssd] Mohamed Boucadair's Discuss on draft-ietf-dnssd-multi-qtypes-12: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-dnssd-multi-qtypes-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/



----------------------------------------------------------------------
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?


----------------------------------------------------------------------
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