Working group consideration of significant changes made to the text.
Presenter: Stuart Cheshire
5.2 Requester Behavior - failure recovery / retries specified
Eric Vyncke: if using SHOULD it needs to follow guidance for that term.
Stuart: Agree, will change to a plain English lowercase "should"
5.3 Server Behavior - update zone serial
6 Retransmission Strategy - writing for readability
Stuart: Reference-heavy text is not helpful to the reader, so have
proposed more readable versions.
Lease Limits
Stuart: I've inserted a sentence to allow operator configuration of the
lower limit.
8 Security Considerations
Stuart: I've added advice to follow industry best practices on flooding
attacks. This is the biggest change imho.
Tommy Jensen (in chat): LGTM
Matthias Kovatch - Additional text about UDP should be added.
Stuart: This is generic advice, not just about TCP, we just add some
references for TCP to get people started.
Esko (in chat): SRP has "3.2.5.5.1. Removing All Published Services" ?
Mark Andrews: (comment not captured)
Tom: Flooding attacks over TCP and UDP to avoid the confusion that it
might be only over TCP
3.3.3 FCFS Name and Signature Validation
Stuart: I've added explanatory text.
6.3 Arbitrary Names in SRP Updates - when not to select a different name
Stuart: Added text that describes how clients should handle a Refused
code.
5.1 Cleaning up stale data - misunderstandings
Stuart: Replaced "misunderstandings" with a paragraph.
Ted: What I mean by the word was cases where the client and server have
different understandings of the lease time. But your paragraph is
helpful.
Stuart: Need to cover the general case of clock drift.
Ted: I'm happy.
(Missed slide)
3.3.6 Optional behavior
Stuart: Easier english.
Appendix C sample config
Stuart: The config was broken re key ID. It should now be fixed.
Ted: We did a thorough effort to address RFC Editor concerns which has
made it much more readable.
Including report of hackathon implementations
Presenter: Ray Bellis
Ray:
Useful development at hackathon. Minor issues discovered. I've made
clarifying updates to draft (now -07). Now some text that clarifies that
recursives MUST go and find answers to all of the QTYPEs before
responding.
Stuart: It's up to you if you want to improve RFC references [by
spelling out what they are about].
Tommy Jensen: I was part of hackathon. We got client and server working.
Think it's ready for WGLC.
Chris: It's a good sign to have running code. Unless told otherwise
proceed to working group last call on that.
Florian: Get some feed back from the list and then do a last call.
Presenter: Esko Dijk
Slides
Special case A: Advertising Proxy(1) missed the Probe/Announce
Ted Lemon: The server with the stale data should see a response from the
server with the recent data. When the client sees a response with more
recent data (sent later in time) it should be able to use it.
Esko: Seeking clarification from Ted on what happens when newer data is
seen.
Ted Lemon: An mDNS client (unaware of TSR, ed.) that doesn't use the new
response is broken and has an incorrect implementation.
Special case B: SRP client attached to AIL
Ted Lemon: The advertising proxy has a registration with TSR. The
expected outcome is that as soon as the mobile (SRP) client connects to
Wi-Fi, the client will probe, and the proxy is going to announce the
service (with TSR) and so the advertisement by the mobile would fail.
A very interesting corner case that we need to talk about.
We can expect the mobile to be aware of TSR maybe for this case; it's a
kind of 'special' device.
Esko: right, special in the sense that it can connect to multiple
network technologies.
Esko: to create an issue and further talk about it.
Special case C (labelled A in slides): Fast SRP replication
Ted: it should work correctly due to the implementation. The TSR is only
between client and first SRP Registrar.
So the TSR value gets replicated along by SRP replication, it will be
identical for all Advertising Proxies no matter how short or long the
replication process takes.
Ted/Esko: action to check if the replication of TSR is described in the
SRP replication draft.
Presenter: Ted Lemon
Slides (Page 2)
Ted: Implementation mostly complete. Would like to see this in
Openthread.
Ray: We should go ahead with early allocation.
Action point: Chairs to raise this.
Ted: Version compatibility is an issue. In some cases we need to arrange
for the highest version to win as can't interoperate safely with the
lower version.
Ted: Can't progress without an implementation.
Presenter: Gautam Akiwate
Slides
Gautam: Want to allow services to share ALPN, e.g. to indicate if they
support HTTP/2 or 3.
Tommy Jensen: Drop mention of IPv4 and IPv6 in the drafts and have the
clients instead request that. Suggest use of Multiple QTYPEs. You'll
still need multiple queries but it would reduce the total number.
Another minor note: Section 4 does not walk through the steps in
chronological order in terms of time and made it hard to follow.
Ralf Weber: (comment missed)
Stuart: Following up on Ralf's concern above. The rules have to be laid
out with will take time before seeing the light of the day in real world
implementations.