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

[Theresa Enghardt <[e-mail]>]

Hi,

Thanks for the replies, Spencer and Michael, and thanks for the revision.
This addresses all my comments.

Best,
Theresa


On 10.01.20 01:08, Spencer Dawkins at IETF wrote:
> Hi, Theresa,
>
> Thank you for your help with this document! Please see comments inline
> below.
>
> Best,
>
> Spencer
>
> On Mon, Jan 6, 2020 at 6:22 AM Theresa Enghardt <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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?
>
>
> Done. 
>  
>
>     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.
>
>
> The intention was to say "insufficient motivation". I changed this
> term to be "Justifying Deployment", which I hope is clearer. 
>  
>
>     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.
>
>
> In addition to the new section 1.2, I tried to make this section clearer.
>  
>
>     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.
>
>
> Good point. "Everybody" knows this, but enough people didn't know it
> to justify the "Spherical Routers" session at IETF 104.
> (https://datatracker.ietf.org/group/wgtlgo/meetings/). I added some
> details here. 
>  
>
>     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?
>
>
> Well, THAT was embarrassing ... swapped now!
>  
>
>
>     Nit: "long term, term trust relatioship" -> duplicate "term"
>
>
> Thanks for spotting this. 
>  
>
>
>     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 wrote the text with a specific problem in mind, but you are pointing
> to it being more general. I tried to make this clearer. 
>  
>
>
>     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".
>
>
> Rephrased without 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?
>
>
> Yeah, I failed to parse it, too. A long time ago, it made sense to me.
> Rephrased. 
>  
>
>
>     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?
>
>
> I took Michael's suggestion to the limit - I deleted the reference to
> DCCP QuickStart, because it wasn't adding any information to the
> lesson. But too your larger point ...
>
> I agree this is a general problem, but the contribution I was
> analyzing was a single mechanism exhibiting the problem. I rephrased
> without "in these cases" - I don't think it added anything, but seemed
> to be TRYING to add something. 
>  
>
>
>     "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?
>
>
> I took Michael's suggestion here as well. 
>  
>
>
>     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"?
>
>
> This is about waking up the TCP that's been sitting quietly, because
> retransmitting over a known-out-of-service-interface doesn't help. 
>
> The problem was that I was using the passive voice. Now it's "somehow
> something along the path could signal TCP", which is about as much
> clarity as we had in initial discussions about TRIGTRAN :D ...
>  
>
>     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.
>
>
> This was phrased badly. Changed to "provide multihoming for IPv6 sites". 
>  
>
>     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?
>
>
> This is the same issue you tagged in 2.7, which isn't surprising
> because 2.7 is a lesson that references this contribution. Added
> details here, too. 
>  
>
>
>     "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.
>
>
> This contribution expanded beyond NSIS a bit here - contributions in
> Section 5 should be focused on a specific technology. I was able to
> replace most occurrences of "end-to-end" referring to NSIS in this
> section, which avoided the problem. 
>  
>
>     Best,
>     Theresa
>
>