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

[Ted Lemon <[e-mail]>]

Eskimo, I beg to differ on the idea that this change is simple. It took you
ten paragraphs to explain what the client would do with this information.
We don’t know how to encode it in the response, so we have to invent that.
We don’t have any implementations of it. So its a really big deal to
suggest this change now, after WGLC. If this is important, I think someone
who is interested should write up a draft proposing a solution and ask the
WG to adopt it.

Adding this to SRP now will mean that SRP standardization will take about
an additional year, if we move very fast. I don’t think this is remotely
worth it.

Op vr 23 sep. 2022 om 10:24 schreef Esso Dijk <[e-mail]>

> Fully agree that we should not do the “renaming by the registrar” part.
> There’s some additional complexity implied by this and things that may
> break interoperability.
>
>
>
> > the leftmost label in the service instance name is the same as the
> leftmost label in the hostname
>
> This is how some implementations may work, but there’s many others that
> don’t. So we can’t make generic assumptions on naming choices.
>
> In any case a smart SRP client that picks its names like this will simply
> rename both – no additional complexity for the client then.
>
>
>
> Despite this, it is fairly simple if we say the SRP registrar SHOULD
> insert any conflicting record(s) that it knows about into the response. As
> I argued before, this doesn’t change any of the procedures we have defined
> in SRP so far.
>
>
>
> And it leaves a great amount of freedom to implementations without
> apparent disadvantages, and without interop problems:
>
>    - A SRP client that doesn’t want to bother parsing the SRP Update
>    response, can just ignore the Additional records in the YXDomain response.
>    It can apply its strategy of “change both names” for example as discussed
>    above.
>    - An SRP registrar that is on a constrained device, or just doesn’t
>    want to bother, can include 0 Additional records (equivalent to saying “I
>    don’t know what the conflict is”) which is acceptable too.
>    - An SRP registrar that is an existing implementation that people
>    don’t want to change, is still compliant.
>    - An SRP client that is an existing implementation that people don’t
>    want to change, is still compliant.  (Maybe it takes some more retries to
>    get registered – but that’s no big problem.)
>    - If in the future an SRP client gets upgraded to a “smarter” client
>    that can detect the conflicts enlisted in the YXDomain response, it may
>    become more efficient. This upgrading is independent of servers’ upgrading
>    or not.
>    - If in the future an SRP server gets upgraded to a “smarter” server
>    that can returns conflicts in the YXDomain response, things may become more
>    efficient. This upgrading is independent from clients’ upgrading or not.
>    - If the Matter approach to names wins and conflicts hardly occur for
>    this reason, and hence no-one implements the conflicting-records feature,
>    then nothing is lost – we just have a small bit of junk-DNA like text in
>    the SRP RFC.
>
>
>
> So the idea is to recommend returning known-conflict records FYI to the
> client and leaving the client free to pursue any naming strategy.
>
>
>
> Esko
>
>
>
>
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, September 23, 2022 15:59
> *To:* Tim Wicinski <[e-mail]>
> *Cc:* Esko Dijk <[e-mail]>; Kangping Dong <
> [e-mail]>; [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> Okay, as I dig deeper into this, I'm realizing that things have changed /a
> lot/ since we had this conversation. First of all, for Matter accessories,
> name changes by the server are simply unacceptable. So the idea that we're
> going to signal back to the SRP client that we changed the name is no
> longer really necessary, because we aren't going to change the name. The
> current Apple Advertising Proxy implementation never does renaming.
>
>
>
> If there is a name conflict, we report it, but we have done a /lot/ of
> work to avoid gratuitous name conflicts, and I think that that work is
> actually what we should be relying on here. Effectively what we've done is
> to make the advertising proxy look more like an authoritative name server,
> and as we agreed in the discussion Kangping found, we are never going to do
> this when the SRP server is an authoritative name server.
>
>
>
> What we've done here is the TSR draft and the SRP replication draft. The
> TSR draft prevents gratuitous name conflicts when two advertising proxies
> are not doing SRP replication. The SRP replication protocol provides a way
> for multiple advertising proxies to sustain a consensus, so that conflicts
> don't occur. Between these two drafts (really, between their
> implementations) we no longer see renaming happening with our advertising
> proxies.
>
>
>
> As we move more toward unicast DNSSD as the baseline, with mDNS as the
> exception, I think that the likelihood of conflicts will drop further.
>
>
>
> My point is, do we really want to add this complexity in SRP? What is the
> problem we are trying to solve here? Most of the time, the way names are
> chosen is deterministic—the leftmost label in the service instance name is
> the same as the leftmost label in the hostname. And so if there is a name
> conflict on one, it's going to be on the other as well.
>
>
>
> So what I think we should actually do is leave the document the way it is.
> Doing what we're talking about here will create a great deal of complexity
> in the client and in the server, at a very late stage in the development of
> the protocol, with no obvious benefit.
>
>
>
> Thoughts?
>
>
>
> On Fri, Sep 23, 2022 at 9:27 AM Tim Wicinski <[e-mail]> wrote:
>
> 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
>
>