IETF 97 - Homenet Wednesday, November 16th, 2016 13:30-15:00 Afternoon Session I Grand Ballroom 1 Administrivia (5m) WG Status Update - Chairs (5m) New Drafts: - draft-ietf-homenet-dot-00 - draft-ietf-homenet-redact-01 Other Drafts: - draft-lemon-homenet-naming-architecture-01 Drafts on hold pending other docs: - draft-ietf-homenet-hybrid-proxy-zeroconf-02 (expired) - draft-ietf-homenet-front-end-naming-delegation-05 (updated) - draft-ietf-homenet-naming-architecture-dhc-options-04 (updated) Ray Bellis: When speaking at the microphone please remember to state your name and affiliation. Dave Thaler: Why affiliation? That's not customary for IETF meetings. Ray Bellis: When speaking at the microphone please remember to state your name, and affiliation if you choose. ---------- Naming Architecture and Service Discovery (60m+) Special Use Domain name for HNCP - Pierre Pfister - draft-ietf-homenet-redact-01 - draft-ietf-homenet-dot-00 The first document will update RFC 7788 to change it to say ".home" is not the default name. The second document will update RFC 7788 to change it to say ".homenet" is now the default name. Dave Thaler: You have good reasons why you need a default name for the devices. None of those are good reasons that the name has to be a TLD. Pierre Pfister: The user-friendliness consideration makes a TLD more attractive. Dave Thaler: I completely disagree. The name ".homenet" is no more user-friendly than ".home.net" Pierre Pfister: I disagree. The name ".home.net" is not as user-friendly as ".homenet" Ted Lemon: It does have to be a TLD, or under ".ARPA." If it's under some other existing TLD, then the owner of that existing TLD will most likely have something to say about it. Ted Lemon: Now you're moving towards my preferred solution. Dave Thaler: Before we argue what the specific name is going to be, we need to decide where in the namespace it should live. Will it be at the root, under "net", under "ARPA", or somewhere else? Ted Lemon: We tried to get ".local.ARPA" ten years ago. That was rejected at the time. I don't think there's any choice we could make here that won't have some minority who will then speak out opposing it. I think that's a tremendous waste of time. This is an obviously good solution that will work. As far as we know, ICANN has no objection to us using ".homenet" as the default domain for these devices. I would hate to have this turn into a rat hole. Personally, the name ".home.ARPA" sounds weird to me, but do we really have to waste another month talking about this? Mikael Abrahamsson: What is the chance this will be rejected? Pierre Pfister: ICANN has received *no* applications for ".homenet." Not a single one. And it is not on any list of potentially harmful TLDs. Ray Bellis, speaking as chair: There are three options: 1. Register a Special Use TLD. 2. Register a Special Use name that's already indisputably under IETF/IAB control. As far as I know, the only name that would meet this requirement would be a name under ".ARPA." My personal position is that ".home.ARPA" would not be appropriate. It may be alarming to some home users, particularly outside the USA, to be seeing the acronym for the United States Defense Advanced Research Projects Agency appearing in the names of their home devices. 3. Register a Special Use name that falls under a name currently under the control of a commercial registry. My personal preference is for option 1. Andrew Sullivan: There is a fourth option: We could declare a special use name that falls under some other TLD. In principle that would be possible, though it would be a fabulously bad idea. But, in principle, the reserved name doesn't have to be a TLD. I'm not sure we have the right expertise in this room to talk about user experience considerations. Personally, I don't care whether this is ".homenet" or something under ".ARPA." ARPA is indisputably under the control of the IAB. If you want a name under ".ARPA" you only have to negotiate with the 13 people on the IAB. To get a TLD under RFC 6761 rules you need IETF-wide consensus that it's a good idea. Suzanne Woolf: If what you want is to avoid a name collision, a name under ARPA can meet that requirement. Peter Koch: You could use a name that falls under ".ietf.org." If you want a name under ".ARPA", then RFC 3172 defines the policy for that. If you are considering the time this will take, then you may want to include a consideration of how long it may take to work through the appeal that may appear if you try to use a top level domain. That can take a long time. Ted Lemon: Are you planning to file an appeal if the IETF has consensus to do this? Peter Koch: There is a likelihood that there might be an appeal. Ted Lemon: Do you know of someone who might do that? Peter Koch: I do not know of somebody who would do that. Ted Lemon: So, you personally do not intend to file an appeal? Peter Koch: That is not what I said. It's just that I do not know of anybody who would do this. I may or may not file an IETF appeal. Ted Lemon: If you intend to file an IETF appeal, then you already know that you intend to do that. Peter Koch: But if I don't know that I intend to file an IETF appeal, then I don't know that I intend to do it. Ted Lemon: They why are you saying something about it at the microphone? Peter Koch: Because, I said, there is a certain likelihood. Ted Lemon: Are we aware of any difficulty that occurred (other than a long stupid discussion on the IETF mailing list) arising from the allocation of ".onion"? Did ICANN object to the allocation of ".onion"? Does anyone know the answer to that question? Andrew Sullivan: The answer to that question is (a) strictly irrelevant, and (b) involves subtlety that we don't want to have. Ralph Droms: I want to make sure everyone is fully aware of the RFC 6761 process, which is that the IETF publishes a standards-track RFC, like the one we're discussing here. The decision is made by IETF consensus, not by an individual or small body that decides "yay" or "nay". If the RFC has consensus, then it is approved and published, and the name is recorded in the registry. Ralph Droms: My suggestion is that we skip the question of whether this is a TLD or not, and what the specific characters of the name should be. We should finish the rest of the discussion, and then we can figure out what the name is. Mark Townsley: That's just kicking the can down the road. Ralph Droms: No, it's not. Right now we're just wasting time on this discussion of what string it should be, before we've decided how it should work. Let's figure out how it works first, and then pick the name. Mark Townsley: That's RFC 7788, already published. We have three years of running code, demos at Bits 'n' Bites, an two independent implementations. That's all been done, just with ".home" instead of ".homenet". And that use of ".home" was reviewed and approved through the IETF process. Ralph Droms: I don't think that use of ".home" got sufficient attention during the IETF process. This time around we need to make sure it gets a thorough review. Mark Townsley: That's what we're trying to do. Until we tell implementers some other name to use, they'll continue using ".home". Ralph Droms: I'm not saying, "Never pick a string." I'm saying, "For the time being let's not spend lot of time talking about the string. Let's get the rest of the issues dealt with first." Mark Townsley: We have three people queued up at the microphone. How many of you are standing there to talk about the choice of the string? [All three raise their hands] Mark Townsley: All three. Ralph Droms: I was merely making a friendly suggestion, but I will not stand in the way of consensus. Ray Bellis: We do not intend to rat-hole on this indefinitely. We have a fair amount of time in today's session. I would rather we understand the issues now, and get a decision, than end up having the second document drag on for months and months, thereby holding up the publication of the redaction document. We should wrap up this topic, and get rough consensus on what to do. Mark Townsley: We've been told by our AD to move very fast on this. Jason Livingood: User-friendliness should be the goal, not political expediency. Using ARPA may be politically expedient, but it's not user-friendly. We should not use a name under ARPA. That is not understandable to an average user. Avoid extra dots in the string. Use something simple, like ".home" or ".homenet". Mark Townsley: When users see something they don't understand, often they'll do a Google search to learn more. If they do a Google search for "ARPA" and find that it's an Advanced Research Projects Agency controlled by the US Government, many users will be alarmed by this, and we may get a bunch of angry and misinformed emails on the IETF mailing list from them. Tim Chown: We know the IAB controls "ARPA", so that's the easiest thing to do. And, remember, not all computer users are English-speaking, and for them "home" is no easier than "home.ARPA". Mark Townsley: [Said in a joking tone of voice] We could use ".maison" and ".casa". Tim Chown: [Said in a joking tone of voice] There is a Unicode symbol for a house (U+2302). We could use "[unicode home char].ARPA" Ray Bellis: Yes, but on most keyboards it's hard to type. And ".casa" is already allocated. [23 September 2014, see ] Pierre Pfister: I would prefer to avoid "ARPA" because I don't want users to see this in names. The IETF Leadership has agreed to move fast on this. I don't want to hear people saying, "Maybe we cannot use '.homnet'. Maybe we should use ARPA because if we don't then someone will appeal." We are going to do this fast, and we'll know in a few weeks whether there is an appeal or not. Even if someone appeals, we will have the technical document done. Right now we have to agree on what we want, not be fearful of things we don't know and can't control. Ted Lemon: I agree with that 100%. RFC 6761 describes the allocation policy. People can object based on technical grounds, not just because they don't like the chosen name. If you have a objection on technical grounds why a given name is a bad idea, then we have to address that objection, or use a different name. But if you don't have any technical reason why a name is the wrong choice, then there's no basis for any appeal, and there's no basis for saying there isn't IETF consensus to use that name. In that case, a bunch of people agree on the use of the name, and the only people who object don't have any good reason why they're objecting. The IESG could legitimately refuse to approve the allocation, if they feel that's appropriate. Ray Bellis: The IESG has already debated this extensively, and they are expecting us to deliver to them a document that reserves a name that is, in effect, a top-level domain name. This is not going to be a surprise to the IESG when it arrives. Avri Doria (Co-chair, ICANN New gTLD group, speaking here as an individual technical contributor): This is a good time to do this, because it's going to be at least a year before ICANN opens the floodgates for allocating more top level domains. If a name is on the RFC 6761 Special-Use Domain Names list then the ICANN policy is that ICANN can't touch it. That makes putting a new name on that list right now a safe thing to do. The fact that it's a neologism, a new word, a word that's not already in use makes it less likely that anyone would complain about it at all. I have asked that there be a communication between the two organizations when this happens, just to make sure. It's a relatively safe name, it's a relatively safe time. In a year or two, when ICANN opens the floodgates, it will get a lot less safe. Dave Thaler: If average users never see these names, then having "ARPA" in them is not a big deal. Dave Thaler: I agree with Mark Townsley and Ray Bellis that there's already an RFC documenting the behavior. RFC 7282 (On Consensus and Humming in the IETF, by Pete Resnick) says that consensus is achieved when all issues have been addressed, though not necessarily accommodated. The issue of whether the name needs to be a TLD or not has been raised many times, but I've never seen consensus called on it. I think we need to have an explicit decision about whether or not it will be a TLD. Bob Hinden: I agree with what Avri Doria and Dave Thaler said. I think we should use a TLD for this, and I think ".homenet" is just fine. Just do it. Don't take forever. Stuart Cheshire: I think we should have one document instead of two. It should be a very short document, that just says, "Don't use '.home'; use '.homenet'." That tells developers what to do. Currently, if you buy a home gateway like a BT Voyager, it's using ".home". They will continue to use that name until the IETF publishes a document recommending a different name. They will probably carry on using ".home" anyway. So, now, we will have polluted two top level names instead of one. But, if that's our decision, let's just do it, and publish it. Let Peter Koch file his appeal. We'll work through the whole process, however many years that takes. We need to start the process, because the sooner we start the process, the sooner the appeal will be filed, and the sooner we can deal with it. Ray Bellis: We do realize it could be done with one document. Stuart Cheshire: If this is two documents, the redaction of ".home" will be published, and the allocation of ".homenet" will never be published. Either way, it will be one document that's published. We're just debating what will be in that one document. Ray Bellis: The allocation document will be normatively referenced from the redaction document. Mark Townsley: Actually... Ray Bellis: We have agreement from our AD that the two documents will be bundled. Stuart Cheshire: If they're bundled they don't need to be two documents. The only reason to have two documents is if in reality they won't be bundled. That's why there are two documents. So one can die. Terry Manderson (AD): Let's stick to Dave Thaler's questions. I want two documents. We need the redaction document for expediency, to make it clear that the IETF is not allocating ".home". That has to happen. Mark Townsley: Will the two documents be advanced together? Terry Manderson (AD): I want to see these go forward as quickly as possible. Mark Townsley: Clustered? [No resolution on this. Moving on to new topic.] Ralph Droms: There has been some discussion in the chat room. There are two independent issues. 1. The choice of Special Use Domain Name. 2. The special name resolution mechanism it triggers. We can decide (1) quickly, and then take our time on (2). I disagree that RFC 7788 fully specifies (2). RFC 7788 specifies how the name is carried around, but not what it's for. The difficulty is that the RFC 6761 rules don't allow you to reserve a name without saying what it's reserved for. Also, it is odd to do this at a time when Ted Lemon's naming architecture document is just getting started. Ray Bellis: The allocation document will specify both the reserved name, and the special name resolution mechanism it will trigger. The special name resolution mechanism will be normal DNS resolution. The name resolution mechanism is independent of HNCP. We expect Ted Lemon's naming architecture will eventually have an internal unicast DNS component. Mark Townsley: There are already implementations of RFC 7788. It defines how to configure the network, and the defaults that are needed. Future documents could continue to improve on RFC 7788. Pierre Pfister: Speaking as an author of RFC 7788, HNCP includes naming specifications. We have implemented it. It went through the IETF review process. It describes how to do service discovery, and naming, in a home network. I can agree that there might be some need for clarification, but we do have a working implementation, and a specification. Ralph Droms: What do you mean by a working implementation? You have a working implementation of HNCP that carries configuration information around. Pierre Pfister: Yes, and it does naming and service discovery. Mark Townsley: HNCP will carry a configured domain, but if no domain is configured, then HNCP does not carry that information, and each HNCP node will assume its own default, so for it to work, the default has to be the same for all nodes. Ralph Droms: If no domain is configured, is a default domain communicated to HNCP nodes? Ray Bellis: Section 8 says if no domain has been manually configured, then no TLV is sent. Ralph Droms: I think there is an internal inconsistency in the document then. Ray Bellis: The intent is that in the absence of the TLV, each HNCP node assumes a default domain, which therefore must be specified to be the same for all nodes. Ralph Droms: I'm not sure the text is complete on that. Ralph Droms: I disagree that RFC 7788 fully specifies service discovery. I posted an erratum on that. I think it assumes a Hybrid (Discovery) Proxy, but it is vague on the details. Pierre Pfister: I agree. There is need for clarification. That's why Ted Lemon is working on the naming architecture document. But that is out of scope for this discussion. The high priority task is to update RFC 7788 with new text specifying a new default name. RFC 7788 reserved a domain name without having a formal RFC 6761 Domain Name Reservation Considerations section. To properly reserve a domain name under RFC 6761 rules we need a Domain Name Reservation Considerations section. So we're going to have a formal RFC 6761 Domain Name Reservation Considerations section, but it's not going to give answers to questions that are already unanswered in RFC 7788. Answering those questions is the job of Ted Lemon's naming architecture document. Mark Townsley: We might answer those questions in a future update to RFC 7788, but we don't have time for that now. Ralph Droms: I was told previously that the rules, saying what the special name is for, are specified in RFC 7788. Are they there? Is HNCP complete or not? Mark Townsley: No piece of work is ever truly complete. We may continue to update RFC 7788 for a long time. [Moving on to technical considerations.] [See Slide 4] Stuart Cheshire: I think requiring locally-named services to be only services that are inaccessible outside the home is an unnecessary restriction. It says that any service with a NAT mapping making it accessible from outside the home is not allowed also to have a local name. Some services in my home are only usable within the home. Some services in my home are also usable remotely. They all have local names. Pierre Pfister: I agree. The sentence could be reworded. A service can have two names. Barbara Stark: RFC 7788 doesn't talk about home networks. It talks about internal and external interfaces, of a router. It says you don't let things escape out external interfaces. You don't know if a router's external interfaces is a boundary of a home network, but it is an external interface. Pierre Pfister: We did not want the application for ".homenet" to be specific to HNCP. That's why it uses vague words. Ray Bellis: This document just defines a domain for internal use. It doesn't have to be used with HNCP. You can use this name without HNCP. But HNCP requires that there be a default name. Hence the one-way dependency. HNCP requires the default internal name document. The default internal name document does not require HNCP. Barbara Stark: There is nothing in any home network that has any concept of where the boundary of that home network is. There is nothing that can enforce this. Ray Bellis: Our fifth charter area is security. We do not yet have a good security architecture for a home network that tells us precisely where the edge lies. Michael Richardson: I read point 1 as saying that when I look up "something.homenet" it had better not give me an address of something that's outside my home. I agree that the wording is poor. Pierre Pfister: Please check the wording in the document itself. Stuart Cheshire: I don't understand why Barbara says there is no way in today's world for anything to know where the boundary of the home network is, when there are countless millions of home gateways shipped that already do this. Devices like the BT Voyager home gateway run a DHCP server, configure clients with the address of their DNS resolver (the BT Voyager home gateway itself) and then the BT Voyager home gateway answers queries under the TLD ".home". It does not leak those queries upstream, to the ISP's name server, or the root name servers, because it answers them. Barbara Stark: Hopefully. Stuart Cheshire: You say, "hopefully", like there is some mystery about how software works. There are *other* gateways, that don't answer ".home" queries, and it is those gateways that leak queries upstream, and they do that because we don't have an RFC saying they shouldn't leak those queries upstream, and that's what we're all standing here debating. All of the gateways that don't answer ".home" queries do leak them upstream. All of the gateways that do answer ".home" queries don't leak them upstream, by definition, because they're answering them. They don't have a random number generator in the software that makes it answer the queries half the time and leak them the other half of the time. They answer ".home" queries 100% of the time, and this is useful for the customer. The customer types "voyager.home" into their web browswer, and they get the configuration page for their DSL gateway. It saves them having to remember and type IP addresses. With these gateways, the users get a benefit, the queries don't leak, and it's very obvious where the boundary is -- it's the thing that's answering the query, which was configured in the client via DHCP. This has existed for ten years, and yet we're standing here saying it's not possible and it can't be done. There's a big disconnect with reality here. Wes Hardaker: The IETF has started having an "Operational Considerations" section in documents, and I suggest we have one in this document. The IETF should specify that *all* recursive resolvers should answer ".home" queries locally, and not propagate them upstream. Mark Townsley: I think the document already says that. Ray Bellis: Yes, it's in the document. Pierre Pfister: It's a "MUST". Mark Townsley: We need to allow time for the discussion of TLD or not. Ralph Droms: The document talks about "services". Do we mean any FQDN ending in ".homenet"? Pierre Pfister: The document uses the phrase "hosts and services". Ralph Droms: Why not just use the phrase "name". Pierre Pfister: I think that's what the draft says. Mark Townsley: We are happy to make edits to get that right. Ray Bellis: Ralph, please re-check, and if it looks wrong, please send text. Mark Andrews: Unlike ".local" or ".onion", this is using the DNS, so DNSSEC has to work. Validating clients inside the home are going to expect these names to validate. That requires that, whatever name we chose, gets insecurely delegated from the parent zone. Ray Bellis: Mark, it's in the draft. Mark Andrews: This slide says "No leaks". Homenet DS queries will go upstream. Ray Bellis: There is already an instruction in the draft to create an insecure delegation from the parent. Mark Andrews: I'm happy with that. Just don't say that there will be no leaks for homenet. You need a qualifier on that. Tim Chown: Verisign says that they get 27,000 hits per million to the DNS root for ".home". So, ".home" queries do currently leak. Mark Townsley: [Said in a joking tone of voice] Boy, we should have written an RFC saying not to leak those queries! Ray Bellis: To be fair, many of those leaks are because the DHCP configured the clients to use ".home" in their DNS searchlists. Many home gateways will induce clients to issue queries in a domain like ".belkin" even though the home gateway itself is not answering those queries. Stuart Cheshire: Tim, you cited a fact, but you didn't tell us what conclusion you draw from that fact. Tim Chown: Clearly there are a number of ".home" queries hitting the root. Maybe they are non-BT customers. Stuart Cheshire: It's important when we see information like this that we dig below the surface and ask ourselves what is going on. What I believe is going on, in many of these cases, is that there is a user, at home, who has a home gateway that is doing this trick where it looks at the hostname in the DHCP request, appends ".home" on the end, and then the home gateway answers requests for that "hostname.home", giving the devices, assigned IP address. Now your Epson printer is reachable at the name "Epson.home" The user sets up a print queue on their PC, to print to "Epson.home", and it works fine when they're at home. When they're away from home, at a coffee shop, or the airport, or this hotel, when they print, the PC cannot resolve "Epson.home", so the print job sits in the print queue, until they get back home, and then it prints. And that may be exactly the behaviour the user wanted. Because we don't have an RFC telling the coffee shop, or the airport, or this hotel, to blackhole those ".home" queries, they have to hit the root. That is one of the paths that causes those queries to be hitting the root. If other people have theories about where these queries are coming from, that would be informative. Right now I have heard no other analysis of where these queries might be coming from, just a lot of pointing at the ".home" document. Joe Hildebrand: The redact document should be Standards Track, not Informational. Mark Townsley: That's a mistake; we will fix it. Dave Thaler: Can we have a consensus call on the naming topic? Mark Townsley: Should the WG, with this document, request a TLD right now? Loud hum in support. Very weak hum against. Mark Townsley: We will take this to the list, to confirm the decision. ---------- Architecture Draft next steps - Ted Lemon - draft-lemon-homenet-naming-architecture-01 Mark Townsley: You seem to have a long wish list of "things that would make home networks better" that are not naming per se. Ted Lemon: They're listed because they may be necessary in support of a richer naming architecture. We need to be properly informed of the extra work that could come along with a richer naming architecture. Mark Townsley: You mention an HTTP-based API. Do we also need a Netconf/Yang management API? Ted Lemon: I'm talking about an API that app writers can write to. Making them learn Netconf/Yang would be a burden. We may also want to provide a Netconf/Yang management API too, but that would be solving a different problem. The ISP could automatically provision each customer with a globally unique DNS domain, but we still want to allow the user to override that with their own choice. We want to allow provider-independent names. Secure delegation will require additional exchange of key data. If we do this right, we should use the same protocols we use elsewhere on the Internet, and that includes DNSSEC. I have no idea of the working group wants DNSSEC, and if it doesn't then perhaps I'm wasting my time writing documents about it. Why should we care about DNSSEC? I think the demand for security in the home is likely to increase, and we should be ready for that. [See Slide 4] Stuart Cheshire: Ted, you say that the Hybrid (Discovery) Proxy doesn't work with global DNS names. In fact, it does. It can use a local DNS domain in the case of a user who doesn't have a suitable global DNS domain they can use, but I can also work equally well with global DNS names. Ted Lemon: That could be used for a DoS attack. Stuart Cheshire: So, your concern is allowing queries from outside to enter the home? Ted Lemon: The server in the home should be a hidden primary, and do zone transfers to an external server. Stuart Cheshire: I think this work sounds extremely ambitious. You're requiring ISPs to offer the service of automatically provisioning each customer with a globally unique DNS domain. Ted Lemon: The ISP doesn't have to provide that service. It could be anyone. Stuart Cheshire: So, you're proposing a service that provides customers with a globally unique DNS domain without them having to go to a conventional DNS registry like GoDaddy to do that. Ted Lemon: It would be nice if that were available. GoDaddy could probably make some money doing that. It would be very simple. They could charge $5/year for that. Stuart Cheshire: I think GoDaddy already offers a service where you can register a globally unique DNS domain and pay them an annual fee for that. Ted Lemon: Yes, you could register a globally unique DNS domain, but we want something lighter weight than that. Ray Bellis: A service provider could have a second-level domain of their own, and sell subdomains of that. Bob Hinden: Expecting users to do something complicated is not going to work. It has to be simple and automatic. I'm not sure DNSSEC helps home users that much. I don't see a lot of value in bringing DNSSEC here. Michael Richardson: You asked if the working group wants DNSSEC. My answer is that if the zone is never queried by anyone outside the home then DNSSEC is more hassle than it's worth. If the zone is never queried by anyone outside the home then I'm not sure it's worth having any of it. If we're going to do this, we should do it well. I think this could end up complicated and difficult, but I also think it could be automated pretty well. I think the only reason we don't hear people screaming for this capability is that most people have not idea that it's possible. Here are the IETF we know how to do this. Other users have no idea. But... this is not on the critical path for homenet. We need to accommodate this work, but not depend on it. Ted Lemon: This work is only useful if we can make it easy to use. Mark Townsley: Do we need a threat analysis document? I think we do. Mark Andrews: Having a home gateway push out a zone is trivial. We just need to define a protocol to do it. There are already home gateways today that update their IP address using Dynamic DNS and TSIG. It's not hard to do this. The user just has to configure their device with the name of their DNS domain, and the usename and password (TSIG key name and data) to give them permission to update it. Harald Alvestrand: Do not assume that my home network is not full of hostile devices. It is full of hostile devices, including all my friends' iPhones, and my toaster. David Schinazi: The moment you ask a user to configure something, you have failed. Ease of use is important. The good thing with Bonjour is that you click the print button, and you see the list of available printers. But today Bonjour only works on a single link. This is why I like Homenet and HNCP. You don't have to configure it. You can't configure it wrong. You just connect the routers, and it works. If it automatically does a zone transfer outside the house without the user's knowledge permission, that could be a privacy leak. For power users this is okay, but it should not be automatic. James Woodyatt: Why do you need a management API? Is there an app that talks this standard protocol to talk to Homenet routers? Would that app let me manage my DNS zone? Who's going to implement that app? OS vendors? How do I get this app? Does it come with the router? Ted Lemon: It's just an Android or iOS app. James Woodyatt: Most people will not find and install that app. Ted Lemon: Some people already want this functionality. And the number of people who need this functionality is going to increase over time. James Woodyatt: There is a chicken-and-egg problem here, of who is going to implement which parts. Where is the incentive for someone to write this app? Where is the incentive for router vendors to implement this protocol? Ted Lemon: I think this will get written by the Open Source community, not by some vendor. Initially people who want this will be early adopters, but later more people will want it. Mark Townsley: Our meeting time is over. Ray Bellis: What are our next steps on this document? Ted Lemon: We should start off with a design that allows us to do whatever is available today. I think the Hybrid Discovery Proxy, if we set it up right, Will allow us to add an authoritative server later, if we want to. Ray Bellis: I suggest a new individual update of the document, which starts at the baseline, while allowing for future expansion into full DNSSEC signed distribution. Ted Lemon: I think the consensus is that that is the right thing to do. Ray Bellis: Can we get that done early before the next IETF? We want something that we can call for working group adoption before the next meeting. Mark Townsley: Thank you everyone.