Re: [tcpm] AD review of PRR draft

[Matt Mathis <[e-mail]>]

Your comments are on the mark: I will roll a new draft.

I agree with Joe, however I know there are communities that desperately
want "RFC" to mean something other than "Request For Comments" because they
depend on PS status to compel manufacturers to do things that they don't
want to do.  These communities are undermined by the existence of strong
well established de facto standards that are only weakly documented in the
IETF process.

Pissing on the entire process (as I did in my prior rant on the subject)
isn't really constructive, and potentially harms areas like network
management, where it is important to be able to write contract language
that explicitly requires verbatim implementations of RFC.

I will do your item (3) as a concession to the IETF process mongers.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.


On Sun, Nov 25, 2012 at 8:48 PM, Wesley Eddy <[e-mail]> wrote:

> 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
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>