Minutes for DNSOP at interim-2015-dnsop-1
minutes-interim-2015-dnsop-1-1

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 .<something> 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.