[tcpm] AD review of PRR draft

[Wesley Eddy <[e-mail]>]

I've completed AD review of this document and have a few small
comments, some of which should be cleared up before going to
the IESG review.  It is basically in really good shape, but I
see painful DISCUSS ballots coming if we don't clean up these
small things:


(1) It's really minor, but SACKs report received data, not lost
data.  Lost data is inferred from what wasn't SACK'ed.  A couple
places (like the last sentence of the 3rd paragraph in Section 1)
indicate that SACKs report missing data.  I know what you really
mean, but it's technically wrong.


(2) All the references to 3517 probably made sense when the doc
was first written, but will really confuse the IESG, now that
6675 obsoletes 3517.  I *think* we can change all instances of
3517 to 6675 and they all still work ... I know that it already
says:
"""
The analysis and measurement study presented here predates [RFC6675],
which updates RFC 3517.
"""
How about something like:
"""
The analysis and measurement study presented here predate [RFC6675],
which updates RFC 3517.  Thus, RFC 3517 was used as the basis for
comparisons and some definitions, however, it is believed that the
changes in RFC 6675 do not significantly alter the results.
"""
Would that be true?  If so, we should do this and change the
references.  If not, then we need to do a little bit more
explaining about what in 6675 would change things.


(3) We are constantly seeing the IESG ask "What is the experiment?"
for Experimental RFCs.  Indeed, the WG even asked this during the
last call when we looked at going to Standards Track.  We should
have a paragraph (probably in section 6) that indicates a bit more
why we stuck with Experimental.  A less cryptic version of what
Matt said in the WGLC thread would probably be good:
"""
Finally there are some details in PRR that are effected by Laminar.  I
would rather not go to the effort of fixing the current draft to make
it a proper normative PS, but not totally correct.  (Hint: Yoshifumi
Nishida's "off by one" comment reflects the difference between pipe
and total_pipe).
"""

-- 
Wes Eddy
MTI Systems