Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

[Abtin Keshavarzian <[e-mail]>]

Actually, on second thought, maybe the right thing to do is check for the
> KEY RR and not the SRV RR. If the key matches, the delete is okay. If there
> are no records on the name, the delete is okay.


Thanks Ted. I agree. This sounds good (and simpler).

On Sat, Dec 19, 2020 at 9:51 PM Kangping Dong <[e-mail]> wrote:

> RFC 6763 Section 6.8 Service Instances with MultipleTXT Records
>> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
>> However, the end of the referenced section also states:
>>
>>    Future protocol designs should not follow this bad
>>    example by mimicking this inadequacy of the LPR printing protocol.
>>
>> Thanks Jonathan, I missed that section.
>
> So I guess the question is whether we can/should mandate this future going
>> forward in SRP?
>>
> Exactly. I would prefer we explicitly disallow multiple TXT records for
> SRP.
>
> BRs,
> Kangping
>
> On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui <[e-mail]> wrote:
>
>>
>> On Sat, Dec 19, 2020 at 7:11 AM Kangping Dong <[e-mail]> wrote:
>>
>>>
>>> 2. What's the use case of supporting multiple TXT RRs?
>>> in section *2.3.1.2. Service Description Instruction
>>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-service-description-instruc>*,
>>> we have:
>>>
>>>> zero or more "Add to an RRset" TXT RRs,
>>>>
>>>
>>> Are there real use cases that we need more than one TXT RRs? What is the
>>> expected behavior
>>> for the advertising proxy to publish this service with multiple TXT RRs?
>>> (I think DNS-SD requires
>>> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated
>>> to form a new TXT RR?
>>> If there is no such use case, should we require a single TXT RR? It will
>>> be easier to implement on both
>>> client and server side and consistent with DNS-SD. thoughts?
>>>
>>
>> RFC 6763 Section 6.8 Service Instances with MultipleTXT Records
>> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
>> However, the end of the referenced section also states:
>>
>>    Future protocol designs should not follow this bad
>>    example by mimicking this inadequacy of the LPR printing protocol.
>>
>> So I guess the question is whether we can/should mandate this future
>> going forward in SRP?
>>
>> --
>> Jonathan Hui
>>
>>