On Wed, 25 May 2011 21:47:04 +0300 Jari Arkko <jari.ar...@piuha.net> wrote:
> Thomas, > > >> Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the > >> norm than exception today. At the very least, I'd again use the MAY > >> keyword for this specification. The above sounds almost like > >> recommending to not implement it. > >> > > > > Just how much time does 4429 shave of the restarting of a device? not > > much I think. Couple of seconds? In reality, devices that are > > sleeping/waking take more than that to restore their state ... > > > > Speak for your own devices :-) Seriously though, you are right of course > that this may not be a big factor. That being said, button press - > Internet is usable time is a significant usability factor in many > devices. And on low-powered nodes the time spent having to wait before > the device can go to sleep again can easily increase battery usage > significantly. So I wouldn't rule out that its a significant issue in > some cases. > > > Also, just who has implemented 4429? Do we actually have real > > experience with it? > > > > Not much if any experience -- agreed. I thought there was at least one > implementation. The Linux kernel has had an implementation since July 2007, although it is disabled by default. (2.6.22 release) A google search shows that apparently it was enabled by default for Opensuse recently to "to improve support for NFS over IPv6." http://gitorious.org/opensuse/kernel-source/commit/5e2ee40f92751c17694c51adaef00c35b00efe6f/diffs But I guess we are having a philosophical discussion of > what it takes to make a spec get a MAY in this document. I definitely > agree that MUST or SHOULD is out of question. I think it would be fair > to list the implementation and deployment experience in the draft, which > you do for many specifications. This is the interesting information for > the reader, and they can draw their own conclusions. But I also think > that extensions in standards track RFCs deserve to be clearly marked as > potential specifications to implement. > > >> (And based on my own experience of running non-IPv4 networks that > >> desperately need DNS discovery, somewhere in Section 7 I think you > >> should require that routers with attached hosts actually support both > >> (stateless) DHCP and RA-based DNS discovery.) > >> > > > > The trouble with routers being required to implement stateless is that > > they don't need to. You can have one DHC server for an entire site, > > with relay agents relaying packets to it... > > > > Ok. Well, require a relay agent or a server then? > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
