Thursday July 24, 12:00-13:00 local time, El Prado
published SRP and update-lease as RFCs
Ted (Lemon): can we PSA about the full service DNS-SD resolver?
Chris: presentation about that in snac tomorrow (draft-tlmk-infra-dnssd)
Ted: use case is a WiFi device on battery that doesn't want to listen
full time for mDNS, but does want to advertise its services and discover
others
Charter now six years old and quite long. Needs to be reset around
current goals.
Chris: this is just a heads up, so we can collect your thoughts here or
later.
Éric (Vyncke): keep maintenance of existing protocols, just in case.
Ted: yes, maintenance. SRP has a few open issues (replay attacks
impacting devices without clocks). May need to extend protocol for
replay protection for devices without clocks.
Ray (Bellis): let's wait until multi-qtypes is approved so there will be
no need to add it to the new charter
LC work concluded. Tommy Jensen raised some issues, need to follow up
with him. Do shepherd writeup, get AD review.
Ray: are you saying Tommy told you off list he does not need that
revision any more?
Chris: can't speak for Tommy
https://github.com/dnssd-wg/draft-ietf-dnssd-tsr
Esko (Dijk): is now the 2nd author; there are issues and Pull Requests.
Ted managed to add many issues in the last hour. As new author, I had a
fresh look, working on a terminology section in PR #4.
Ted: should add registrar/registrant to terminology section
Esko: PR (#4) streamlines things, aligns with RFC terminology,
simplification, clarification. TSR requestor is not like SRP requestor.
Want to get terminology clear before changing any already defined
features in this protocol.
Ted: inconsistent use of requestor and registrant to mean the same
thing, should unify, prefers "registrant"
Esko: SRP requestor can be registrant?
Ted: no, registrant is process on machine that the mDNS
responder/registrar is on, that does the registration.
Ted: is there a case where requestor is non-local? if so we should fix
that because it is confusing
Ted: TSR not only for proxies.
Esko: inviting further comments. Also want to discuss issue #5. Not
fully clear what needs to happen here.
Ted: device can be on mesh and WiFi at the same time. Need to answer the
question (somewhere, maybe not in this draft), should it register in
both places? What if SRP is shared between the two? Then perhaps it can
just register with it once. Current thread border routers don't do SRP
on WiFi.
Ted: updated TSR implementation in spring of 2025, fixing a bunch of
edge cases. These open issues document the problems we fixed.
Ted: #6 and #7 are related. 6 is interesting.
Ted: #7: Need input from people who know how mDNS work to ensure
what I say makes total sense.
Ted: #11: Sometimes, updates are too large and have to span several
packets. The two packets can be considered as a conflict with the local
cache since they contain partial data.
Ted: I think that's everything I needed to talk about.
Esko: #1: the Advertising Proxy apparently contains an Advertising
Proxy, should fix naming to reduce confusion.
Ted: Sorted, I believe.
Ted: #6: refers to email discussion about TTLs.
Ted: 6762 advises low TTL for host names, but that does not make sense
from a proxy.
Ted: harebrained scheme: eliminate conflicts by creating subdomains of
.local #10. What we want here in the end is to get rid of the
advertising proxy, once everything supports SRP or ..... End up doing
everything over DNS. Should remove the text about this elegant solution
(the subdomains) from this inelegant document.
Ted: #11: devices might end up picking the wrong address to
connect to first. Should change this to MUST NOT, if you know how to
tell whether a link local address is valid for you.
Esko: if SRP client registers link local address, what do we do?
Ted: does not happen on Thread border routers. On WiFi we do want it.
Might be the best address to contact that client. Need to specify how to
know whether that registration is on-link. Need some metadata because a
standard DNS zone cannot carry that (that = scope ID?).
Ted: #9: SRP servers are only authorities if they are
synchronised. Should only advertise when synchronised. Where to specify?
SRP replication document, or advertising proxy document?
(slides contain most of Donald's spoken words)
Ted: we have a usecase for forwarding in SRP, because SRP wants to
validate message source after several hops. I was going to forward the
message unchanged. I see the utility of being able to represent the
second ID, but I wonder what motivated that.
Donald: the problem is that the signature covers the request ID, and a
forwarder would usually pick a new ID, which then causes signature
verification failure. The additions to 2931bis should cover that.
Ted: we'll have a look
Poll for people interested in working on this. 6 people said yes,
another 6 with no opinion, and none against.