[dnsop] Draft dnsop minutes for IETF65

[Peter Koch <[e-mail]>]

Dear WG,

find below the draft minutes for the Dallas meeting. Thanks to Wouter for
acting as the Jabber scribe and thanks to Jaap for providing the minutes
on time. Aplogies for the delay, all typos are mine. Please send comments
or change requests to the WG chairs by Friday, May 5th 1200 UTC.

The minutes are also available online
<http://www3.ietf.org/proceedings/06mar/minutes/dnsop.txt>

-Peter

-----------------------------------------------------------------------------
	DRAFT(1) dnsop WG minutes for IETF 65, Dallas
-----------------------------------------------------------------------------
WG:        DNS Operations (dnsop)
Meeting:   IETF 65, Dallas
Date:      Tuesday, 21 March 2006
Time:      15:20 - 17:20 (UTC -0600)
Chairs:	   Rob Austein, Peter Koch
Minutes:   Jaap Akkerhuis
Jabber:    xmpp:[e-mail]
J-Scribe:  Wouter Wijngaards
J-Script:  http://www.ietf.org/meetings/ietf-logs/dnsop/2006-03-21.html
Audio:     http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65tue05.mp3.2
WG URL:    http://www.dnsop.org
Material:  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
-----------------------------------------------------------------------------

1) Administrivia

   - blue sheets
   - agenda bashing

	There was no change to the agenda itself.

-----------------------------------------------------------------------------
2) Status Update by Peter Koch.

   - RFCs published
	RFC 4339 "IPv6 Host Configuration of DNS Server Information Approaches"

   - Internet-Drafts in RFC Editor Queue
	draft-ietf-dnsop-ipv6-dns-issues-12.txt

   - I-Ds in IESG review
	draft-ietf-dnsop-dnssec-operational-practices-08.txt

Approved by the IESG yesterday (2006-03-20) after a resolved discuss.

   - I-Ds in or past WGLC
	draft-ietf-dnsop-bad-dns-res-05.txt

This draft passed Working Group Last Call, waiting for PROTO write-up.

	draft-ietf-dnsop-serverid-06.txt

This draft is close to be done and was waiting for a corrected version (-07).
It will then be sent to the IESG with a PROTO write-up.  Since this will be
an informational document, it depends on the AD whether there will be an IETF
Last Call.

	draft-huston-6to4-reverse-dns-04.txt

This document describes an existing service.  This draft is still
in need for review and the chairs are waiting for volunteers. The
list of volunteers from last time got lost.

Comments from George Michaelson (Proxying Geoff) about issues that came up:

	Although there had been no publicity at all, there are
	already over 185 uses of this service. This raises questions
	about the scalabilaty.  Obviously it scales for the time
	being. Note that this service is designed for transition
	and not for infinite use.

	Q: It was raised why this wasn't done with with dynamic update?
	A: if you want that, write a proposal.

-----------------------------------------------------------------------------
3) Lingering Drafts & Review Process

   3.1) draft-ietf-dnsop-inaddr-required

Discussion of this draft needs more guidance, otherwise it is at danger of
rehashing old issues over and over.

Peter suggests to use the tracker, identify and discuss the issues and close
them.

Sam Weiler notes that the drafts is expired and wonders whether the
editor is not really committed. Peter Koch explains that that is not
the case and that by non foreseen circumstances the editor just
missed the deadline for this meeting.

   3.2) draft-ietf-dnsop-respsize
	Draft is expired, revised I-D needed

Akira Kato-san reports that the draft expired by accident.
A new version (03) is expected soon.
At the meeting nine people volunteered to review the draft.

-----------------------------------------------------------------------------
4) WG Charter

A draft charter was circulated to the mailing list in advance. Peter Koch
gives an overview of it. It boils down to:

1) develop or review guidelines for choosing zone configuration
   parameters that affect inter-server or server-resolver communication,
   including but not limited to SOA RR parameters, TTL values, and glue
   information

2) develop or review guidelines for any DNSSEC specific operational
   parameters, such as key length or key validity periods

3) develop or review operational guidelines that address the specifics of
   IPv4/v6 coexistence and transition

4) review the use of existing DNS frameworks (SRV, DDDS) in other protocols,
   especially focussing on operational consequences and scalability

Pekka Savola comments that operators needs are not addressed and
wants to know whether 4 denotes only new things or also current.

Peter: Interpretation what ever you like. Intention is current and
    upcoming, like ENUM.

Pekka: so this not necessarily gives new action items.

Austein: Grey area, sometimes issues are discussed with the DNS directorate.
     But sometimes some wider review is needed.

Peter: Price for (4) is more reviews and more work!

       Generic Question: Is the proposed charter too broad/too narrow?

Ed Lewis misses:
	(1) resolver issues
	(2) performance, measuring, etc.

Point 4 adresses about protocols, 1-3 about servers, in general,
the resolver part is missing.

Ed clarifies the he would like to see measurements guidelines and methodology
discussed in the group, but does not expect the WG to engage in actual
measurements.

Alain Durand wonders about terminology used. A lot of documents
have problems with that. Peter agrees that this problem is important and
needs to be solved. However, the DNSOP WG is not only the only game in town.
Olaf Kolkman (DNSEXT co-chair) is asked for a comment.

Olaf: as soon as such a draft exists as a personal submission he
will let it land in DNSEXT WG.  Some will be done somewhere and
dnsext will at least review such a thing.

Peter: Last Call on the charter will be done after comments are taken
in and processed and actual milestones have been defined.

-----------------------------------------------------------------------------
5) Other Internet-Drafts

   5.1) draft-krishnaswamy-dnsop-dnssec-split-view-02.txt
	http://www3.ietf.org/proceedings/06mar/slides/dnsop-1.ppt

Suresh Presents:

	Goal is to demonstrate the need for this WG to deal with the subject.

After the presentation it was questioned why 'split view' was needed in
the first place and whether it is a 'good thing'. Reasons given included
the existence of Firewalls/NAT and hidden names inside public names spaces.
Suresh suggested that the WG should care because 'split views' could conflict
with DNSSEC and offer various options of 'shhoting oneself in the foot'.
He felt that the draft/the WG should offer solutions to enable coexistence
of split-views and DNSSEC. Comments should go to the WG mailing list.

Rob Austein asked whether this was the right document for the group.
Some voices were raised in favor and eventually 10 people in the room
volunteered to review the document.
The document will not become a WG doc yet until this real review is done.

   5.2) draft-andrews-full-service-resolvers-02.txt
	[slides available with agenda slides]

Mark presents and Peter summarizes that this is AS-112 in a box.

Two questions are raised:

(1) Should there be an IANA registry for this?

    (a) how do you know your addresses are to get on the list?
    (b) how to get addresses off the list?

After some discussion, the chairs ask for a humm in favor of either
an IANA Registry or a hardcoded list in the document.
The humm does not show a clear result either way

Mark explains that one reason for a registry was the list of IPv6 address
ranges, where things still are in flux.

Olafur Gudmundsson asks whether anybody sees any harm in having a registry.
Sam Weiler argues that he does not see a benefit, but would not object to
a registry. Rob Austein adds that so far no one has argued for a registry
maintenance policy weaker than 'standards action', so the actual work of
updating the list might be the same with a registry and with a list
carried forward in updated versions of the document under discussion.

(2) Is initial list of adresses complete?

Mark presents the list of address ranges subject to authoritative 'name error'.

Peter asks why 255.255.255.255 appears instead of 255/8 
Mark responds that this would cover to large of a /8 for just one address
No further comments on the v4 list, further remarks should go to the mailing
list.

After presentation of the v6 list, Alain Durand raises the concern that
anyone trying to use the listed addresses internally would encounter problems.
Mark and Rob respond that the lists specify the default configuration and
implementations must provide means to override these. Peter adds that
a network administrator has to provide a consistent view internally.
Alain volunteers to send explanatory text.

Peter summarizes that the sense of the room is in favor of an IANA registry
and the list presented. He suggests to ask the INT area and the 'addressing
community' for review to avoid conflicts and surprises.

Ten people commit to review the draft. This is not yet an official WG item.

-----------------------------------------------------------------------------
6) Current & New Topics [25 min][16:40]

   6.1) Measurements on DNSSEC Validation Performance
	http://www3.ietf.org/proceedings/06mar/slides/dnsop-0.pdf
	[Jakob Schlyter][10 min][16:40]

Jakob Schlyter presents performance impacts of DNSSEC validation for
Nominum CNS and ISC BIND. One of the results is that the change in
performance (answered queries/s) was larger for CNS than for BIND.
For the ISP which gave traffic, it doesn't really matter.

The audience, asked for feedback, considered this kind of testing useful.
Jakob did not promise to produce a write-up of the tests.

   6.2) "Open Resolvers"

	Discuss operational impact of "Open Resolvers" as mentioned
	e.g.  in the thread starting
	<http://www.merit.edu/mail.archives/nanog/msg16000.html>
	Explore chances to work towards a BCP on resolver configuration
	and/or operational impact of potential counter measures.

Peter Koch introduces subject:  Lots of people heard about it.
  Is there work on a document?
  Configuration help?
  Should the WG produce a BCP?

Several people agree that it would be good to have an IETF document, even
given that BCP 38 already exists and is too widely ignored. Concerns are
raised that the WG should not target a specific code base, but might want
to include some configuration examples. It is also mentioned that not only
open resolvers are abused, but also authoritative servers; others feel that
still closing open resolvers is a good thing because they lower the barriers
to entry compared to usage of botnets etc.
It is noted that in some fora EDNS0 receives a bad press as being the enabler
for the DoS attacks. Jinmei argues that there are some legitimate uses for
open resolvers. There is agreement that resolvers should just not be 'open'
by default. 

No one in the room argues against a BCP style document. It is also agreed
that, to be useful and relevant, any such document has to be passed through
soon, i.e. around the Montreal IETF. Peter is asking for volunteers to
edit a document, pointing to the tight schgedule.
Matt Larson, Joao Damas, Frederico Neves, and Roy Arends come forward as
potential editors. Eight additional people volunteer as reviewers.

Action on the chairs to select editors and define a schedule.

-----------------------------------------------------------------------------
7) I/O with other WGs
   [chairs][10 min][17:05]

   7.1) EDNS0 for ENUM

Patrik Fältström: As enum WG we have enough feedback already (with Liman)
There are other things popping up. Let's continue the way is is now.

-----------------------------------------------------------------------------
8) A.O.B.

Peter Koch (speaking as an individual) asks for review of 
draft-koch-dns-glue-clarifications-01.txt, dealing with "glue" terminology
and policy. This is not a WG draft. Rob asks whether Peter would like to
bring this to the WG. Peter responds that he'd like to have some guiding
feedback first, since the draft covers various aspects, some of which are
operational only.

-----------------------------------------------------------------------------
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html