Thursday November 6, 09:30-11:00 local time, Van Horne meeting room
Stuart Cheshire and Esko Dijk taking notes.
Chris Box gave status update on documents in progress. DNS Update
Lease and Service Registration Protocol have been published.
Multiple QTYPEs is being updated for publication.
We will be discussing TSR and Advertising Proxy today.
We will also be discussing individual documents as time permits.
Éric Vyncke added one final agenda item, to discuss Erratum report
8560 from Ilya Kulakov for the RECONFIRM operation in RFC “8765
DNS Push Notifications”.
Éric Vyncke: Encourages people in the room to engage in the rechartering
discussions. The final item (“may also adopt work that improves the
underlying technology”) is too broad and is unlikely to receive IESG
approval.
Ted Lemon: For item 3 on the slide, TSR is not about name conflicts. TSR
is actually about preferring fresh data over stale data. We have also
discovered things we didn’t anticipate in the SRP design, which we
should fix.
François Michel (Apple): We really want to work on improving efficiency
on constrained networks — like Thread.
Esko Dijk (IoTconsultancy.nl): The current charter is looking dated now,
and need to be updated. For example, “ZigBee IP” should be replaced by
“CSA Matter”.
Éric Vyncke: The process is that we have an initial discussion between
chairs and AD, then solicit input from the WG until mid-December, then
initiate the official rechartering process.
Esko Dijk (IoTconsultancy.nl) presenting slides. Specific open issue
items listed in the slides were discussed.
Ted Lemon (Apple): We have changed the document to say that if the data
does not have the same source (determined by key), then it is
automatically considered to be in conflict, regardless of TSR value. We
do need to probe again and announce the data, because there may be stale
data in other cashes that we need to update.
RFC 6762 says that Multicast DNS records should not be transmitted
more frequently than once per second.
Stuart Cheshire: The intent was that identical data should not be
transmitted more frequently than once per second. We should feel free to
update previous RFC guidance if appropriate.
Ted Lemon (Apple): The client (querier) is expected to use best practice
mDNS querying, keep it open until a successful connection with service
is made (Happy Eyeballs). If it doesn’t do that already, we can’t help
it.
Esko to look if some informative text can help here.
Expect that RFC 6762 applies in such cases where non-TSR mDNS
advertisements are processed. There isn’t a perfect solution for such
late conflicts that really shouldn’t normally happen in the first place.
Esko: I’ll look if we can add a sentence to point the reader to the
appropriate guidance. The SRP Registrar has no way to asynchronously
inform the SRP registrant of a late conflict.
Ted Lemon: It is ambiguous what the right outcome is. In principle, the
data in the SRP zone is not in conflict; it is the mirroring of that
data in to the Multicast DNS (“dot-local”) zone that is conflicting. For
use cases like Matter this has not proven to be a problem because Matter
ensures that names are unique.
Agreement to not have this in TSR document scope.
Ted Lemon: May need a separate document (not in SRP replication doc).
[Skipped to save time]
Draft work will resume after TSR is done.
Esko: Would be good to make an intermediate update, to keep it active.
Mathieu Kardous has changed employment, and no longer has the time to
conribute to this. We are now seeking a new co-author. Matter is still
enthusiastic to get this done, but we would prefer it be done in the
IETF instad of in some other body.
The DNSSD service on infrastructure can run on any device on the link
— e.g., it can run on Thread Border Routers.
Stuart Cheshire: This work is extremely valuable. Long term we’d like
every Wi-Fi Access Point to support this capability, but before then we
should use deploying it on other devices as a stepping stone to the
eventual solution.
Esko Dijk: Agree with Stuart. Even though, personally, I am working on
primarily Thread currently, it’s important to have stable SRP/DNS
service in the home and not rely on e.g., Thread Border Router devices
that may be switched off at certain times.
Éric Vyncke: I also think this work is extremely valuable.
Ted Lemon: We will be discussing this topic at the CSA Matter meeting
next week in Barcelona. Should we formally adopt this as a Working Group
document now?
Éric Vyncke: That’s up to the Working Group chairs.
Chris Box: We do have capacity to add this to the Working Group items.
David Redekop (ADAMnetworks): I support this.
Esko Dijk: I assume this is in scope of the new charter? (Chairs: Yes)
François Michel (Apple) presented slides.
Éric Vyncke (Cisco): What happens if some servers support this new
option and others do not?
François Michel: Servers that do not support the new option do not echo
it back, and then clients retry using the old mechanism.
Ted Lemon: This is important work and I intend to contribute.
Esko Dijk: I am a co-author on this draft and would like to see it
progress.
We can also do a “v2 SRP” RFC later on that includes this new option and
other improvements.
Ted: This document could officially update the SRP RFC, to make it more
easily discoverable by implementers.
Donald Eastlake (Independent) presented slides.
Discussion on purpose of presentation: Invited by the chairs. Work
currently doesn’t have a home. Work may end up in DNSOP; but unclear
yet.
Stuart Cheshire: Application-layer DNS Forwarder role seems not really
needed, IP can do the forwarding.
Ted Lemon: If both client and server need updating, you may as well
create a new option.
Ted Lemon: We may actually need Application-layer DNS forwarding for a
specific use case, but it would not use this mechanism. BIND also
supports forwarding, but not using this mechanism. It is unclear who
would use this.
Éric Vyncke (Cisco): Please don’t be overloading existing fields. In
principle, this work could be adopted here (there were discussions among
DNSOP & DNSSD chairs and ADs).
Alexander Clouter (coreMem Limited): We have implemented SIG(0) in a
server, based on
RFC 2931, which specifies that only one SIG(0) is allowed. It will
reject DNS messages with more than one SIG(0).
An email has been sent to the Working Group list about Erratum report
8560 for RFC “8765 DNS Push Notifications”.
Please review that email and respond.