Re: draft vienna minutes (sorry about the delay)

[Tim Chown <tjc@ecs.soton.ac.uk>]

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