Re: [PANRG] RG Last Call for draft-irtf-panrg-what-not-to-do-05

[Theresa Enghardt <[e-mail]>]

Dear PANRG,

I recently gave this document a thorough read from my perspective as a
researcher of Path Aware technologies.

As I have not been around yet for the development of most of the
technologies listed in this document, I find its "lessons learned" to be
quite a valuable resource.
So, again, thank you for writing it!

To make this document even more accessible to researchers wanting to
learn from it, I have a few comments, see below.

Once these are addressed, I think this document is ready for publication.


Section 1:

Maybe it's worth adding one paragraph with a short definition or
description of what we mean by Path Aware technologies here, e.g., at
the very beginning?

Section 2.1:

What exactly does "Overcoming Entropy" mean? To me, entropy sounds like
this is about the ecosystem of deployed hardware/software being too
diverse or chaotic, so the benefits of the proposed Path Aware solution
do not outweigh the costs. But the rest of the paragraph also sounds
like this is about trying to solve a non-problem, or a problem with
insufficient motivation to solve it? Or is this both?
Maybe I just fail to capture all the nuances of the colloquial American
English expression as a non-native English speaker. ;)
I think adding a clarifying sentence to make the lesson more explicit
would help here.

Section 2.3:

This is about multiple possible solutions to the same problem, right,
one being end-to-end and another being Path Aware? So is Path Aware
necessarily not end-to-end? This goes back to comment on considering to
add a definition of Path Aware technologies to Section 1.

Section 2.7:

What is the relationship between "Keeping Traffic on Router Fast-paths"
and "Router Alert Options (RAO)"? Does RAO mean that the traffic cannot
be fast-path anymore? This seems to be implicitly said here, but I think
adding a sentence to make this explicit would help.

Section 2.9:

The section heading says "Intermediate Devices Trusting Endpoints", but
the text is about endpoints not relying on signals from intermediate
devices. This seems odd to me.
Maybe the headings of 2.8 and 2.9 should be swapped, because 2.8 appears
to be about operators of intermediate devices not using signals from
endpoints and 2.9 seems to be about endpoints not using signals from
intermediate devices?

Nit: "long term, term trust relatioship" -> duplicate "term"

Section 2.11:

Does "Providing a new feature/signal [does not mean that that the
feature/signal will be used]" refer to the problem that a stack
implements the possibility to set, e.g., an additional variable, but
then an application using the stack fails to set this variable? Or is
this about the stack setting the variable, and then an application would
have to interpret this variable, but fails to do so? Or both?
I guess here, in the first sentence, I am confused about what exactly is
meant by "provide", "use", or "utilize" a signal - implementing support
for setting a variable, actually setting the variable, or interpreting
the variable which has been previously set by someone else?

I think another example of this problem is Section 5.8.

Section 3:

When categorizing the lessons as "invariant", "variable", or "dragons",
I guess "dragons" is kept vague on purpose. Still, I'm wondering if we
could make this a bit more clear - Does "dragons" mean that we don't
know if the lesson is invariant or variable, or that we don't want to
comment on it, or that the problem is open-ended?
Maybe adding one more sentence here makes sense, especially for
non-native English speakers who might not be familiar with the phrase
"here be dragons".

In the last paragraph, I fail to parse the following sentence: "[TAPS]
will justify consideration of the current state of play for Path Aware
Networking proposals for some time to come" - Does that mean that we
think TAPS might change this lesson, thus, the lesson should be
re-evaluated after some time?

Section 5.3:

"[…] In these cases, a sender cannot easily determine an appropriate
initial sending rate, given the lack of information about the path"
What does "these" refer to here? Isn't this a general problem?

"One challenge is synchronization of information between different
packets […]"
What does synchronization mean here? That a router signals for two flows
that there's capacity?

Section 5.5:

"[…] somehow TCP could be signaled when that link returned to service"
Should this be "somehow TCP could signal when the link returned to service"?

Section 5.6:

"work began on a protocol that would provide the same benefits for
multihomed IPv6 sites […]"
Same benefits as IPv4 multihomed sites? The previous sentence talks
about problems, not benefits.

Is the sentence starting with "In addition, the usual concerns about
firewalls […]" missing a verb?

Section 5.7.1:

"One reason for the non-deployment of NSIS is the usage of the IPv4 and IPv6
   Router Alert Option (RAO) to allow for an efficient interception of
   those path-coupled signaling messages"
As someone not familiar with RAO, this sentence reads a bit confusing to
me - it was not deployed because it is efficient?

"End-to-end signaling approaches were considered problematic […]"
So is NSIS an end-to-end signaling approach? I thought Path Aware
technologies were not end-to-end (Section 2.3)? To me, end-to-end by
default means "end host to end host", without considering any
intermediate device, but I think this paragraph means something else by it.
I think adding a sentence explaining who the "end to end" is here would
help.


Best,
Theresa