Re: [dnssd] SRP: name conflict while not knowing which name conflicts

[Tim Wicinski <[e-mail]>]

How about just the name(s) attempted to register with that request
which are in conflict?

I vote for being explicit on the minimum the SRP registar needs to do.

also, not a chair but write up all the text changes and make sure the WG
has no issues with that.

On Fri, Sep 23, 2022 at 9:14 AM Ted Lemon <[e-mail]> wrote:

> Okay. I ask because we should be explicit.
>
> Chairs, how do you want to approach this? I think this is a WG consensus
> that I failed to put into the document, but we didn't last call on it, so I
> don't know that it's _actually_ consensus. Do we need a new WGLC?
>
> On Fri, Sep 23, 2022 at 9:12 AM Esko Dijk <[e-mail]>
> wrote:
>
>> > So it can certainly respond with a list of the names on which it found
>> conflicts, but the list might not be able to be made complete
>>
>>
>>
>> I think it should respond at least with the names that it knows are in
>> conflict (based on its internal database of SRP registrations for example).
>> So, 0 or more records in the response.  Zero records is our current
>> specified baseline.
>>
>> An SRP registrar implementation that wants to put in more work can
>> certainly do so – we don’t need to standardize here exactly what it should
>> do for that.
>>
>>
>>
>> Esko
>>
>>
>>
>> *From:* Ted Lemon <[e-mail]>
>> *Sent:* Friday, September 23, 2022 14:56
>> *To:* Esko Dijk <[e-mail]>
>> *Cc:* Kangping Dong <[e-mail]>; Tim Wicinski <[e-mail]>;
>> [e-mail]
>> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
>> conflicts
>>
>>
>>
>> Aargh. Thanks for catching this Eskimo, and thanks Kangping for
>> remembering the conversation. I had completely forgotten, although I recall
>> it now of course.
>>
>>
>>
>> One problem with this approach is that it will not be the case that the
>> SRP server necessarily knows all of the names that are in conflict. So it
>> can certainly respond with a list of the names on which it found conflicts,
>> but the list might not be able to be made complete without more work. Do we
>> want to require it to do that work?
>>
>>
>>
>> Op vr 23 sep. 2022 om 08:07 schreef Esko Dijk <
>> [e-mail]>
>>
>> Hi Tim,
>>
>>
>>
>> > I don't think an update to 2136 is needed here, as section 2.2.3.1
>> describes the differences with an SRP registrations and 2136 Updates,
>>
>> but this response should be tested against a DNS update response.
>>
>>
>>
>> Clear, we can just add a bullet in 2.2.3.1 then as plain DNS Update isn’t
>> updated by this draft.  What’s important then is that the server, when
>> receiving a DNS Update that is not an SRP Update, will not use the new
>> mechanism of including the conflicting record(s). Only do this for an SRP
>> Update.
>>
>> And for testing: do you mean sending the “new” type of YXDomain response
>> to a plain DNS Update client and see what happens?  That seems not
>> necessary if the SRP registrar is careful in using the “new” response
>> format only for SRP clients.
>>
>>
>>
>> Esko
>>
>>
>>
>>
>>
>> *From:* Tim Wicinski <[e-mail]>
>> *Sent:* Friday, September 23, 2022 12:28
>> *To:* Esko Dijk <[e-mail]>
>> *Cc:* Kangping Dong <[e-mail]>; [e-mail]; Ted Lemon <
>> [e-mail]>
>> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
>> conflicts
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <[e-mail]>
>> wrote:
>>
>> Thanks Kangping,
>>
>>
>>
>> It looks like including the conflicting name records in the Additional
>> section is a good base solution and also easy to describe in the SRP draft,
>> which does not impact the states & procedures of registrar and client.
>>
>> It’s just additional helpful information the client may use to compose
>> the retry Update.  The part about renaming by the registrar, on behalf of
>> the client, seems more tricky and may impact states & procedures which were
>> just WGLC-reviewed now.
>>
>>
>>
>> If we use the Additional section for a YXDomain response, this may
>> require a formal update of RFC 2136 (3.8) since DNS Update only allows a
>> server to repeat all records in the (error) response or to exclude all
>> records.
>>
>>
>>
>> Esko
>>
>>
>>
>>
>>
>> Esko,
>>
>>
>>
>> I don't think an update to 2136 is needed here, as section 2.2.3.1
>> describes the differences with an SRP registrations and 2136 Updates,
>>
>> but this response should be tested against a DNS update response.
>>
>>
>>
>> Kangping, I believe this is your workflow description - I pasted it here
>> to assist in my readings.
>>
>>
>>
>> 1. If a name has already been registered on the SRP server or a name conflict
>> error is returned by the Advertising Proxy:
>>
>>     the SRP server responds with the RR that includes the conflicted name.
>>
>>     If the client sees such records, it knows the conflicts on the SRP
>> server and will retry with a new name.
>>
>>
>>
>> 2. If a name conflict is reported to the SRP server after the SRP update transaction
>> has been committed:
>>
>>     The next time the SRP client registers, the SRP server responds with
>> a CNAME record which includes the new name.
>>
>>     If the client sees such records, it knows the conflict on the
>> multicast link and will accept the name or retry with another name.
>>
>>
>>
>> https://mailarchive.ietf.org/arch/msg/dnssd/cUJBXN9WXBguPKtTYgPYq4bo4pQ/
>>
>>
>>
>> Tim
>>
>>