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

[Ted Lemon <[e-mail]>]

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