Re: [dnssd] Progressing with multi-qtypes

I think I may have already argued for some of these points, but I think I
was a bystander for the multi-option versus QTD question. I do agree with
the approach you've stated—just burn two option codes. We have plenty. I'm
sure someone will curse our memory 2000 years from now, but how else will
we be remembered if we don't do this?

I may have been one of the people who argued for getting rid of QTCOUNT,
and I still think that's right—it's redundant, and if we send it, we have
to validate it. That seems like needless complexity.

As for the limit on the number of qtypes, I also don't see the need for
that. There will no doubt be practical limits; the most likely of these is
simply that there aren't actually that many rrtypes that will likely be
represented on any given name. So I'm not sure what an explicit limit here
accomplishes. At the very least we should articulate a reason for the limit
if we impose one.

On Mon, Apr 29, 2024 at 6:17 AM Ray Bellis <ray@bellis.me.uk> wrote:

> With apologies for the delay (caused by other travel since the Brisbane
> meeting) the proposal during the session there was to:
>
> - remove the QTD bit and use a pair of EDNS option codes instead
>    (one for queries, and another for responses).
>
> - remove the QTCOUNT field
>
> - either impose a fixed limit on the number of additional QTYPES (in the
>    range of 3 - 8?) or remove the limit altogether.
>
> We need to get formal WG consensus on these points so please send your
> thoughts to the list...
>
> thanks
>
> Ray
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>