Document:   draft-ietf-v6ops-onlinkassumption-03.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date:  Monday 12/12/2005 6:05 PM CST
Telechat Date:  Thursday 12/15/2005

Summary: this specification is headed the right direction for publication as 
an Informational RFC, but still needs some work in a couple of places that 
were confusing to me (and I thought I understood the topic).

Comments:

If I understand this document correctly, it's telling me that the on-link 
assumption was put in place to allow communication between two hosts with 
different global prefixes in the absence of an IPv6 router, and that this 
assumption causes problems (see section 3 for details), so the assumption 
should be removed (see section 4 for details). Right so far? Stop me now, or 
...

- The specification is arguing for the removal of the assumption, but 
doesn't ever actually say whether we just don't care any more about 
communications in the absence of an IPv6 router when two hosts with 
different global prefixes are on the same link, or if there is some other 
mechanism that now allows this communication to succeed without the 
assumption. I think I know what actually happens, but I'm guessing. I'd just 
like to see this spelled out a bit more clearly.

- Section 3.3 is a lot less clear than the other parts of section 3. It 
wasn't clear to me whether dropping the packet is actual behavior in 
deployed hosts or not, and I wasn't sure whether dropping the assumption 
fixed all the problems with multiple links (I think it does, but I'm reading 
between the lines). I suspect that the problem is that, in the absence of 
one defined behavior, you're trying to describe multiple problems at once, 
but Section 3.3 is still confusing (that's why I'm not sure I can suggest 
replacement text, beyond, "There are three things that an implementation can 
do with a packet when faced with multiple interfaces and the on-link 
assumption, and all of them are bad, and only the most complex action is 
likely to work even most of the time" - is that the point?)

- In section 5, I'm guessing you are telling me that the removal of the 
assumption "removes all of the security-related vulnerabilities of the 
protocol as described in Section 3.4", but the current text says "removes 
some vulnerabilities as described", and "some" is ambiguous.

Minor nits:

- It bothers me that an observed implementation error is used in Section 3.4 
to justify changing the protocol. I understand the problem, but OS 
implementations may be broken in lots of ways, right? Probably doesn't 
matter because there are so many other justifications, but...

- Since RFC 1122 is, like, 116 pages long, it would be nice to include the 
section number (4.2.3.5) in the reference at the bottom of page 4.

I hope this is helpful - most of the text is very clear, but there are just 
some places that faded out on me.