Re: [dnssd] SRP: name conflict while not knowing which name conflicts
Ted Lemon <mellon@fugue.com> Mon, 26 September 2022 14:50 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6EDC14F746 for <dnssd@ietfa.amsl.com>; Mon, 26 Sep 2022 07:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPu0xf5NoO4W for <dnssd@ietfa.amsl.com>; Mon, 26 Sep 2022 07:50:48 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B91C1526E7 for <dnssd@ietf.org>; Mon, 26 Sep 2022 07:50:38 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id v2so8491267edc.7 for <dnssd@ietf.org>; Mon, 26 Sep 2022 07:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=8SMeXHx9JO049N2LjMeH5yGUiD5uXDHwNe4scx417eY=; b=iwUNvgy62XWgU+x/A2x1U2ymT7tvPpWCun9V7vAE8nxDU+Yn1mMFtJW5fkk7kx8U46 BP27068RITCjadSBL8tHpJyPhSUhtH2wxJI2XcTCs2kFfHj4SlgRvD+EiEIosq6CFt1S q3p1aFbQyKDx5keI3AlsG9RWeDWhZiFlF1u0poi+Q8r2wCWEEcruNRjAsFmB5hTkibSa Yjl/2khdUZ3Pl5YhImE2ZzPMLl4c47LbQL/Usy7tmppbNxTZAlhZfCI3ZaNOU9VrQeko lOG8/ZqA917F5HlP7tsucg8eItz+Ku105aNJ9xdhrFOYeoRaQbdfyqHpRJ5icMCe0506 GKaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=8SMeXHx9JO049N2LjMeH5yGUiD5uXDHwNe4scx417eY=; b=5+TpJXtkYUnkn94OOMUk4bpFdxJA6nAXEPDBfXM4J7RSZwf9cU3QYxY5TWIvrMXgMO mWKsI/ie8U+5Jff2yLUC19RlEr/IwZqx/oLMKxmb+KpGX9/p+NwB+XLi8aZoQhmATx1q htPqtiA4kyreKRAPoFUv4/7Y2vxL6NdSN5bTLzo3LM424EL8cnw6n0bhBOqgCNTCiD0n OrfXSUXRsXWs5poVslyizeT4Nrza+Ge6PWea4MqH+UkT0Y7cimiXG6b81fZnVCyOQRuS 4L7P0jzcXTbenT5BM2FhYap7f5M9mdcBdSZol1uMShDqRWlQttOk23Wxy3vjtHsy5Pf8 yaYw==
X-Gm-Message-State: ACrzQf0ddz9eNX/mgkDW240+ALGJy1Gu5D+Q2RHrtArtd5wrSu3a07n2 XrB8dpApbehZ4A3wAJNZRTXSVseTCnKU0gMvTDkPv1YhHMo=
X-Google-Smtp-Source: AMsMyM75amBKZjAowhAj+HfZeCghJ4yull0+AFNtGSPAOMslLC91EfY3PuCF+Ihh1QG40+t8MXHrHSXHsz0dz2Vy+JI=
X-Received: by 2002:a05:6402:5ca:b0:43b:6e01:482c with SMTP id n10-20020a05640205ca00b0043b6e01482cmr23502124edx.189.1664203837465; Mon, 26 Sep 2022 07:50:37 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB19780211A2F50F5E66BCE005FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAJ5Rr7Ys+bmFiP9j3ebptBEZHXX+6rzkTRaFHr7_mmgVZb9sZQ@mail.gmail.com> <DU0P190MB1978E63F6C69807759C10FD0FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CADyWQ+EMf3XTLuZWupLNeGwQ8Gaqd-A7BvyAs4wK-fT7M5zk6Q@mail.gmail.com> <DU0P190MB19786D6BDA466AC9667087C9FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1k0si52gnCHz_A-coitbVG8AHovLaWpJXBaWiN3to0j+w@mail.gmail.com> <DU0P190MB19782E66596D8C646D5A3F89FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1kOLHnKkarjfuOeqRgS0Rz8n219Av37xbLxbakwHhS5-g@mail.gmail.com> <CADyWQ+Hzg44nbJ49PwwMsK9cPVXtao2aFeiDr7n0UyCt7JXj2A@mail.gmail.com> <CAPt1N1kUPKkSdfZj2P23fJ_2OQmRR3nQyE+O+Q90aV7qKDcHbw@mail.gmail.com> <DU0P190MB1978522CFB7784B2BA16C1F0FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mUYCyjakENUb460kEf07f0UdXoAtsLn1weHBKvaMWfOQ@mail.gmail.com> <DU0P190MB1978C9983DA1982AC70B2874FD519@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1=gLgMp17qBNgxpj02Eiu5Yc7ye55aFE-FhbF0E95yRvA@mail.gmail.com> <DU0P190MB1978983616C9CB8DE1EF2ACEFD529@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978983616C9CB8DE1EF2ACEFD529@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 26 Sep 2022 10:50:26 -0400
Message-ID: <CAPt1N1ngszRzbfM8_r51vhCg=wUxA0nk=cOheXp=A6H204DvYA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: "dnssd@ietf.org" <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000090fd8505e995a635"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ySOYd4194dId_84ZVv4bc2XgXsY>
Subject: Re: [dnssd] SRP: name conflict while not knowing which name conflicts
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 14:50:52 -0000
Maybe we should write some conformance tests that send unknown options. :) But yes, I think you’re right. Op ma 26 sep. 2022 om 10:49 schreef Esko Dijk <esko.dijk@iotconsultancy.nl> > Hi Ted, > > > > I would still be in favor to insert a sentence about the possible use of > the answer records (in case of an error) in the future. > > > > > But right now we have no text at all about how the client interprets rrs > in the response, so I think even this is unnecessary. If it does something > with them, it’s out of spec. > > > > In my years of experience with how software development works, an > implementer somewhere is bound to check incoming messages very precisely > against what the implementer thinks it should be -- never mind the spec. > The robustness principle isn’t automatically applied, now in times of > security breaches everywhere. It’s rather becoming “if the input looks > slightly different from the usual, it must be wrong” and extra checks are > coded in everywhere without thinking about extendibility. I have seen > implementations where nice TLVs are defined for extendability, and then > Version 1 implementations discard any message received with an unknown TLV > type, such that the future Version 2 implementations could never use a new > TLV type anymore, i.e. the extendibility that was defined doesn’t exist > anymore in practice. > > > > Especially in our case since the base spec DNS Update precisely tells > what the response fields can be, we have to say here that SRP deviates: > that it can contain something else. (Which is then defined in the future, > maybe, or maybe not.) > > > > But if the rest disagrees for good reasons then we should not add any > text. This additional text would have zero code impact. > > > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 18:47 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > I just have no idea what problem you are solving here. And no, we do not > know how to represent this in the response. > > > > I get that you have some ideas about how this could be used, but that’s > not what I’m asking. What I’m asking is, what /problem/ does this solve? > What bad thing happens if we don’t do this, and how does doing this make it > better? And to be clear, by “problem” I mean “what bad experience will the > user have that will be less bad if we do this?” Having to rename at all is > a catastrophe. We might make that catastrophe trivially smaller. How does > that materially benefit the end user? > > > > As for representation, right now the response can contain the update, > verbatim. We need to specify in detail a response format that the client > can unambiguously interpret as listing names that were in conflict. I’m not > saying this is hard, just that we have to write it up, implement it, test > it, feel confident it works. > > > > What we have in the document now describes what we have implemented and > extensively interop tested. To meet that standard for this proposed update > is at least a year of work. > > > > So if we want to do this in this document, we need a really, REALLY, good > reason, not some ideas about how it could be used. > > > > But the bottom line is that this is harmless. If it’s useful to do this > year’s work, let’s just do it in a follow-on document. But I really > strongly urge you not to insist on doing it in this document. It’s not as > small a change as you are imagining. > > > > Regarding preparing the client for this, the new spec would say how the > client should handle this, so I don’t think that’s necessary. An existing > client can be expected to ignore whatever is sent by a new implementation. > > > > I guess we could say that the client MUST ignore any RRs in the response. > But right now we have no text at all about how the client interprets rrs in > the response, so I think even this is unnecessary. If it does something > with them, it’s out of spec. > > > > Op vr 23 sep. 2022 om 11:42 schreef Esko Dijk <esko.dijk@iotconsultancy.nl > > > > > It took you ten paragraphs to explain what the client would do with this > information > > That was just explaining the benefits. Hence the more, the better. It’s > just a perfect solution if you just want to be prepared for all possible > futures with a minimum of effort and no nasty dependencies. It’s the > equivalent of our local high school recommending yesterday for pupils to > take the “STEM” profile in case they don’t know yet what future job to do > because it leaves a maximum of options still open. Only, less difficult to > execute ;-) > > > > But we can also do without solving this particular issue and avoid another > WGLC – because we do have simple name-change solutions for the SRP client > that work already (as you also indicated). So if we foresee potential > issues/complexity here maybe better leave it for a later time. > > > > About the format definition: we already know how to include records into a > DNS response so don’t agree to your point there. But true, it will take > more than 1 sentence to explain such a new feature – maybe an entire > subsection to do it right. > > > > Can’t we just say the SRP client MUST be prepared to receive something in > Additional records of YXDomain, whatever it is? Just to pave the way for > our potential future new draft. (Otherwise the SRP client may ignore the > response as “invalid” and not heed it.) > > That would only be one sentence and requires no code. > > > > Regards > > Esko > > > > *From:* Ted Lemon <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 17:14 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > 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 <esko.dijk@iotconsultancy.nl > > > > 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 <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 15:59 > *To:* Tim Wicinski <tjw.ietf@gmail.com> > *Cc:* Esko Dijk <esko.dijk@iotconsultancy.nl>; Kangping Dong < > wgtdkp@google.com>; dnssd@ietf.org > *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 <tjw.ietf@gmail.com> 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 <mellon@fugue.com> 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 <esko.dijk@iotconsultancy.nl> > 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 <mellon@fugue.com> > *Sent:* Friday, September 23, 2022 14:56 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; Tim Wicinski <tjw.ietf@gmail.com>; > dnssd@ietf.org > *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 <esko.dijk@iotconsultancy.nl > > > > 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 <tjw.ietf@gmail.com> > *Sent:* Friday, September 23, 2022 12:28 > *To:* Esko Dijk <esko.dijk@iotconsultancy.nl> > *Cc:* Kangping Dong <wgtdkp@google.com>; dnssd@ietf.org; Ted Lemon < > mellon@fugue.com> > *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name > conflicts > > > > > > > > On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <esko.dijk@iotconsultancy.nl> > 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 > >
- [dnssd] SRP: name conflict while not knowing whic… Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Kangping Dong
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Tim Wicinski
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Tim Wicinski
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Nathan Dyck
- Re: [dnssd] SRP: name conflict while not knowing … Chris Box
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Michael Richardson
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon
- Re: [dnssd] SRP: name conflict while not knowing … Esko Dijk
- Re: [dnssd] SRP: name conflict while not knowing … Ted Lemon