Minutes interim-2021-homenet-01: Fri 14:00
|Meeting Minutes||Home Networking (homenet) WG|
|Title||Minutes interim-2021-homenet-01: Fri 14:00|
Homenet Interim Meeting
Friday, April 23, 2021
Chairs: Stephen Farrell, Barbara Stark
AD: Éric Vyncke
- Administrivia: Agenda bashing, notes, attendance
- draft-ietf-homenet-front-end-naming-delegation-13: Simple Provisioning of
Public Names for Residential Networks
- draft-ietf-homenet-naming-architecture-dhc-options-10: DHCPv6 Options for Home
Network Naming Authority
- Where to go from here
Administrivia: Agenda bashing, notes, attendance
Do stub network discussion in another interim at late May. Ted will start discussion on mail list to get some momentum before the call.
DNS Outsourcing Infrastructure (Daniel)
Slides: DNS Outsourcing Infrastructure
Éric (no hat): Maybe not include DoH because it doesn't support transfer option?
Ted: Has anyone implemented?
Daniel: Yes. Ray implemented.
Michael: I ran Ray's code. I want to create different client implementation but haven't yet.
Ted: So, Michael, you believe it works?
Ted: In Figure 1 chart -- this is a bit hard to read. You don't mention that IN ADDR zone can also be done this way. Also, it's not clear what relationship is between home network zone and HNA.
Michael: We can add these by making figure taller. And add lines to connect components appropriately.
(Carsten, in chat): Make that a separate diagram
Ted: What about user ability to redact things they don't want public?
Michael: The idea is that this would be opt in (so no need to redact, a priori). The convenience is they don't have to copy IP addresses and when IP addresses change, they get updated. I would also expect it to filter out privacy addresses.
Daniel: I think we're discussing those points in the draft. But if there is more, we're happy to have those.
Ted: I was asking because in diagram you only mention public homenet zone and not private. But diagram is already complicated.
Michael: I'm not opposed to discussing the private zone but am worried it would actually increase confusion.
Ted: Yes, I agree that managing the private zone would be out of scope for this doc.
Michael: If we put private zone in box by itself and show it is unconnected to all, would that be ok?
Ted: What I'm really trying to call your attention to is that devices in the LAN won't always be querying the public homenet zone. They'll likely query private homenet zone. And public is subset of private and gets updated from private?
Daniel: I get your point. I think that's feasible. We'll see what we can put in diagram. I think there is also text on that.
Ted: And temporary addresses aren't advertised, so you won't see those.
Stuart: That's right. They aren't published as addresses for inbound.
Ted: So no need to filter.
Michael: I was thinking that if they showed up, we would filter.
Ted: But how would you know?
Michael: Good point. But there are some patterns that we recognize. Like LLA and ULA.
Daniel: Does mDNS use any other non-private IP?
Ted: mDNS will always use LLA. It does also use ULA. So filtering of ULA is relevant.
Ted: You never say what HNA is in DHCP document. You should include that.
Stephen: Should we discuss what to do about WGLC?
Daniel: We can.
Stephen: Other technical comments, first?
Erik Kline (from chat): What is the auth story here?
Daniel: We had long list of authors for historical reasons.
Michael: Author or authentication?
Erik (from chat): Authentication
Michael: People want to be able to go to 3rd parties. By having blob that can be copied and pasted, we're making it possible to avoid typos. But ther is also OAUTH possibility. This is all configuration, but also explicit authorization. Then we expect this to be validated in TLS. So synchronization channel is DNS over TLS. Ray convinced us this was easier to do over DNS.
Erik: How does ISP trust the homenet to do the update?
Michael: There is the zone transfer. The better question is how the homenet trusts the ISP to do the AXFR. That is all set up in the synchronization channel. Certificate is provided then.
Barbara (no hat): Should you have IANA considerations for the various transport options (DoT, Do53, etc.)?
Michael/Daniel: We'll look at that.
Ted: And you should only list the ones you want used. If you don't want Do53 used, you shouldn't list that either.
Daniel: Not a problem to add. Should we go for specification required? I used 2 bytes.
Ted: Specification required should be ok, since you do want people to document what they're doing.
Stephen: Other technical comments? Hearing none, we will go on to process.
Stephen: How many people have read this? Please reply in chat. / There were 2 yes and 2 partial/quick scan.
Stephen: How many people will review? / 3 people.
Stephen: Does anyone think this would be a bad idea? / There was no-one who said anything.
Éric: When you issue WGLC in homenet, you could copy DPRIVE and INTAREA and the INT area directorate for DNS and DHC for DHCP options.
Stephen: Then we will let Eric use his influence to get additional review and go forward with WGLC?
Daniel: We'll update the document. Expect that in next few days. But I don't think that will impact WGLC.
Stephen: We don't want update after WGLC starts.
Daniel: Then wait a week for update and start WGLC.
Stephen: Stub resolver discussion noted in intro.
Ted: And I will update the draft.
- Erik Kline, Google
- Stephen Farrell, Trinity College Dublin
- John Border, Hughes
- Carsten Bormann, TZI
- Ted Lemon, Apple
- Stuart Cheshire, Apple
- Éric Vyncke, Cisco
- Chris Box, BT
- Michael Richardson, Sandelman Software Works
- Barbara Stark, AT&T
- Daniel Migault Ericsson
- Oliver Borchert, NIST
- Rongli Sun, Google
- Suvesh Pratapa
- Martin Turon
- David Millman
- Kazunori Fujiwara, JPRS
- John Border
- Ray Hunter