Subject: review of draft-ietf-node-req-bis

From: Jari Arkko <[email-masked]>
Date: Wed, 25 May 2011 21:22:35 +0300

I have reviewed this draft. In general, this version is well written, I 
agree with the recommendations, and I'd like to thank everyone for 
working on this much needed update. I think the document is ready to go 
to IETF Last Call -- some minor issues below that I think could be 
addressed even during the last call.

However, since I was part of the original design team that worked RFC 
4294, I have asked Ralph to formally handle this document. He has 
promised to do so. (Thanks!)

My comments:

> Consequently, IPv6 Jumbograms [RFC2675 <http://tools.ietf.org/html/rfc2675>] remain optional at this time.

Other sections use RFC 2119 keywords (MAY) to state this. Consider using 
that style here as well.

> Static address may be supported as well.
>   

"Static addresses may be ..." or "Configuration of static address(es) 
may be ..." might be a better formulation.

> For general purpose devices, RFC 4429 is not   
>             considered to be necessary at this time.

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.

> Consequently, DNS configuration
> information can now be learned either through DHCP or through RAs.
> Hosts will need to decide which mechanism (or whether both) should be
> implemented.
>   

I would make a forward reference here and add: "Specific guidance 
regarding DNS server discovery is discussed in Section 7." This is 
because for that specific issue we do have something stronger to say 
than the above text .

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

Jari

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 May 2011 14:33:47 -0400

Hi Jari.

Some quick thoughts.

I'm OK with most of your comments  (they are mostly editorial).

I personally think the IETF has gotten too formal wanting the word MAY
when it ends up being stilted English. But that said, the wording
(english) could still be improved as you note.

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

Also, just who has implemented 4429? Do we actually have real
experience with it?

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

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 May 2011 21:47:04 +0300

Thomas,

> 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

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.

> with relay agents relaying packets to it...

Ok. Well, require a relay agent or a server then?

Jari

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2011 05:57:30 +0930

On Wed, 25 May 2011 21:47:04 +0300
Jari Arkko <[email-masked]> wrote:

> 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 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------