Re: [dnssd] Progressing with multi-qtypes

[ Speaking as individual contributor ]

+1 to removing the QTD bit in favor of two option codes

+1 to removing the type number limit entirely. Since the server handling of
these is a SHOULD, the server is allowed to only handle some of them if it
is resource constrained. We already have the server send the list of types
it handled in the response option, so we could just say that the server MAY
ignore some of the requested types, but in that case it MUST NOT include
them in the response options?

David

On Mon, Apr 29, 2024 at 6:21 AM Ted Lemon <mellon@fugue.com> wrote:

> 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
>>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>