Subject: [tcpm] AD review of PRR draft

From: Wesley Eddy <[email-masked]>
Date: Sun, 25 Nov 2012 23:48:10 -0500

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2012 22:17:52 -0800

On Nov 25, 2012, at 8:48 PM, Wesley Eddy <[email-masked]> wrote:
> for Experimental RFCs. ...

That seems like useful info to report to the Nomcom.  That sort of ignorance ought to justify relieving that party of their appointment.

Fwiw, it may stem from the following, e.g., section 3 item 1. It may continue to confuse the point that the protocol itself is the experiment. 
http://www.ietf.org/iesg/informational-vs-experimental.html

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 26 Nov 2012 09:45:22 -0500

On 11/26/2012 1:17 AM, Joe Touch wrote:
> 
> 
> On Nov 25, 2012, at 8:48 PM, Wesley Eddy <[email-masked]
> <mailto:[email-masked]>> wrote:
> That seems like useful info to report to the Nomcom.  That sort of
> ignorance ought to justify relieving that party of their appointment.
> 
> Fwiw, it may stem from the following, e.g., section 3 item 1. It may
> continue to confuse the point that the protocol itself is the experiment. 

The question isn't Informational vs Experimental, but rather one
of "if the algorithm is really as good as you say it is, and if
you've already got this large measurement study done, and it looks
like it's clearly okay, then why is TCPM not coming with it for
Proposed Standard?".

I think, in general, the point is just that we should be specific
about whether there are aspects of the protocol/algorithm that we
aren't really sure about yet.  For instance, the current document
is really good about this in terms of PRR-CRB vs PRR-SSRB, by
explaining the differences and why an implementation might favor
one over the other.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2012 09:57:50 -0800

> like it's clearly okay, then why is TCPM not coming with it for

That seems like the IESG pushing things towards PS; the default ought to 
be "not PS" unless there is community consensus. Is it really necessary 
to explain that to the IESG? Or do they not believe TCPM when we make a 
recommendation?

> aren't really sure about yet.

That's not the only case for Experimental. It can also be that there is 
insufficient operational experience, insufficient interest in 
implementing/deployment. The latter does not imply a lack of confidence 
in the algorithm or parameters.

Again, it's disturbing that there is a need t constantly remind the IESG 
of this.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 26 Nov 2012 15:22:08 -0500

> to explain that to the IESG? Or do they not believe TCPM when we make a

I think it's perfectly fair for people to ask what the rationale
for a decision is, and for that rationale to be part of the document.
In N years, when someone comes to ask to move to the Standards Track,
this gives a starting point for assessing if it's ready.

Just so we're clear, the IESG hasn't asked for this yet.  I'm saying
that it's a common question when rationale isn't clear, and I'm
personally saying that it's not clear in this I-D.  The rest of the
IESG hasn't said anything about it, and I'd like to address it in
the I-D so they won't wonder.  Nobody is trying to counter the WG's
decision or push towards PS; in fact, I fully agree with you that
the default should be "not PS" without strong consensus.

> in the algorithm or parameters.

Exactly.  Do you believe that the I-D says which of these is the case?
On the contrary, it gives a lot of measurement data, and talks about
implementation and deployment experience at a large site.

> Again, it's disturbing that there is a need t constantly remind the IESG

So far, this is in the AD Review state and it's my comment, so you
aren't reminding the rest of the IESG about anything yet :).

-- 
Wes Eddy
MTI Systems

---

From: Matt Mathis <[email-masked]>
Date: Tue, 27 Nov 2012 11:08:58 -0800

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 <[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Matt Mathis <[email-masked]>
Date: Tue, 27 Nov 2012 11:12:00 -0800

The addresses on your earlier message were corrupted. Replying bounced.
--MM--
The best way to predict the future is to create it.  - Alan Kay

---------- Forwarded message ----------
From: Matt Mathis <[email-masked]>
Date: Tue, Nov 27, 2012 at 11:08 AM
Subject: Re: [tcpm] AD review of PRR draft
To: Wesley Eddy <[email-masked]>
Cc: "[email-masked]"@
atl4mhob08.myregisteredsite.com, "[email-masked]" <[email-masked]>

Thanks,
--MM--