Re: draft vienna minutes (sorry about the delay)

[Ralph Droms <rdroms@cisco.com>]

I would agree with "reasonably fair" - in a little more detail, I
heard a louder hum for DHCPv6 but not rough consensus.  I think the
minutes might provide a little more detail about my presentation (for those
who don't go look up the presentation); perhaps "configuring devices for DNS
using DHCPv6"?  Finally, for those who weren't present, I think the minutes
should note that DHCPv6 has been accepted as a Proposed Standard and is
published as RFC 3315 (I believe this was the case as of the Vienna
meeting), so we're comparing the use of a published standard against the
development and future publication of a new protocol.

According to the minutes, the first step was to be a continuation of the
discussion on the mailing list.  Perhaps the chairs could frame and kick off
that discussion before we go to a design team?

- Ralph

At 06:17 PM 9/25/2003 +0100, Tim Chown wrote:
>So this is a reasnoably fair reflection of the lack of concensus on RA vs
>DHCP for DNS resolver discovery in Vienna.   Some comments are missing
>though, like Alain's "large network resetting" issue, and of course the
>"Why have DHCP?" responses to "Why not use DHCP?" :)
>
>How is the impasse to be resolved?   Pekka suggested a design team, which
>was not taken forward as it would be a potentially slow process, yet I'm
>not sure anything has changed since July anyway?
>
>There were some fringe proposals after Vienna, e.g. for multicast responses
>to DHCP requests.   Perhaps the lack of a detailed RA-based proposal will
>cause DHCP to be used "by default".
>
>There is still work either way in how the DHCPv6 (Lite) settings are
>propogated to the router, or how DHCPv6 forwarding accurs where DHCPv6
>requests are sourced on a subnet with no server.
>
>Thoughts?
>
>Tim
>
>On Thu, Sep 25, 2003 at 09:39:24AM -0700, David Meyer wrote:
> >
> > *************************************************************************
> > *** DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT ***
> > *************************************************************************
> >
> >
> >                     MINUTES FROM THE DNSOP WG
> >                     57th IETF, Vienna, Austria
> >
> > Date:         Monday, July 14, 2003 15:30-17:30 (Hall NO)
> > Chairs:               David Meyer <dmm@1-4-5.net>
> >               Rob Austein <sra@hactrn.net>
> > Minutes by:   Lars-Johan Liman <liman@autonomica.se>
> > Version:      $Id: minutes-vienna,v 1.3 2003/07/15 10:19:47 liman Exp $
> >
> > #----------------------------------------------------------------------
> > # DRAFT AGENDA
> >
> >
> > Agenda Bashing                                                   5 minutes
> > Meyer/all
> >
> > Status of outstanding drafts                                    10 minutes
> > Meyer/Austein
> >
> > (i).    Farewell to drafts this WG doesn't need to think about anymore
> >         draft-ietf-dnsop-hardie-shared-root-server-07.txt
> >         draft-ietf-dnsop-v6-name-space-fragmentation-02.txt
> >         draft-ihren-dnsop-interim-signed-root-02.txt
> >         draft-ihren-dnsop-v6-name-space-fragment-01.txt
> >
> > (ii).   WG drafts which are ready for last call
> >         draft-ietf-dnsop-ipv6-transport-guidelines-00.txt
> >         draft-ietf-dnsop-serverid-01.txt (?)
> >
> > (iii).  Active WG drafts
> >         draft-ietf-dnsop-bad-dns-res-01.txt
> >         draft-ietf-dnsop-inaddr-required-04.txt
> >         draft-ietf-dnsop-interim-signed-root-01.txt
> >         draft-ietf-dnsop-ipv6-dns-issues-02.txt
> >         draft-ietf-dnsop-ohta-shared-root-server-02.txt
> >         draft-ietf-dnsop-respsize-00.txt
> >         draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above]
> >
> > (iv).   Expired WG drafts
> >         draft-ietf-dnsop-dontpublish-unreachable-03.txt
> >         draft-ietf-dnsop-keyhand-04.txt
> >         draft-ietf-dnsop-resolver-rollover-00.txt
> >         draft-ietf-dnsop-rollover-01.txt
> >
> > (v).    Active individual drafts
> >         draft-durand-dnsop-dynreverse-00.txt
> >         draft-hall-dns-data-03.txt
> >         draft-jeong-ipv6-ra-dns-autoconf-00.txt
> >         draft-kato-dnsop-local-zones-00.txt
> >         draft-morishita-dnsop-misbehavior-against-aaaa-00.txt
> >         draft-park-ipv6-extensions-dns-pnp-00.txt
> >         draft-warnicke-network-dns-resolution-02.txt
> >         draft-yasuhiro-dnsop-increasing-dns-server-00.txt
> >
> > IPv6 DNS Discovery -- Framing the discussion                    15 minutes
> > Rob Austein
> >
> >   IPv6 DNS Discovery, and why it is important                   10 minutes
> >   Bob Hinden
> >
> >   IPv6 Router Advertisement based DNS Autoconfiguration         10 minutes
> >   draft-jeong-ipv6-ra-dns-autoconf-00.txt
> >   Jaehoon Jeong
> >
> >   IPv6 Router Advertisement DNS resolver Option                 10 minutes
> >   draft-beloeil-ipv6-dns-resolver-option-01.txt
> >   Luc Beloeil
> >
> >   Discussion                                                    20 minutes
> >
> > A Suggested Scheme for DNS Resolution of Networks and Gateways  10 minutes
> > draft-warnicke-network-dns-resolution-02.txt
> > Edward Warnicke
> >
> > Considerations for DNS Resource Records                         10 minutes
> > draft-hall-dns-data-03.txt
> > Eric Hall
> >
> > IPv6 Extensions for DNS Plug and Play                           10 minutes
> > draft-park-ipv6-extensions-dns-pnp-00.txt
> > Syam Madanapalli
> >
> > Outstanding issues in draft-ietf-dnsop-ipv6-dns-issues-02.txt   10 minutes
> > Alain Durand
> >
> >
> > #----------------------------------------------------------------------
> > # MINUTES
> >
> > ** AGENDA BASHING **
> >
> > The agenda was adjusted slightly, by adding short time slots to give
> > room for Daniel Karrenberg to bring up issues with the .LOCAL top
> > level domain and its impact on the root name servers, and for
> > Ralph Droms to make a presentation about DHCP.
> >
> >
> > ** STATUS OF OUTSTANDING DRAFTS **
> >
> > (i).    Farewell to drafts this WG doesn't need to think about anymore
> >         draft-ietf-dnsop-hardie-shared-root-server-07.txt
> >         draft-ietf-dnsop-v6-name-space-fragmentation-02.txt
> >       draft-ihren-dnsop-interim-signed-root-02.txt
> >         draft-ihren-dnsop-v6-name-space-fragment-01.txt
> >
> > The above drafts were pronounced dead and taken off the agenda of the
> > working group.
> >
> > (ii).   WG drafts which are ready for last call
> >         draft-ietf-dnsop-ipv6-transport-guidelines-00.txt
> >         draft-ietf-dnsop-serverid-01.txt (?)
> >
> > No new issues were presented. The chairs will take the drafts to WG
> > last call.
> >
> > (iii).  Active WG drafts
> >         draft-ietf-dnsop-bad-dns-res-01.txt
> >         draft-ietf-dnsop-inaddr-required-04.txt
> >         draft-ietf-dnsop-interim-signed-root-01.txt
> >         draft-ietf-dnsop-ipv6-dns-issues-02.txt
> >         draft-ietf-dnsop-ohta-shared-root-server-02.txt
> >         draft-ietf-dnsop-respsize-00.txt
> >         draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above]
> >
> > There was no discussion during the session. These drafts are Still
> > active.
> >
> > (iv).   Expired WG drafts
> >         draft-ietf-dnsop-dontpublish-unreachable-03.txt
> >         draft-ietf-dnsop-keyhand-04.txt
> >         draft-ietf-dnsop-resolver-rollover-00.txt
> >         draft-ietf-dnsop-rollover-01.txt
> >
> > No one spoke in favour of revival of any of these. The chairs'
> > approach is to let them die.
> >
> > (v).    Active individual drafts
> >         draft-durand-dnsop-dynreverse-00.txt
> >         draft-jeong-ipv6-ra-dns-autoconf-00.txt
> >         draft-kato-dnsop-local-zones-00.txt
> >         draft-morishita-dnsop-misbehavior-against-aaaa-00.txt
> >         draft-park-ipv6-extensions-dns-pnp-00.txt
> >         draft-yasuhiro-dnsop-increasing-dns-server-00.txt
> >
> > The above drafts were deemed still active, but will remain individual
> > drafts for the time being.
> >
> > >         draft-hall-dns-data-03.txt
> > >         draft-warnicke-network-dns-resolution-02.txt
> >
> > The above drafts were decided to be under serious consideration to
> > become WG documents.
> >
> >
> > ** IPV6 DNS DISCOVERY -- FRAMING THE DISCUSSION **
> >
> > Rob Austein made a presentation to try to set the framework for the
> > discussion. The presentation is found in the meeting archives.
> >
> > Rob tried to clarify and enumerate the underlying generic problems
> > faced by a DNS consumer node.
> >
> > See presentation for details.
> >
> > Ralph Droms commented that the trust model has changed between IPv4
> > and IPv6: the IPv4 address is obviously owned by DHCP server, but in
> > an IPv6 auto-configure scenario the "host" part of the address is "owned"
> > by the host, and the "prefix" part is "owned" by the upstream router.
> >
> >
> > ** IPV6 DNS DISCOVERY, AND WHY IT IS IMPORTANT **
> >
> > Bob Hinden made a presentation trying to convey the message about why
> > DNS discovery is important. The presentation is found in the meeting
> > archives.
> >
> > Bob went through the different steps in a DNS consumer's life,
> > identifying a number of steps where DNS discovery is necessary, and
> > identifying a couple of different methods to achieve it.
> >
> > See presentation for details.
> >
> > There was a note from audience that there is an auto-registration draft
> > also in the DNSEXT WG.
> >
> > Ted Lemon also commented that the presentation seemed to conveyed the
> > message that overloading service location on names or addresses is a
> > positive thing, which he disagreed with. He was seconded by several
> > others.
> >
> >
> > ** IPV6 ROUTER ADVERTISEMENT DNS RESOLVER OPTION **
> >
> > Luc Beloeil made a very fast presentation about the IPv6 router
> > advertisement DNS resolver option. The presentation is found in the
> > meeting archives.
> >
> > See presentation for details.
> >
> > There was a comment from the audience that DHCP service often is found
> > in the upstream router anyhow, so why not use it?
> >
> >
> > ** IPV6 EXTENSIONS FOR DNS PLUG AND PLAY **
> >
> > Syam Madanapalli made a presentation regarding IPv6 Extensions for DNS
> > Plug and Play. His proposal, called 6DNAC has three steps:
> >
> > - domain name generation
> > - duplicate domain name detection
> > - domain name registration
> >
> > that were animated in the presentation.
> >
> >
> > ** CONFIGURING DEVICES FOR DNS **
> >
> > Ralph Droms make a presentation about configuring devices for DNS .
> >
> > The presentation is found in the
> > meeting archives.
> >
> > See presentation for details.
> >
> >
> > ** DISCUSSION **
> >
> > Alain Durand: Please clarify: What happens if you have DHCPv6 and RA
> >   at the same time on same segment? Does this work?
> >
> > Ralph Droms: No, I haven't tried. Have to think bout it.
> >
> > Alain: Will it create a problem?
> >
> > Ralph: If network administrators do the the right thing - no. If not,
> >   it might. It may cause unpredictable behaviour.
> >
> > Pekka Savola: What are the processes to move forward from here? We
> >   should first think carefully about in which direction we want to go,
> >   and then set up design team.
> >
> > Bob Hinden: I want to defend my presentation: the name resolution
> >   method using names like ftp... and www... was not intended to be
> >   the perfect solution to service location problem.
> >
> > Dave Meyer: I still haven't heard why DHCP is NOT the solution to
> >   this.
> >
> > Olafur Gudmundson: Ditto. Use DHCP! It's small and it's easy. Get over
> >   it!
> >
> > Matt Ford(?): Please no design team. We need this now, and a design
> >   team will take too long.
> >
> > <Unknown>: The method depends on type of network infrastructure. There
> > could be ways to do this using PPP options.
> >
> > Rob Austein: I hear different signals from the PPP group.
> >
> > <First name> Thomas: Non-DHCP stuff can be used for ad-hoc networks.
> >
> > <Unknown>: In what way are the proposed options different from DynDNS?
> >
> > Rob: They create names out of blue to have some thing to register.
> >
> > Alain: The unsolicited RA message is one-to-many. One message reaches
> >   all clients on the segment. The DHCP proposals lead to bilateral
> >   exchanges that involve at least two-packets per client.
> >
> > Rob: The security is still an issue. End client needs to verify
> >   signatures, so it needs NTP.
> >
> > Randy Bush, AD hat on: Please hum: DHCP vs. auto-discovery.
> >
> > Dave: not conclusive.
> >
> > Rob: DHCP attractive: client just sends, and just receives.
> >
> > Ted Lemon: Someone mentioned reliability issues in DHCP, but that
> >   doesn't apply to stateless DHCP in IPv6, since that is a different
> >   animal. Don't compare the two.
> >
> > Ralph Droms: DHCP "light" is not different from DHCP, it is a subset
> >   thereof.
> >
> > Dave: We have two classes of proposals: DHCP vs. discovery.
> >
> > Ted: You have to have a DHCP client anyhow on the client side. Why not
> >   use it for DNS discovery.
> >
> > Ralph: I don't think the O bit=0 means *DON'T* do DHCP.
> >
> > Dave: We will take the discussion to the list.
> >
> >
> > ** A SUGGESTED SCHEME FOR DNS RESOLUTION OF NETWORKS AND GATEWAYS **
> >
> > The author was not present. This agenda item was skipped.
> >
> >
> > ** CONSIDERATIONS FOR DNS RESOURCE RECORDS **
> >
> > The author was not present. This agenda item was skipped.
> >
> >
> > ** Problems with the .LOCAL TLD **
> >
> > Daniel Karrenberg
> >
> > The root server operators have been observing large quantities of
> > queries for names in the .LOCAL and .LOCALHOST top level domains. At
> > certain points in time and topology up to 1/3 of the query load. If
> > anything else thatn root name servers were hit by this type of data
> > stream, it would be called a DOS attack. :-) What can we do about
> > this? For now: just answer. In the future we might want not to answer,
> > but that is a decision that cannot be taken by the root name server
> > operators. An alternative is to delegate them to query sinks (... and
> > eventually to get the clients fixed).
> >
> > Akira Kato has written a draft that addresses these issues. Daniel
> > asked the chairs 1) what the status of the draft is, and 2) how to
> > proceed.
> >
> > Rob: Kato's draft was presented in San Francisco (56th IETF), but at
> >   the time it was so new new that not no one had had an informed
> >   opinion. Nothing has happened since. Also: it might create a dangerous
> >   precedence.
> >
> >   Please hum: WG item (intending a BCP) or not? Result: WG item!
> >
> >
> > ** OUTSTANDING ISSUES IN draft-ietf-dnsop-ipv6-dns-issues-02.txt **
> >
> > Alain Durand talked briefly about outstanding issues in
> > draft-ietf-dnsop-ipv6-dns-issues-02.txt. It's almost ready for last
> > call. Remaining issues: what do about reverse domain space, especially
> > prepopulation? Another revision with focus on reverse prepopulation is
> > planned.
> >
> >
> > ** DS UPDATE IN PARENT **
> >
> > Mohsen Souissi
> >
> > DNSSEC is getting more and more operational. Test beds in different
> > places. What about update DS in parent? We need operational
> > requirements before working.
> >
> > Randy, AD hat on: This is one of the main focuses of the group! If not
> >   interested there will be consequences ... ;-) Degenerate case:
> >   root key management.
> >
> > It was found to be a suitable WG item. :-)
> >
> > The meeting was closed.
> > #----------------------------------------------------------------------
> > #----------------------------------------------------------------------
> > # To unsubscribe, send a message to <dnsop-request@cafax.se>.
>#----------------------------------------------------------------------
># To unsubscribe, send a message to <dnsop-request@cafax.se>.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.