Interim Meeting 2015-05-12 Slides: https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/slides/slides-interim-2015-dnsop-1-0.pdf Notes ----- Suzanne Woolf (sw): Note Well, Agenda, etc. Basis of conversation in 2860 ICANN has policy over DNS Root, IETF has responsibility for "assignment of domain names for technical uses." 6761 expands on this. Responsibility where DNSOP is here - came about from rechartering. Areas of Concern ---------------- - Operational Questions * 6761 has 7 criteria, "new functionality" * Other characteristics * Special Use Names are *not* TLDs - Policy around Name space * is coordination needed? * policy goals are not always technical ones. onion draft: * CAB forum one thing; installed base. reducing leakage unknown(uk): CAB Forum objective; reducing leakage is another Peter Koch(pk): adopt the document not necessary per 6761. pre-occupation conveyed reduced Dan York(dy): process question: sw: overview, then 45-60 minutes for discussion on drafts Warren Kumari(wk): Follow up to Peter. If WG adopts and WGLC more likely IESG do their part, or not? sw: we don't know. Process should follow, not Lead chapin draft: aka "home/corp/mail" - delegate due to risk of 'name collision' - ICANN 'deferring indefinitely' alt draft: discussed several times, well known will this work other drafts: p2p: multiple names, WG seems to want to separate them lewis: use the extra 2-letter strings homenet: another proposal for .home next steps: within the charter; AD is supportive timeliness constraint on the .onion onion: seems straightforward - adopt? alt: could help with scalability chapin: appears policy based longer term: how high should the bar be? update 6761? Jonne Soininen(js): ICANN liaison. alt allows for others to experiment and saving a potentially scare resource. Ted Lemon(tl): not always a scare resource based on combinatorics. not a good use of ietf resources to argue about TLDs, hence .alt is a good idea Richard Barnes(rb): alt is a good solution for the future, but does not solve the .onion problem. sw: .alt is useful for experimental but not in the immediate Hugo Connery(hc): .alt is a good idea as an idea. onion have a large deployment base. do not delegate names, but also operators to not answer / nxdomain pk: possibly mixing issues. RFC6303 is a registry for local names already. instead of .alt, why not use .invalid (2606) dy: app developers aren't paying attention to the TLD space. go with .onion John Levine(jl): wide use of .onion, should reserve sw: clarifying question: jl: someone could "gin up" a plausible but fake community for . to shake down an applicant, but is hypothetical. tl: agrees with previous speaker Lars Liman(ll): really carefully with using installed base as basis. could introduce denial of service. js: home/corp/mail - not necessarily use of 6761. what is the bar, .onion already passes the bar. reserve if risk of collision. can easily get into policy questions if we look into wrong names and we should not be. Andrew Sullivan(as): distinction made on the mailing list between protocol and policy. should make the distinction, and if we do, then punt special uses that are attempts to carve out dns back to the root zone and special names additions are just for new functionality. dy: asking us to adopt? sw: no adoption during this call. that will be on the list. gauge interest. Tom Ritter(tr): using installed base as metric. can be gamed, doesn't mean we can't require a fairly high bar. https://metrics.torproject.org/ uk: agree with past comment on installed base. trying to prevent leakage in public space. there is time pressure and existing installed base. tl: topic of user base for allocation special use names. .onion is a good use case. large installed base not a good test. MoU and what can we do about it. sw: some discussion with policy names in reserving names vs protocol shifts wk: don't want to become an ICANN. pk: Andrew Sullivan going in the right direction. IETF should not make itself to "policy laundering". ICANN should take responsibility. uk: to warren: do we need an RFC for an exception? circular argument. similar to IANA code point. wk: people are underestimating the amount of pent up demands in the ICANN space, even in preventing others from having a TLD. Mark McFadden(mm): policy component. chapin-draft is more operational and engineering, and not policy. policy and protocol component missing operational stability component. str4d: a developer of I2P. would not have an issue using .alt if starting now. dy: key point is strings to reserve because of impact outside of DNS. .onion is perfect example. Paul Hoffman(ph): speaking of engineering. wants to take off table the root server leakage. gaming has happened. other operational and engineering criteria rb: determine auto-generated traffic vs organic growth ph: was not saying we could not tell, people who thought we could not tell would start flooding. uk: well-established and well-maintained technologies that want to be excluded from DNS. .alt proposal creates opportunity. wk: disagree with Mark McFadden that the chapin draft was largely operational Lyman Chapin(lc): current operational case with the home/corp/mail names. use cases show operationally problematic. thought it was useful that the IETF declare in an 'operating Internet' is stronger than the policy interest in allocating names to people who pay money. wk: fully agrees. will resolve with Mark sw: should be very precise on the operational impacts of adding names to the special use registry, but is not sufficient. need refinement of the operational impact of reserving or not reserving a set of names. rb: supports moving .onion forward Ray Bellis(rb2): let's get .onion and out there, get home/corp/mail out, move everything into .alt; and close the registry. dy: tell developers to use .alt, but developers will want to use their own TLDs because they can. rb2: which is why to close 6761 registry to prevent any more tld hijacking. str4d: dns has that central hierarchy, and if someone had the need they could get a TLD. would contest that I2P is 'experimental' sw: seems like consensus on .onion. also strong feelings on how to untangle complicated questions.