Subject: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.txt

From: David Meyer <[email-masked]>
Date: Thu, 9 Sep 2004 08:57:54 -0700

Folks

	This note starts what I hope is the last WG Last Call for
	comments on draft-ietf-dnsop-ipv6-dns-configuration-03.txt, 
	"IPv6 Host Configuration of DNS Server Information
	Approaches". It can be found on 
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-03.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. 

	Please note that this is a somewhat unusual case as the
	IESG requested this document as input to their decision
	process regarding IPv6 DNS (host) configuration. That
	being the case, please state only substantial comments.

	This Last Call will end on 23 Sep 2004 at 1400 PDT (UTC/GMT-7). 

	Thanks,

	Dave

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 10:19:28 +0300 (EEST)

> 	not you believe that this document is ready to go to the
[...] 
> 	This Last Call will end on 23 Sep 2004 at 1400 PDT (UTC/GMT-7). 

Unfortunately, I think this still needs a spin as my earlier comments 
were not (IMHO) adequately addressed.

substantial
-----------

I already commented on the link-layer WLAN "bashing", and the text is 
now better, but IMHO not sufficiently so.

Trying to pre-empt another revision cycle, let me try to suggest
something I wouldn't have problems with -- rewriting section 3.1 to
something like below (note new paragraphs -- the existing ones were
ridiculously long!):

   RA approach is to define a new ND option called RDNSS option that
   contains a recursive DNS server address.  Existing ND transport
   mechanisms (i.e., advertisements and solicitations) are used.  This
   works in the same way that nodes learn about routers and prefixes.  
   An IPv6 host can configure the IPv6 addresses of one or more
   RDNSSes via RA message periodically sent by router or solicited by
   a Router Solicitation (RS) [8].

   This approach needs RDNSS
   information to be configured in the routers doing the
   advertisements.  The configuration of RDNSS address can be
   performed manually by operator or other ways, such as automatic
   configuration through DHCPv6 client running on the router.  When
   advertising more than one RDNSS options, an RA message includes as
   many RDNSS options as RDNSSes.  

   Through ND protocol and RDNSS
   option along with prefix information option, an IPv6 host can
   perform its network configuration of its IPv6 address and RDNSS
   simultaneously [3][4].  The RA option for RDNSS can be used on any
   network that supports the use of ND.

   However, it is worth noting that some link layers (e.g., WLAN)
   need to acknowledge multicast packets, which may increase the 
   amount of link-layer traffic.  This is discussed in Appendix A.

   The RA approach is useful in some mobile environments
   where the addresses of the RDNSSes are changing because the RA
   option includes a lifetime field that allows client to use RDNSSes
   nearer to the client.  This can be configured to a value that will
   require the client to time out the entry and switch over to another
   RDNSS address [8].  However, from the viewpoint of implementation,
   lifetime would seem to make matters a bit more complex.  Instead of
   just writing DNS configuration file, such as resolv.conf for the
   list of RDNSS addresses, we have to have a daemon around (or a
   program that is called at the defined intervals) that keeps
   monitoring the lifetime of RDNSSes all the time.
                                                                                                                  
   The preference value of RDNSS, included in RDNSS option, allows
   IPv6 hosts to select primary RDNSS among several RDNSSes; this can
   be used for load balancing of RDNSSes [8].

Appendix A - Link-layer Multicast Acknowledgements with RA option

   One benefit of RA option has been to be able to multicast the 
   advertisements, reducing the need for duplicated unicast 
   communications.

   However, some link-layers may not support this as well as others.
   Consider, for example, WLAN networks
   where multicast is unreliable.  The unreliability problem is caused
   by lack of ACK for multicast, especially on the path from the
   Access Point (AP) to the Station (STA), which is specific to
   CSMA/CA of WLAN.  Namely, multicast packet is unacknowledged on the
   path from the AP to the STA, but acknowledged in the reverse
   direction from the STA to the AP.  For example, when a router is
   placed at wired network connected to an AP, a host may sometimes
   not receive RA message advertised through the AP.

   The fact that this problem has not been felt to be a problem in 
   Neighbor Discovery [RFC2461] indicates that the extra link-layer
   acknowledgements have not been felt to be a serious problem,
   at least until as of this writing.

   A possible mitigation technique could be mapping all-nodes 
   link-local multicast address to the link-layer broadcast address,
   and relying on the ND retransmissions for message delivery.

(feel free to gripe about the shortcomings of Neighbor Discovery in
WLAN environments in an appendix if you feel it's warranted, but
please don't do that in the body of the memo!)

editorial
---------

3.3 Well-known Anycast Addresses
[...]

==> I already commented on this, but I think it would be useful to use 
'shared-unicast' -terminology instead, or at least refer to that to 
disambiguate with "IPv6 anycast".  After all, that's a good 
terminology (coined in the IESG evaluation), based on 
draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt.  

I could live with 'anycast' here, but I'd think it would be confusing 
especially if you don't mention "shared unicast" at all..

3.1.2 Disadvantages
                                                                                                                  
   1) ND is mostly implemented in kernel part of operating system.
   Therefore, if ND supports the configuration of some additional
   services, such as DNS, NTP and SIP servers, ND should be extended
   in kernel part, and completed by a user-land process.

==> s/completed/complemented/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 23 Sep 2004 17:30:13 +0900

Pekka Savola;

> I already commented on the link-layer WLAN "bashing",

There has never been and still never is any WLAN bashing.

My comment to your comments is that your comments are
substantially poor.

						Masataka Ohta

.

---

From: "Jaehoon Jeong" <[email-masked]>
Date: Fri, 24 Sep 2004 11:50:59 +0900

Hi Pekka and Ohta-san,

How can we compromise on the term "anycast" in our draft?
How about the addition of "shared-unicast" below?

   First of all, the well-known anycast addresses approach is much 
   different from that discussed at IPv6 Working Group in the past [9].
   It should be noted that "anycast" in this memo *, which means shared-unicast,*
   is simpler than that  of RFC1546 [11] and RFC3513 [12] where it is assumed to be 
   prohibited to have multiple servers on a single link sharing an 
   anycast address. 

If both you are okay with my suggestion, I'll go ahead :-)

Thanks.

Paul

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>

.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Sep 2004 07:51:46 +0900

> How can we compromise on the term "anycast" in our draft?

Just keep it.

> How about the addition of "shared-unicast" below?

If you insist on "shared-unicast" issue, I suggest the
following text.

   First of all, the well-known anycast addresses approach is
   anycast used in the real world, which is much different from
   that discussed at IPv6 Working Group in the past [9].
   It should be noted that "anycast" in this memo and in the
   real world is simpler than that of RFC1546 [11] and RFC3513
   [12] where it is assumed to be prohibited to have multiple
   servers on a single link sharing an anycast address. 

   To avoid the confusion, IPv6 WG should coin a new terminology
   for their own addressing scheme or, better, just remove the
   concept, which is not yet have any useful purpose, entirely.

						Masataka Ohta

.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 27 Sep 2004 13:17:11 +0300 (EEST)

>    concept, which is not yet have any useful purpose, entirely.

The IESG will choke and spit that out, but if you (meaning the WG,
chairs and co-authors) think that's OK, go ahead.

I'd prefer to have 'shared-unicast' in there though.

.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 27 Sep 2004 20:48:01 +0900

>chairs and co-authors) think that's OK, go ahead.

That is not a valid counter argument in IETF WGs.

Conglaturations that you have successfully qualified
yourself as a person not to be able to contribute
productive discussions.

The reality is that the real world have choked and spitted
IPv6 out with so many valid reasons some of which I pointed
out.

					Masataka Ohta

.

---

From: David Kessens <[email-masked]>
Date: Mon, 27 Sep 2004 06:39:47 -0700

Masataka, 

> IPv6 out with so many valid reasons some of which I pointed

There are different ways to express your disagreement. Your discussion
style is unacceptable and disrupts the work of the working group. I
have warned you before about this. I warn you again that I am quickly
running out of patience.

David Kessens
---
.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 28 Sep 2004 05:35:48 +0900

David Kessens;

> There are different ways to express your disagreement.

If you think there is any technical point in Pekka's expression
of his disagreement, show us an example of technical
disagreement.

						Masataka Ohta

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Sep 2004 08:23:10 +0300 (EEST)

On Tue, 28 Sep 2004, Masataka Ohta wrote:
> If you think there is any technical point in Pekka's expression of
> his disagreement, show us an example of technical disagreement.

Do you think there is no technical (or procedural) point in saying
basically 'The IESG will not like this text, it *will* be returned to
the WG for revision, and this text will need to change in any case' ?

I'd certainly prefer if we used some less controversial text with even
a slim chance of getting through, without having to spend a month or
two revising it.

.