[dnsop] Draft DNSOP Vancouver minutes

[Peter Koch <[e-mail]>]

Dear WG,

the draft minutes of our Vancouver meeting have been uploaded and are
available at <http://www3.ietf.org/proceedings/05nov/minutes/dnsop.txt>
as well as in this message. Apologies for the delay and thanks to Sam Weiler
for for doing an excellent job. Thanks also to George Michaelson for
being the Jabber scribe.

Please submit comments and corrections asap; the proceedings will be
frozen on December 26.

-Peter

-----------------------------------------------------------------------------
DNSOP WG IETF64 Meeting Minutes (draft)
Date: 8 November 2005, 15:10-17:10 [PST]
Scribe: Sam Weiler
Jabber Scribe: George Michaelson
Chairs: Rob Austein & Peter Koch
-----------------------------------------------------------------------------

Process changes

   The chairs asked for agreement on a temporary moratorium on new
   work items until items on current agendas are gone, either through
   publication or killing documents.  Before the next IETF, they hope
   to go through each of the current work items and kill those that
   the WG won't commit to reviewing (approx. five individuals).  Then,
   for new work, if the WG can't get N (5?) people to review an item,
   we don't take it on.

   While agreeing that a simple "hummm" should not be sufficient for
   taking on new work, Olaf expressed the concern that requiring an
   empty stack before taking on new work may be bad. He asked that if
   new items are useful we go ahead and accept them (after applying
   the gating function based on number of reviewers).  The chairs
   agreed to this modification

   Two other suggestions were made: Pekka Savola suggested that every
   author proposing a draft should publicly review 5 other docs.
   And Liman suggested assigning small teams to shepherd (new) docs,
   rather than a single editor.

   No objections were raised to the chairs' proposal.


Documents past last WG

   The chairs listed the docs beyond WG last call, per the agenda.

   The chairs called for a show of hands for those who had read
   draft-ietf-dnsop-dnssec-operational-practices and think we
   should advance it.

   David Kessens explained that ipv6-dns-issues passed IESG except for one
   AD.  The doc will be on next IESG telechat agenda to try to clear
   that Discuss.

   Mohsen asked for clarification about the state of
   ipv6-dns-configuration, and the chair confirmed that this WG is
   done with it -- the IESG just wanted it as input for chartering
   decisions.


Active drafts

draft-ietf-dnsop-serverid-05.txt

   There was a WGLC on the serverid draft and the editor believes all
   substantive comments have been addressed in current draft.  The
   draft is waiting for the chairs to advance it; no further work is
   needed in the WG at this time.  Olaf raised the question of whether
   this work is still needed since the NSID draft in DNSEXT has now
   progressed.  The chairs asked if any in the room thought the draft
   was not needed (no hands), who supported publications (modest
   humm), who opposed (silence), and who had read it (some hands).

draft-ietf-dnsop-inaddr-required-07.txt

   For inaddr-required, less than a handful of those present
   acknowledged having read the CURRENT version of the draft.  There
   were 4-6 people willing to commit to reading the draft, though some
   of those specifically declined to agree that the draft was worth
   advancing.  The chairs will take the decision of what to do with
   the draft to the list.

draft-ietf-dnsop-respsize-02.txt

   The chairs called for a show of hands for those who had read the
   LATEST version of the respsize draft and thought it was ready for
   last call.  They asked those uncomfortable with advancing it to
   send comments to the list.


Expired drafts

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

   This was a product of an IAB IPv6 ad hoc group that suggested this WG
   review it and publish it as informational.  This has not been
   published elsewhere, but it has gotten substantial review, and the
   service it describes is now up and running.

   Pekka Savola expressed concerns about whether this document
   accurately describes the service as it's running and will continue
   to run.  Geoff assured us that this does accurately describe the
   current service, but that there are no reassurances the service
   won't change in the future.  The service is in the last stages of
   testing, not productions, so issues that arise during WGLC can
   still be considered.  Ed Lewis also expressed concerns that we were
   being asked to rubber stamp others' work.  David Kessens reassured
   the WG that we can indeed make changes to the document -- this
   isn't a request for rubber stamping.

   Sam Weiler and Lars-Johan Liman asked why DNSOP was being asked to
   review this, rather than the IAB publishing it directly or the
   editor sending it in as an individual submission.  It was explained
   that the IAB has asked us to take this on -- they'd rather see us
   publish it.  David Kessens expressed a preference against
   individual submissions, in part because of the RFC Editor's ISR
   delays.

   The chairs called for reviewers and some committed.

draft-fujiwara-dnsop-dns-transport-issue-00.txt

   The editor is withdrawing the draft.


Potential new items.

draft-andrews-full-service-resolvers-01.txt

   Mark gave a brief presentation (see slides in the proceedings)
   arguing that having an RFC will help encourage some vendors to do
   this.  The chairs asked that the detailed discussion of the names
   on the list be deferred.  They clarified that this is NOT a
   protocol change and offered an alternate explanation: it's like
   replicating AS112 on all recursive resolvers.

   Olaf pointed out that the registry lacks an allocation policy
   and as asked to send text fixing that.

   Peter Lothberg started a brief discussion of alternatives to
   NXDOMAIN answers (such as answering the queries) and Bill Manning
   told of his experiences doing that.  When he first proposed
   standing up dedicated servers for this, the IANA said this was
   ludicrous -- these queries would never make it out onto the live
   net.  This was a safety net.  When they actually tried it, there
   was a huge number of queries and Bill got an "exorbitant" number of
   threats from important people.

   There was some discussion of whether this "blacklist" needs to be
   updated regularly, and Mark explained that one must be careful
   about what names are added -- removal from the list is difficult.

   Olafur and David Hankins spoke up in support of the draft and
   committed to review it.  The chairs called for other reviewers.

draft-minda-dnsop-using-in-bailiwick-nameservers-01.txt
draft-morishita-dnsop-anycast-node-requirements-01.txt

   The editors of these documents weren't present; discussion should
   go to the list.

draft-durand-dnsop-dont-publish-01.txt

   Very few comments have been made about it on the list and it's not
   clear how interested the WG is.  There was discussion of whether to
   mention split-brain configuration in the draft -- consensus seems
   to be strongly in favor of doing so, recognizing that split brain
   is a fact of life.  The chairs encouraged the editor to submit a
   new version within 8-10 weeks, which should be about the time that the WG
   has finished its review of existing items and is ready to consider
   new work.

draft-kurtis-tld-ops-00.txt

   The editor didn't get a revision in by the draft cutoff and
   promised to do better next time.

draft-krishnaswamy-dnsop-dnssec-split-view-01.txt

   This draft has gotten very few comments on the list (there were no
   responses to a query from Ed Lewis in August).  The chairs called
   for reviewers, and 5-6 people volunteered.

draft-pappas-dnsop-long-ttl-00.txt

   The chairs pointed out this document, which will be discussed on
   the list later.  They're particularly concerned with how this
   interacts with DNSSEC and would especially appreciate review by TLD
   operators and registries.


Charter and direction

The chairs pointed out that the previous charter focuses on work in
three areas:

  1) IPv4/v6 coexistence
  2) DNSSEC
  3) general DNS operations

The chairs asked if there are any other big areas that need to be
included, and Ed Lewis mentioned the resolver and measurement of the
effects of DNS operational changes.


Any other business

draft-kato-dnsop-local-zones-00.txt

   There was a brief discussion of whether Kato-san's local zones
   draft should be merged into Andrews' draft.  Liman spoke up for
   keeping them separate.

draft-conroy-enum-edns0-01.txt

   The question was raised of how to support other working groups, in
   particular reviewing this draft.  Patrik, as an ENUM chair asked if
   we need a doc saying "you should do EDNS0" (some phone handsets
   aren't.) and, if so, should we do that in DNSOP, in ENUM, or in
   ENUM reviewed in DNSOP?  Rob thinks DNSOP should go ahead and
   review it, to save the IESG the hassle of sending it to us later in
   the process.

   Patrik asked for a coeditor and Liman volunteered.

   There was discussion of the scope of the document: whether it
   should include both operational and implementation requirements
   and, since this touches clients, servers, and middleboxes, whether
   the doc would grow unwieldy.  It was suggested that a big doc would
   do ENUM a disservice -- they need a short, terse doc with lots of
   requirements to use to beat implementers.  ENUM and other WGs that
   need such a document should write it themselves, with our review,
   and if we want a bigger, more comprehensive document, we can reuse
   text from their documents.  (Mark Andrews volunteered to review a
   DNS firewalls rules document.)

Following up on the discussion of draft-andrews-full-service-resolvers
and Bill Manning's stories, Dave Hankins mentioned that as a
contact for AS112 advertised address space, he regularly gets
phone calls from folks who think they're under attack.  Sundry
suggestions were offered for mitigating this lack of clue, including
changing the WHOIS records or advertising a special phone number which
is answered only by a machine.
-----------------------------------------------------------------------------
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html