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

Reply via email to