DNSOP Minutes Session One Date: Wednesday 6 April 2016 Time: 16:20-17:20 ART (19:20-20:20 UTC) # Paul Hoffman(PH) - resolver-priming draft moving along no comments # Olafur Gudmundsson(OG), roadblock-avoidance no comments OG --refuse any PH -- Are you suggesting both solutions go into document and we should do both? OG--yes # OG -- maintain ds Shane Kerr (SK) --my only concern with making this standards track is that I feel like the approach for adding the new DS, there are many options there, not very specific and clear OG --send text SK --document does good job of talking about various ways, don’t think there is a good answer for a single straightforward way of doing it. # Stephane Bortzmeyer (SB) --nxdomain cut Ted Lemon (TL) --please limit to the clarificaiton and not the normative language Dave Lawrence (DL) --asking the server to try to keep things consistent is unnecessary. eventual consistency is good enough. PH --the problem is that it does exist in the cache, that is what the cache believes, saying it doesn’t exist unless you do something more doesn’t make sense, just say may. We all know what must means. Should means MUST except in these cases. You could turn it into may or is a good idea. Dan York -- maric fabruza. dig … returns nxdomain. if resolvers abide by this the whole akamai dns will be off. Dave then wrote, in a signed zone, it would work with akamai, our problem is limited to unsigned zones. SB --if you have a name server that is broken on ent, in both cases we have a problem. when we have broken servers we have problems. Shumon Huque (Verisign) --one thing mentioned during that long train of messages that is not currently in the draft is the option of performing NXDOMAIN only on a cache miss. On a cache miss you have to perform an upward search anyway. So probably that option should be discussed explicitly in the draft. Section 2 says should should should do this, only in a later section, 5, it says however if you have a good reason to ignore this advice because your cache implementation is not a tree, but I think there is a step inbetween that is a reasonable option that could be discussed. SB -isn’t it the same, the case where there is a cached response. Shumon --I’m pointing out that it isn’t currently in the document SB --it is in my head but not in the document Tim Wicinski (TW) --should go into 02 document. TW --authors will do a 02 with these comments and a few others, then take it to the mailing list and see what happens, then go to wglc. Shumon --implementation sections, they talk about implementations, they say remove before publication. I think it would be useful to continue to have some information about the implementations SB --you never modify an rfc, can last a long time, always outdated. # Duane Wessels (DW) --edns key tag Warren Kumari (WK) -- one of the authors on a different earlier document which had it encoded in the qname and one of the issues that we discovered is if there is a forward which is unaware of this, client might send it through the forwarder, send it to whoever … this and that forwarder would appear to have the key tag. So we came up with the idea of a uuid, became even more complex, we became concerned and ran away. Mark Andrews (MA)--doesn’t need to be complicated. we want you to know the set of clients out there, which algorithms are actually in the trust anchors, so it doesn’t matter if it all comes through the same ip address. DW--I disagree, I think the IP address is useful. PH --we want to know. this is not just data we want to be sending around the DNS, there are people who will possibly make decisions based on this, so finding that information, having it show up in places where WE can evaluate it is important, so I wonder if it is a large recursor that we recognize, e.g . a busy TLD or root zone, I can recognize what a big recursor is, asking lots of sensible questioins, small recursor because it asks me every two weeks for something sensible, so I want an edns0 option. Ed Lewis (EL) --I also prefer edns0. why hex? everywhere else I see this key tag it’s in decimal. MA --hex is compact, and no separator. EL --as an operator this is not convincing. please don’t confuse us. DW --one thing I worry about, as you probably know, any time you look at data that comes in the root servers, it’s amazing, I would like to be able to differentiate a legitimate signal versus an unintentional signal. Otherwise something that happens to match this might be mistaken this for a legitimate datum. EL --I also wonder how I would trust, but don’t just give it a different way. Evan Hunt --I still favor qname, agree hex is overly clever, recommended decimal with punctuation. separate labels has problem with qname minimization. General comment, not sure current draft has a clear statement of what the goal is, but I think we should do what is minimal and fastest and meets the goal that we specifically have. wname does meet that goal without upgrading all the middleresolvers. if you use qname it’s just going to get passed along. Lars Liman --hex or decimal is a presentation thing, the thing that gets encoded on the wire should make technical sense. please standardize what’s sensible for the wire. MA --could do qname, then migrate. OG--pick one. hum on edns0 option hum on qname hum on gtxo WK --if you have edns0, it’s the recursor that sends the query to the trust point. If you have qname it’s the machines behind the thing that sends the query. so it depends on what you want to measure, might even want to do both. DW --I think there are some differences but overall you get the same data. You get the trust anchor key tags from both recursive and stubs/end machines. EH -presumably if you are a validating stub passing queries through validating resolver, queries would be sent from both, although potential that a qname would have been cached by the validating resolver. if passing queries tfrom validating stub through non-validating resolver, ??? WK --more concrete examples, 4.2.2.2, large recursove resolver, if not upgraded to support this, and I run a stub resolver that uses this, 4.2.2.2 will appear to have the new key tag. that will make it appear that 4.2.2.2 supports this and has the latest key. that was the concern. PH --I do not want to slow this down, but I would like to see lots of discussion on the list, and then can you ask the question of a, b, a+b, 0? TW --so holding off on the hums until we hash it out on the list OG --can we ask about not doing it? Should we kill this effort bc nobody has any clue what’s going on and value of experiment may be very low. lots of hums for continue, none for kill. OG --tim, can I ask you or Duane to ask explicitly on the mailing list the questions TW --yes, we’ll put together the questions and send that off, start that discussion that way. PH --a note for the room, if you care about nsec5, there’s going to be a pres in saag. # SK --dns over http PH --I would like to see both adopted, don’t see a reason …, would like to see the people review it. I was the one who brought up post versus get, because I was thinking of my model which was not the binary one. Fine for binary one to be post. Get with a body is known to invoke a lot of tears. I would strongly like you to do the well known, but slightly change, someone else might want to do dns over http with get, so if you wanted to get rid of your second bullet, because you don’t want someone in javascript to be putting together a dns packet, I would say somebody else such as me might do it a different wya, and only look at that group, and to me that is a strong argument for doing the survey document as well. John Levine --this is a disgusting crock, but it solves a real problem. having written production dns servers in perl, don’t share paul’s concern about writing in javascript. put this on the std track, people will will write one or two js things, that’s okay. Christuan Huitema (CH) --I don’t really want, my problem with security section, there is an issue there what happens if someone uses it in an enterprise network. that particular construct will go across firewall just fine, will let you browse your porn site from your work desk, despite your IT managers’ attempts to block resolution. SK -willing to add text or copy/paste what you send as recs for sec considerations for enterprises. I agree can be concern as with work of dprive. Christian--synchronize with dprive dan--what is wrong with wire messages, cost is dwarfed by transport cost, much more value to consumers to get easy-to-read dns contents. SK --don’t remember, my guess is pv did it on an airplane flight, and did it bc it was easy. SB --I remember discussing it with you, your answer then, the war system you can pass any dns request. if you define mapping, always the risk that something, unknown qtypes, will be missing fromt eh mapping. Dan York --at the hackathin this weekend sarah dickinson did an analysis of google’s offering, it’s in hackathon slides. SK --that’s actually a good example of the strength of this approach--there is no way to do a validating resolver with current google api, Lars Liman --do we have a problem statement? SK --yes Lars Liman --is this dnsop work? looks like a protocol mechanism. maybe dnsop has turned into dnsext. if so that’s fine, but if not might be better to put somewhere else. TW --until we hear otherwise from ad, it’s fine here. Robert Edmonds --application-octet-stream, any reason not to register the wire message format in mime media type registry? SK --no reason, happy to do that. Robert Edmonds --then you can use http content-type negotiation SK --that kind of thing scares me, not sure what the behavior is of web servers if they encounter unknown content-type PH --it’ll be fine SB --application type dns exists. DW --I agree with microsoft, the security statement is not just a protocol issue but also an intranet issue. not sure why we want to put everything on the internet on port 80 SK --because you block everything else. DW --I don’t think that should be our decision what they block. if people want to shoot themselves in the foot they should be allowed to. ---------- WG: DNS Operations (dnsop) Meeting: IETF 95, Buenos Aires Location: Buen Ayre C Date: Friday 8 April 2016 Time: 10:00-12:00 ART (13:00-15:00 UTC) Chairs: Tim Wicinski Suzanne Woolf *Session Two - Returning New Business draft-wkumari-dnsop-cheese-shop 10 min draft-fujiwara-dnsop- nsec-aggressiveuse10 min (Slides?) Chairs’ question for the room: Cheese-shop is a simpler proposal for the root zone. Fujiwara is more ambitious. Should we adopt both drafts? Shane Kerr: Consensus on list was not to proceed with cheese-shop. Warren Kumari: Cheese-shop is for the special case of the root zone. It’s a simplified case because the root zone changes very slowly, and it’s okay if a name doesn’t work for 8-12 hours. Wes Hardaker: Ólafur, how does your faking NSEC records (you are returning every rrtype) interact with these drafts? Ólafur Guðmundsson: The lying can be adjusted depending on the traffic patterns. I think we should focus on Fujiwara, and not on cheese-shop. Evan Hunt: Why can’t the Fujiwara draft be modified to say it may be applied to only one zone if you want? Kazunori Fujiwara: Both cases are important. Ray Bellis: So, what is our conclusion? Adopt only Fujiwara? Both drafts? Tim Wicinski: I wanted us to discuss both. I think the conclusion is we only move forward with Fujiwara. Ray Bellis: I agree, we should focus completely on Fujiwara, and not get distracted by cheese-shop. - (More) Possibly New Working Group Business draft-wallstrom-dnsop-dns-delegation-requirements, Levigneron 15 min (Vincent Levigneron presenting) Ralf Weber: I support adopting this document. We should focus on the delegation aspect, not zone transfers and DNS Updates. Paul Hoffman: I would love to see this adopted by the working group, but only if we remove almost all the “MUST”s and “SHOULD”s. There’s a real risk we could put a “MUST” or “SHOULD” in this document that’s not the same as the base document. This document should reference the base RFCs, and say, “Here’s our view.” It should be Informational, not BCP, because BCP is Standards Track. Don’t want to look like we’re re- doing any of the RFC 2119 language. Vincent Levigneron: It will remain as an Informational document. Dan York: I also support adopting this document. Paul, why remove most of the “MUST”s and “SHOULD”s? Paul Hoffman: Because there’s a risk of inconsistency between different RFCs. This document should have no requirements, and just reference the appropriate base RFCs. Dan York: I like having the definitive rules in one place, instead of having to hunt in different RFCs for them. It makes it much easier for implementers. Paul Hoffman: Then we’ll have to be very careful that we get it right here, and when we update RFCs. Sometimes the original RFCs don’t even use MUST/SHOULD language. We’d have to be careful, and this working group has not been good at that. Dan York: I think this is good work, that we should continue. David Conrad: I also strongly support this adoption of this document. I also like having the definitive rules in one place. That’s better than forcing people to go back and look at potentially conflicting documents. A summary document is extremely useful. If there’s a conflict, then that is a source of education and learning, and we can file errata if necessary. John Levine: I think this is useful, but should not be normative. It should reference previous RFCs. DNS is now enormously complicated. No matter how many eyes review it, the chance of this document being accurate and correct is zero. I’d rather have it be our best guess, with pointers back to the source RFCs, for people to read themselves. Stuart Cheshire: If we think this task is so hard that the DNS experts in this room working together have no chance of getting it right, how can we expect an individual reader to get it right? (Laughter from attendees in room.) Paul Hoffman: If this document is going to specify MUST/SHOULD language then it absolutely needs to be BCP, not Informational, *and* it must formally update that list of earlier RFCs. That’s been done in the past. If we’re going to do it we should go the whole way. Marcus Sanz: +1 to what Paul Hoffman just said. I support this document being a BCP. Andrew Sullivan: We tried to do this before, in the DNSEXT WG. It was a massive failure. Everyone looked at the work and said, “No way.” If we’re too ambitious, the WG will never complete the document. There’s a lot of unbelievably stupid beliefs out there, and we want to fix that. We should get a document out as soon as possible to correct that misunderstanding and misinformation. There’s lots of bad advice on the web. Do the fast and easy thing first. David Conrad: This is an operational document. We’re not trying to reconcile the DNS specifications into a single omnibus document. There are specific items that are experienced when one is trying to get DNS operational. Where we run into things that reflect into earlier base documents I think it’s appropriate to try to ensure that we get the answer right and if necessary if that conflicts with former advice that’s not a bad thing. Dan York (for Jabber room): A couple of people have agreed with Andrew Sullivan. Suzanne Woolf: I hear strong support to continue work on this document; significant debate about document status. Peter Koch: What is the noncontroversial set of tests? Stephane Bortzmeyer: The empty set. Vincent Levigneron: Many of the test are controversial. Of course the noncontroversial set is not large. A small document is better than nothing. Dan York: We should adopt doc now, decide status later. Suzanne Woolf: I prefer to know how much work we’re taking on. Shane Kerr: I was going to ask the same thing. Suzanne asked for sense of the room for whether to adopt this as a working group document: ** Adopt this document: Significant hum in support ** Do not adopt: Silence draft-ietf-dnssec-algorithm-update, Wouters 15 min Paul Hoffman: We should not talk about specific algorithms today. S/MIME used this “SHOULD+” and “MUST-” notation, and it worked very well. IPSECME has also worked well. I like this as a way of helping guide developers. Christian Huitema: Something is wrong with this aesthetically. I’d hate seeing “SHOULD?” and “MUST+” in RFCs. What about plain English phrases like “MUST for now”? This is supposed to be English, not a programming language. Paul Wouters: The people reading this should be programmers already. Mike Richardson: I am for doing this work, and this split for signers/validators is sane and good. I see that you would pick validation SHOULD+ in advance of signer SHOULD+, and I think this makes sense. Dan York: Is there “MUST+” Paul Wouters: No. Dan York: Is the “SHOULD+” and “MUST-” notation documented anywhere? Paul Wouters: In this document. Francis Dupont: I do not support “SHOULD-” for RSASHA512. Paul Wouters: The idea is that algorithms that are dead or not used or silly should be demoted. Likewise for algorithms that have different algorithms for NSEC3 and not-NSEC3. Christian Huitema: What’s the difference between “SHOULD-” and “MAY”? Paul Wouters: “SHOULD-” means currently “SHOULD”, but we’re thinking of changing to “MAY” or “MUST NOT”. Paul Hoffman: If you don’t like the “-” and “+” you can ignore those modifiers. Christian Huitema: I don’t like this “-” and “+” and I don’t want to see it in the next update of RFC 2119. Ed Lewis: The DNSSEC definition includes local policy. What are you targeting here? Paul Wouters: This is targeting implementations, not local policy. Ed Lewis: Then you need to distinguish between general-purpose implementations and turnkey. I don’t have to write my code for my use to meet your spec. Paul Wouters: If you ignore all the MUSTs you will likely not interoperate will with other people. Andrew Sullivan: The DNS community had this fight once before, in DNSEXT. This strategy is not popular around here. I don’t know why. What we did is captured in RFC 6944. It is considerably less useful than this advice. I encourage people to reconsider it. There’s an archive from 2013 that will allow you to peruse how this conversation went the last time we had it. Mike Richardson: If your only interoperable algorithm is marked SHOULD-, then you had better add a new algorithm, because later on others may remove support for it, and you won’t interoperate. Paul Wouters: Yes. Every table needs at least one “MUST”. Dan York: I support this work. I like the “SHOULD+” and “MUST-” notation. Will this notation spread to other documents? Paul Wouters: I talked to Mark Andrews and he said we should never change any software defaults because that would break fifteen-year-old scripts. We can’t ever remove any signing algorithm, because then those old scripts might break. We have to support all the old algorithms for eternity. Dan York: Once things are implemented in the DNS, they never die. It’s impossible to phase things out. However, there’s still value in providing guidance to newer implementations. Paul Wouters: We don’t want the case where someone has a signed zone that effectively becomes an unsigned zone because no one supports their algorithm any more. Tim Wicinski: There is support for this work, so we’ll continue it. - This May (Not) Be Working Group Business draft-sullivan-dns-class-useless, Sullivan15 min DNS Classes are an attractive nuisance. People sometimes believe they are more useful than they really are. Support for DNS Classes is often implemented badly. Propose that IANA close the DNS DNS Class registry. New rrtypes will be for all classes. John Klensin: Chaos was a "different network stack", Hesiod was something else, more like a hierarchical namespace. If either "didn’t work", it would come as a surprise to a lot of users at the time. "Outlived their usefulness and are creating confusion" would make me a lot happier than "useless". Andrew Sullivan: Happy to make that change. Christian Huitema: This is a great idea. One thing DNS needs is more entropy bits. We could use the class field for more entropy bits. Just sayin’. [Presumably joking -- minute taker] (Laughter from attendees in room.) Ólafur Guðmundsson: Christian has the uniform of the Bad Idea Fairy. Andrew, you are brave, but I don’t agree with this. We should continue to allow the use of classes, with the understanding that such software may not interoperate with anything else. Andrew Sullivan: The first version of this document just gave advice. The feedback was that if things are so bad, we should just close the registry. John Levine: I agree we should close the registry. The problem is the spec is broken. It says a Chaos “A” record and a Hesiod “A” record and an Internet “A” record are different. Except for “NS” records they’re all the same. There is no problem that DNS Classes solve, and many that they introduce. Mark Andrews: We need to make DNS Classes usable in the future. We can make operational guidelines that different classes need to be delegated in parallel. We need to specify that for all new rrtypes, by default they apply to class “IN” only. DNSSEC records are class-less. Delegation is class-less. We should not close the registry. We could have solved the IDNA problem using a class “IDNA”. Andrew Sullivan: There was a proposal to do IDNA using DNS Classes. It turns out not to work very well. Part of the reason is that there’s a lot of software that can’t do it. It might be nice to be able to use DNS Classes in the future, but there is no path to that future that I can see. Mark Andrews: There is no path *you* can see. *I* can see a path. You want to close this because *you* can’t see the possibilities. Others can see the possibilities. I believe doing IDNA using DNS Classes would have worked. Suzanne Woolf: Are you volunteering to write this draft? Mark Andrews: We don’t need to do anything right now. Just go away. We don’t need to touch DNS Classes. We just need to say rrtypes apply to class “IN” only. Ed Lewis: I actually agree with *some* of what Mark Andrews said. When we did DNSSEC we overlooked message compression and DNS Classes. We fixed the confusion about message compression. We never fixed the confusion about DNS Classes. No one cares about this. I think it would be good to close the registry. Wes Hardaker: I agree with Mark Andrews. DNS Classes are not the problem. The problem is badly written software. That doesn’t mean it couldn’t be useful in the future. This is an education problem. So, we need better documentation -- a BCP. We should have a document describing the pitfalls of using classes other than “IN”. Andrew Sullivan: There are two problems. 1: STD13 says the trees (by convention) are parallel. In reality it would be a terrible idea to have the trees not be parallel. Different people would control the same name in different classes. 2: We don’t truly know if new rrtypes apply to all classes, or just one. It’s so long since we had other classes that no one knows. Does the new TLSA rrtype apply to all classes, or just “IN”? Wes Hardaker: Are we trying to document reality or change reality? DNS Classes have not been used for a long time. We can change the rules if we like. Peter Koch: With the CLASS registry closed, things like RFC 2136 (DNS Dynamic Update) would not be possible; registration policy already sets a high bar; bad ideas will not go away by closing the registry. Class dependent RRTYPE definitions are a different issue. Stéphane Bortzmeyer: I support this draft, and closing the DNS Class registry. I remember the Net4D project a few years ago, which was a technically flawed idea, encouraged by the belief that DNS Classes could be used. The draft explains many reasons why trying to use DNS Classes is a bad idea. In addition, many APIs do not allow specifying the DNS Class. Even if the APIs exist, they are not widely tested, so there are likely to be bugs that we have not found yet. David Lawrence: Which WG is the right venue for this? Andrew Sullivan: It can be discussed on the IAB Program list inip- discuss. DNSOP is also a place where this can be discussed. John Klensin: Seems to me that fixing the spec to remove the parallel tree language and restrict cross-class RRTYPEs would be straightforward. I’d even volunteer to do the work, right after we get i18n nailed down. [Presumably joking -- minute taker] (Laughter from attendees in room.) Joe Abley: AD sponsorship would be reasonable. draft-valsorda-dnsop-black-lies, Guðmundsson David Lawrence: What rcode? Ólafur Guðmundsson: No error. (The name “exists”.) David Lawrence: That might cause problems for some applications. Ólafur Guðmundsson: Yes. For applications that care, bits in the NSEC record let them derive the information they want. Paul Hoffman: This is a good document as an Informational RFC. I don’t think it updates RFC 4770 as shown on slides -- wrong RFC number. I think it needs a better title. Aaron Falk: Maybe publish first as Experimental, and then reconsider Standards Track in a couple of years? Mark Andrews: This interacts badly with aggressive negative caching. Ólafur Guðmundsson: Yes, and no. We can tune how far away the ‘next name’ is, because we’re signing on the fly. Mark Andrews: With random attacks the space is almost infinite. The only way to close them down is a negative answer. Extending the ‘next name’ will not work once people adjust to this. Ólafur Guðmundsson: Let’s discuss this further on the list. I believe it’s workable. You do not. draft-vavrusa-dnsop-aaaa-for-free, Guðmundsson15 min Stuart Cheshire: Clarification: When you say “poison the caches” you mean “preload caches with correct information”, right? Ólafur Guðmundsson: Yes. Andrew Sullivan: The problem is the signalling is needed in any case, because the chains might be multiple resolvers long. The authoritative server doesn’t know what’s happening at the other end of the chain. We know that resolvers that set the DO bit can accept *some* extra records. Using the DO bit presupposes EDNS0. We still don’t know what happens with resolvers that don’t set DO and you give them something extra. Robert Martin-Legene: You are doing this to make things faster? Ólafur Guðmundsson: No. The goal is to get more IPv6 connections. Robert Martin-Legene: Okay. Ed Lewis: I recommend doing a document search. I know the question of trustworthiness vs. DNSSEC signed data has been discussed. Has that ever been documented? Ólafur Guðmundsson: There was an extensive discussion of this topic when we were doing DNSSEC. For some reason I don’t recall we decided not to document this. We also decided not to document negative answer generation based on NSEC records. Paul Wouters: We also touched on this while discussing EDNS query chain. I suggested using the NSEC bitmap to add any queries you want, like TLSA. Shane Kerr: Your focus is on communication from recursive resolvers to authoritative servers, right? Ólafur Guðmundsson: Yes. Shane Kerr: Should also do this for stub-to-recursive communication too. This could halve the query load on recursive resolvers. Erik Kline: Is there any data that suggests this actually saves RTTs (for non-validating clients, say...)? Many resolvers ask for AAAA first, if IPv6 is a possibility for the client. Ólafur Guðmundsson: I am not aware of any data. Stuart Cheshire: iOS and OS X start AAAA query first, then A immediately afterwards (running in parallel). Erik Nygren: Android (at least in some cases) does the two queries sequentially, not in parallel. Christian Huitema: Microsoft does both queries in parallel. Problem happens if you wait for both responses, which adds latency. - 6761 Discussion draft-adpkja-dnsop-special-names-problem 30 min draft-tldr-sutld- ps https://tools.ietf.org/html/draft-tldr-sutld-ps-00> (Warren Kumari & Ted Lemon presenting) Dan York: Your third bullet says: > DNS names are the installed base, new name resolution protocols > have to exist under a label reserved under RFC6761. Names don’t *have* to be reserved under RFC 6761 rules. In reality, developers are free to do what they want without talking to the IETF at all. Warren Kumari: You are right, “have to” is overstating it. Stuart Cheshire: This document talks almost exclusively about TLDs, whereas RFC 6761 is not at all about TLDs; it’s about special behaviors and how names can be algorithmically identified as triggering those special behaviors. For example, talks about special behavior relating to “ipv4only.arpa”, which is not a TLD. Warren Kumari: Yes, you’re correct. Ralph Droms (co-author of TLDR draft): The important question is whether, within these documents, there is a clear and useful list of problems we can use as the basis for working group development? Andrew Sullivan: Thanks Ted and Ralph for for writing the TLDR version of this problem statement. It is orders of magnitude easier to understand than the adpkja version, and considerably better focussed on the technical issues. Ray Bellis: Is the TLDR name an intentional joke (“too long; didn’t read”)? Ted Lemon: Yes (with Ralph’s agreement). Stuart Cheshire: As I’ve said already on the mailing list, the adpkja draft focusses far too much on the question of the names, and completely ignores any consideration of the new behaviors people want. Here at the IETF we’re interested in writing software, and how that software behaves. The use of algorithmically recognizable names is merely a means to that end. At this IETF (arcing Bof) we’ve discussed carrying around an extra resolution context in a tuple, and why that’s not practical. The “gethostbyname” family of APIs don’t have any way to specify a context. We could expand that family of APIs to take a string plus a context identifier, but then we would need an IETF working group to debate who owns the namespace of context identifiers. We’d need a context identifier for the context identifiers. Recognizing that adding more layers of indirection doesn’t solve the problem, we need a way to have a name be self-describing. That means that something about the name tells you the context you use to look it up. That technical motivation behind doing this seems to be completely ignored by the adpkja draft, at present. That’s what I think is missing. We need to remember that there are two layers here. There is the API layer of “gethostbyname” and friends, and then there is the on-the- wire DNS protocol layer. We assume that those two layers are tied together, but we know they are not. There has been the /etc/hosts file since the start, there’s NetBIOS, Multicast DNS, dot-onion, the nsswitch mechanism in Linux that let any developer plug in whatever they want to do. Without some cooperation we just have chaos. It feels like the adpkja draft is about defending ICANN’s revenue. Honestly, what the “gethostbyname” APIs mean depends exactly what vendors like Microsoft, Android and Apple feel they ought to mean. As long as the DNS and the IETF provide a useful service for the public good then we all support that, but there is no law that says we are obliged to make APIs that funnel money to ICANN. David Conrad: As far as I know, ICANN has no opinion here. There is no assertion that anyone has to abide by anything that ICANN says with regards to that namespace. We have RFC 2860 (Memorandum of Understanding Concerning the Technical Work of the IANA) that says the IETF has the ability to reserve special names. My view of RFC 6761 is that it is a mechanism by which that could be exercised. That has absolutely nothing to do with the new gTLD program. The issue is that we have a multipolar world in an environment that assumes a unipolar world. Warren Kumari: In some cases what the IETF says and what ICANN says doesn’t really matter. We are not the police here, we have no ability to stop developers doing what they want. If we provide a way that it is easy and friendly, maybe they will follow it, but if someone wants to create a dot-something, or a different name resolution mechanism, like hashtags in twitter, there is nothing we can do to stop them. Suzanne Woolf: The IETF arcing BoF discussed these issues, and those drafts are good reading about these namespace issues. Ted Lemon: The whole point of the TLDR draft was to up-level the conversation. When we talk about solutions before we talk about what the problems are we wind up not clearly seeing the things we are giving up or the things we are getting. I don’t disagree with what you said, Stuart, but for now I want to discuss specifically what the problems we are trying to solve, and not how we are going to solve them. I wanted to make that crystal clear in the document. Ralph Droms: In whatever document we take forward we should be sure to capture what David Conrad just said. Ted Lemon: There are three problems I have become aware of since we wrote document that aren’t in the current version. I don’t remember the details but I have them in my notebook. There has been some discussion specifically about how to document the issue David Conrad raised. Peter Koch: I take offense in being accused of co-conspiring protecting ICANN’s income; this is not about ICANN, it’s about the IETF behaving consistent: consistent with the architecture, consistent with the 2860 MoU and consistent with the 6761 procedure to start with; also we do have identified open issues in 6761 - and that was the task. Stuart Cheshire: Peter is making a good point. I was not accusing any of the authors of the adpkja draft of having ICANN’s income as their primary interest. My comment was addressed at this document: that right now it completely ignores the special behaviors that developers want. That’s what I think is unbalanced about this document. It’s all about the names, and not about the behaviors. The document is not balanced right now. Suzanne Woolf: What I’d like to have conversation focus on for now is that we do have two drafts that between them list some specific issues and what I think we need to be working towards is a list of issues so that we can then start saying, “If we do this then it will solve this subset of the challenges.” Because I saw a relative small number of hands raised by people who have read the drafts I think what we need to do is solicit more comments and discussion on the lists, and focus on the technical and operational pieces of this. We need to spend the next few weeks focussing on what the symptoms we are trying to alleviate look like. Thanks to everyone for contributing. See you in Berlin. END