Re: [PANRG] [LB] Questions about draft-irtf-panrg-what-not-to-do-19.txt

[Spencer Dawkins at IETF <[e-mail]>]

Dear RFC Editor,

Thank you for the opportunity to translate what I wrote into what people
can understand :-)

I am cc:ing PANRG, just to keep them in the loop - I don't think there's
much here that's non-editorial, but I'd rather be surprised by discovering
that I'm wrong earlier, rather than later.

Inline answers follow.

Best,

Spencer

On Wed, May 5, 2021 at 12:05 PM <[e-mail]> wrote:

> Hi, Spencer.
>
> We are in the process of editing draft-irtf-panrg-what-not-to-do-19 and
> have a preliminary list of questions for you.
>
> Apologies for the long list of questions, but addressing these questions
> earlier in the publication process will make the AUTH48 state (
> https://www.rfc-editor.org/pubprocess/) go more smoothly.
>

You are too polite to point out that I should be apologizing to you, that
the question list is so long. Thank you for your gentleness.

Most of what follows is pretty straightforward. I either said "yes, please
do what you suggest", or "what about this?"

There are a few places where I need more help - please scan for "Spencer
question:"


> Please reply so that your document will move forward in the publication
> process.
>
> Thank you very much!
>
> RFC Editor/lb
>
> 1) Section 3:  This sentence was difficult to follow, as it
> appeared to say that Section 6.1 was published in the 1970s.  Also,
> because the RFCs listed in Section 6.1 were published in the 1990s,
> we updated as listed below.  Please let us know if this is incorrect.
>
> Original:
>  The earliest Path-Aware Networking technique referred to in
>  Section 6 is Section 6.1, published in the late 1970s.
>
> Currently:
>  The earliest Path-Aware Networking technique referred to in
>  Section 6 is [IEN-119], which was published in the late 1970s; see
>  Section 6.1.
>

Yes, please, keep this change.


> 2) Section 4:  We had trouble following these sentences.
> In the first sentence, the "and"/"but" relationship isn't clear.
> In the second sentence, Sections 6.6 and 6.6.3 appear to cover two
> different topics.  If the suggested text is not correct, please
> clarify "both ... and ... but" and "as one example".
>
> Original:
>  The research group discussed
>  distinguishing between obstacles that impede and obstacles that
>  prevent, but it appears that the boundary between "impede" and
>  "prevent" can shift over time - some of the Lessons Learned are based
>  on both Path Aware techniques that were not deployed, and Path Aware
>  techniques that were deployed, but were not deployed widely or
>  quickly.  See Section 6.6 and Section 6.6.3 as one example of this
>  shifting boundary.
>
> Suggested:
>  The research group discussed
>  distinguishing between obstacles that impede and obstacles that
>  prevent, but it appears that the boundary between "impede" and
>  "prevent" can shift over time - some of the Lessons Learned are
>  based on both a) Path Aware techniques that were not deployed and
>  b) Path Aware techniques that were deployed but were not deployed
>  widely or quickly.  See Sections 6.6 and 6.6.3 for examples of this
>  shifting boundary.
>

 Yes, please, keep this change.

3) Section 4.9:  We had trouble following the punctuation
> in this sentence.  Are the commas after "one" and "low" necessary?
>
> Original:
>  We note that "trust" is not binary -
>  one, low, level of trust applies when a node issuing a message can
>  confirm that it has visibility of the packets on the path it is
>  seeking to control [RFC8085] (e.g., an ICMP message included a quoted
>  packet from the source).
>
> Possibly:
>  We note that "trust" is not binary -
>  one low level of trust applies when a node issuing a message can
>  confirm that it has visibility of the packets on the path it is
>  seeking to control [RFC8085] (e.g., an ICMP message included a quoted
>  packet from the source).


Yes, please keep that change.

After looking at this more closely, perhaps

We note that "trust" is not binary -
 one low level of trust applies when a node receiving a message can
 confirm that the sender of the message has visibility of the packets on
the path it is
 seeking to control [RFC8085] (e.g., an ICMP Destination Unreachable
message that includes
 the Internet Header + 64 bits of Original Data Datagram payload from the
source).


If you think a reference to RFC0792 for ICMP is helpful, that RFC is
already in the references section.


> 4) Section 5:  We see that [Conviva] defines  "CDNs" as
> "Content Delivery Networks".  Would you like to update this sentence
> to match?
>
> Original:
>  -  There are end-to-end measurement techniques that can steer
>     traffic at the application layer (Content Distribution
>     Networks, multi-CDNs like Conviva [Conviva], etc.)
>
> Possibly:
>  -  There are end-to-end measurement techniques that can steer
>     traffic at the application layer (Content Delivery Networks
>     (CDNs), multi-CDNs like Conviva [Conviva], etc.).
>

Yes, please keep this change.

That's even the expansion we used in
https://datatracker.ietf.org/wg/cdni/about/ :-)

5) Section 5:  We expanded "TSPEC" as "Traffic
> Specification" per [I-D.ietf-tsvwg-intserv-multiple-tspec].  Please
> let us know any concerns.
>
> Original:
>  To date, attempts to help them
>  haven't gotten anywhere (e.g. the multiple-TSPEC additions to
>  RSVP to attempt to mirror codec selection by applications
>  [I-D.ietf-tsvwg-intserv-multiple-tspec] expired in 2013).
>
> Currently:
>  To date, attempts to help them
>  haven't gotten anywhere (e.g., the multiple-TSPEC (Traffic
>  Specification) additions to RSVP to attempt to mirror codec
>  selection by applications [INTSERV-MULTIPLE-TSPEC] expired in
>  2013).
>

  Yes, please keep this change.


> 6) Section 6.1:  Does "flow specification" as used in these
> sentences mean "Flow Specification (Flow Specs) [RFC2210]" as used in
> Section 6.2, or is the term used generally here?
>
> Original:
>  ST2 used a control plane layered over IP to select routes and reserve
>  capacity for real-time streams across a network path, based on a flow
>  specification communicated by a separate protocol.  The flow
>  specification could be associated with QoS state in routers,
>  producing an experimental resource reservation protocol.
>

"None of the above". The term is defined, along with FlowSpec, in
https://tools.ietf.org/html/rfc1819.

That flow specification has nothing to do with the flow specification in
RFC 2210. Awesome, no?


> 7) Section 6.2:  We changed "Mpbs" to "Mbps" here.  Please
> let us know if this is incorrect.
>
> Original:
>  Internet Service
>  Providers built networks over DS3 (45 Mbps) infrastructure, and sub-
>  rate (< 1 Mpbs) access was common.
>
> Currently:
>  Internet Service
>  Providers built networks over DS3 (45 Mbps) infrastructure, and sub-
>  rate (< 1 Mbps) access was common.
>

  Yes, please keep this change.


> 8) Section 6.2.2:  This sentence is difficult to parse.
> If the suggested text is not correct, please clarify.
>
> Original:
>  In environments where IntServ has been deployed, trust relationships
>  with endpoints are very different from trust relationships on the
>  Internet itself, and there are often clearly-defined hierarchies in
>  Service Level Agreements (SLAs), and well-defined transport flows
>  operating with pre-determined capacity and latency requirements over
>  paths where capacity or other attributes are constrained.
>
> Suggested:
>  In environments where IntServ has been deployed, trust relationships
>  with endpoints are very different from trust relationships on the
>  Internet itself.  There are often clearly defined hierarchies in
>  Service Level Agreements (SLAs) and in well-defined transport flows
>  operating with predetermined capacity and latency requirements over
>  paths where capacity or other attributes are constrained.
>

That's an improvement, but still not quite right. I'd suggest (starting
from your Suggested)

In environments where IntServ has been deployed, trust relationships
 with endpoints are very different from trust relationships on the
 Internet itself.  There are often clearly defined hierarchies in
 Service Level Agreements (SLAs) governing well-defined transport flows
 operating with predetermined capacity and latency requirements over
 paths where capacity or other attributes are constrained.


> 9) Section 6.3:  The other three entries in this list show
> the titles of the listed documents.  May we update the [SAF07] item
> as suggested below?
>
> Original:
>  *  Determining an appropriate initial sending rate over an
>     underutilized network path [SAF07]
>
> Suggested:
>  *  "Determining an appropriate sending rate over an
>     underutilized network path" [SAF07]


 Yes, please keep this change.


> 10) Section 6.3:  We had trouble following this sentence.
> Should "as well in routers" be "as well as in routers"?
>
> Original:
>  Quick-Start requires modifications in the
>  involved end-systems as well in routers.
>

Yes, your suggestion is correct. Please make that change.


> 11) Section 6.3:  Because we see the phrase "experiments
> with Quick-Start in [Sch11]" in Section 6.3.1, we changed "analyzes"
> to "analyze" to correct the subject-verb disagreement in this
> sentence.  Please let us know if this is incorrect.
>
> Original:
>  Later studies
>  [Sch11] comprehensively analyzes Quick-Start with a full Linux
>  implementation and with a router fast path prototype using a network
>  processor.
>
> Currently:
>  Later studies
>  [Sch11] comprehensively analyze Quick-Start with a full Linux
>  implementation and with a router fast path prototype using a network
>  processor.
>

Yes, please keep this change.


> 12) Section 6.3.2:  Should "10 MSS" be "10 times the
> Maximum Segment Size (MSS)" in this sentence?
>
> Original:
>  After publication of the Quick-Start specification, there have been
>  large-scale experiments with an initial window of up to 10 MSS
>  [RFC6928].
>

Not quite. I'd suggest

After publication of the Quick-Start specification, there have been
 large-scale experiments with an initial window of up to 10 segments
 [RFC6928].


> 13) Sections 6.4, 6.6, and 6.8:  May we change
> "references ... are" to "reference ... is" for these three items?
> We only see one reference listed after each of them.
>
> Original:
>  The suggested references for ICMP Source Quench are:
>
>  *  INTERNET CONTROL MESSAGE PROTOCOL [RFC0792]
> ...
>  The suggested references for Shim6 are:
>
>  *  Shim6: Level 3 Multihoming Shim Protocol for IPv6 [RFC5533]
> ...
>  The suggested references for IPv6 Flow Label are:
>
>  *  IPv6 Flow Label Specification [RFC6437]
>
> Suggested:
>  The suggested reference for ICMP Source Quench is:
>
>  *  "INTERNET CONTROL MESSAGE PROTOCOL" [RFC0792]
> ...
>  The suggested reference for Shim6 is:
>
>  *  "Shim6: Level 3 Multihoming Shim Protocol for IPv6" [RFC5533]
> ...
>  The suggested reference for IPv6 Flow Label is:
>
>  *  "IPv6 Flow Label Specification" [RFC6437]


Yes, please keep these changes.

14) Section 6.5:  This sentence does not parse, and we
> cannot follow its meaning.  Are some words missing after
> "single signal"?  Please clarify "the end-to-end flow control
> mechanism has only a single signal, the loss of a segment, and TCP
> implementations since the late 1980s have ..."
>
> Original:
>  TCP [RFC0793] has a well-known weakness - the end-to-end flow control
>  mechanism has only a single signal, the loss of a segment, and TCP
>  implementations since the late 1980s have interpreted the loss of a
>  segment as evidence that the path between two endpoints may have
>  become congested enough to exhaust buffers on intermediate hops, so
>  that the TCP sender should "back off" - reduce its sending rate until
>  it knows that its segments are now being delivered without loss
>  [RFC5681].
>

Breaking into more sentences ... I'd suggest

 TCP [RFC0793] has a well-known weakness - the end-to-end flow control
 mechanism has only a single signal, the loss of a segment, TCP
 implementations since the late 1980s have interpreted the loss of a
 segment as evidence that the path between two endpoints may have
 become congested enough to exhaust buffers on intermediate hops, so
 that the TCP sender should "back off" - reduce its sending rate until
 it knows that its segments are now being delivered without loss
 [RFC5681].

15) Section 6.5.1:  As we are now past 2020, should "In the
> 2010s, it is common" be "Since the 2010s, it has been common" or "In
> the 2010s, it was common"?  Also, 'a single "link" to support many
> senders and receivers on a single link' looks odd; is the extra 'on a
> single link' needed?
>
> Original:
>  In the 2010s, it is common for a single "link" to support many
>  senders and receivers on a single link, likely requiring TRIGTRAN
>  senders to wait some random amount of time before sending after
>  receiving a TRIGTRAN signal, which would have reduced the benefits of
>  TRIGTRAN even more.
>

Please make the change you suggested, and remove the extra "on a single
link".


> 16) Section 6.7:  These sentences are difficult to follow.
> In the first sentence, does "protocols" refer only to NSLP (in which
> case it appears that it should be singular), or does "protocols"
> refer to both NSLP and NTLP?  In the third sentence, are the
> repeated expansions of "NSLP" necessary, as "NSLP" is already
> expanded three times in this section?  If the suggested text is not
> correct, please clarify.
>
> Original:
>  However,
>  over time a new approach evolved that introduced a modular
>  architecture using application-specific signaling protocols (the NSIS
>  Signaling Layer Protocol (NSLP)) on top of a generic signaling
>  transport protocol (the NSIS Transport Layer Protocol (NTLP)).
>
>  The NTLP is defined in [RFC5971].  Two NSLPs are defined: the NSIS
>  Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
>  [RFC5974] as well as the NAT/Firewall NSIS Signaling Layer Protocol
>  (NSLP) [RFC5973].
>
> Suggested:
>  However,
>  over time a new approach evolved that introduced a modular
>  architecture using two application-specific signaling protocols:
>  a) the NSIS Signaling Layer Protocol (NSLP) on top of b) a generic
>  signaling transport protocol (the NSIS Transport Layer Protocol
>  (NTLP)).
>
>  NTLP is defined in [RFC5971].  Two types of NSLPs are defined:
>  NSLP for Quality-of-Service Signaling [RFC5974] and the NAT/Firewall
>  NSLP [RFC5973].
>

This is a massive improvement. I'd suggest one additional change in the
second paragraph, just so the two NSLP descriptions are more parallel.

 NTLP is defined in [RFC5971].  Two types of NSLPs are defined: an
 NSLP for Quality-of-Service Signaling [RFC5974] and an NSLP for
NAT/Firewall
 [RFC5973].



> 17) Section 6.7.1:  We had trouble following this sentence.
> Does "that are" refer to the messages, the node, or the control plane?
>
> Original:
>  The NTLP mainly operates as path-coupled signaling protocol, i.e, its
>  messages are processed at the intermediate node's control plane that
>  are also forwarding the data flows.
>

I'd suggest

The NTLP mainly operates as a path-coupled signaling protocol, i.e, its
 messages are processed at the control plan of each intermediate node that
 is also forwarding the data flows.



> 18) Section 6.8:  Does "or to" in this sentence refer to
> multiple flow labels or the network?
>
> Original:
>  A multiplexing transport could choose to use
>  multiple flow labels to allow the network to independently forward
>  its subflows, or to use one common value for the traffic aggregate.
>
> Perhaps (the labels):
>  A multiplexing transport could choose to use
>  multiple flow labels to a) allow the network to independently
>  forward its subflows or b) use one common value for the traffic aggregate.
>
> Or possibly (the network):
>  A multiplexing transport could choose to use
>  multiple flow labels to allow the network to either independently
>  forward its subflows or use one common value for the traffic aggregate.
>

Please make the "(the network)" change.


> 19) Section 6.8.1:  Because "the standard [RFC3697]" reads
> oddly and RFC 3697 was obsoleted by RFC 6437, we updated this
> sentence as noted below.  Please let us know if this is incorrect
> (i.e., it appears to us that RFC 3697 is the original flow label
> standard).
>
> Original:
>  Although the standard [RFC3697] forbids any encoding of meaning into
>  the flow label value, the opportunity to use the flow label as a
>  covert channel or to signal other meta-information may have raised
>  concerns about setting a non-zero value [RFC6437].
>
> Currently:
>  Although the original flow label standard [RFC3697] forbids any
>  encoding of meaning into the flow label value, the opportunity to
>  use the flow label as a covert channel or to signal other meta-
>  information may have raised concerns about setting a non-zero
>  value [RFC6437].
>

Yes, please make this change.


> 20) Section 6.8.1:  To what does "or to" refer in this
> sentence?
>
> Original:
>  Network
>  equipment (routers and/or middleboxes) need to include appropriate
>  support so they can utilize the field when making decisions about how
>  to classify flows, or to inform forwarding choices.
>
> Perhaps:
>  Network
>  equipment (routers and/or middleboxes) need to include appropriate
>  support so they can utilize the field when making decisions about
>  how to classify flows or inform forwarding choices.
>

That's an improvement. May I make a counterproposal?

 Network
 equipment (routers and/or middleboxes) need to include appropriate
 support in order to utilize the field when making decisions about
 how to classify flows or forward packets.



> 21) Section 6.9:  This paragraph contained four sentences
> that were repeated twice.  We verified them to be identical and then
> removed the "repeat" sentences.  Please let us know any concerns.
>
> Original:
>  In response to this situation, "Active Queue Management" (AQM) was
>  deployed in the network.  A number of AQM disciplines have been
>  deployed, but one common approach was that routers dropped packets
>  when a threshold buffer length was reached, so that transport
>  protocols like TCP that were responsive to loss would detect this
>  loss and reduce their sending rates.  Random Early Detection (RED)
>  was one such proposal in the IETF.  As the name suggests, a router
>  using RED as its AQM discipline that detected time-averaged queue
>  lengths passing a threshold would choose incoming packets
>  probabilistically to be dropped [RFC2309].  In response to this
>  situation, "Active Queue Management" (AQM) was deployed in the
>  network.  A number of AQM disciplines have been deployed, but one
>  common approach was that routers dropped packets when a threshold
>  buffer length was reached, so that transport protocols like TCP that
>  were responsive to loss would detect this loss and reduce their
>  sending rates.  Random Early Detection (RED) was one such proposal in
>  the IETF.  As the name suggests, a router using RED as its AQM
>  discipline that detected time-averaged queue lengths passing a
>  threshold would choose incoming packets probabilistically to be
>  dropped [RFC2309].
>
> Currently:
>  In response to this situation, "Active Queue Management" (AQM) was
>  deployed in the network.  A number of AQM disciplines have been
>  deployed, but one common approach was that routers dropped packets
>  when a threshold buffer length was reached, so that transport
>  protocols like TCP that were responsive to loss would detect this
>  loss and reduce their sending rates.  Random Early Detection (RED)
>  was one such proposal in the IETF.  As the name suggests, a router
>  using RED as its AQM discipline that detected time-averaged queue
>  lengths passing a threshold would choose incoming packets
>  probabilistically to be dropped [RFC2309].
>

Yes, please keep this change, and I apologize for apparently copy-pasting
instead of cut/pasting!


> 22) Section 6.9:  We had trouble parsing this sentence.  Are
> some words missing?  If the suggested text is not correct, please
> clarify.
>
> Original:
>  Researchers suggested that providing "explicit congestion
>  notifications" to senders when routers along the path detected their
>  queues were building, so that some senders would "slow down" as if a
>  loss had occurred, so that the path queues had time to drain, and the
>  path still had sufficient buffer capacity to accommodate bursty
>  arrivals of packets from other senders.
>
> Suggested (changed "suggested that" to "suggested" and "detected
>    their" to "detected that their"):
>  Researchers suggested providing "explicit congestion notifications"
>  to senders when routers along the path detected that their queues
>  were building, so that some senders would "slow down" as if a loss
>  had occurred, the path queues had time to drain, and the path still
>  had sufficient buffer capacity to accommodate bursty arrivals of
>  packets from other senders.
>

That's significantly better. Now that I understand what the original text
meant(!), may I suggest

 Researchers suggested providing "explicit congestion notifications"
 to senders when routers along the path detected that their queues
 were building, giving senders an opportunity to "slow down" as if a loss
 had occurred, giving path queues time to drain, while the path still
 had sufficient buffer capacity to accommodate bursty arrivals of
 packets from other senders.


 23) Section 6.9.1:  Is the "at least" necessary in this

> sentence?  It looks odd in the context of "All three" in the next
> sentence.
>
> Original:
>  There are at least three sub-stories - ECN deployment in clients, ECN
>  deployment in routers, and AQM deployment in operational networks.
>  All three sub-stories mattered.
>

This text was discussed in a fairly intense (for PANRG) email thread. I was
trying to avoid saying that I knew what all of the substories were (and
trying to get agreement on that). Let me try again.


ECN deployment relied on three factors - support in client implementations,
support in router implementations, and in deployment decisions in
operational networks.



> 24) Section 6.9.1:  We expanded "TOS" as "Type of Service"
> per RFC 791.  Please let us know any objections.
>
> Original:
>  What they did not anticipate, was routers that would crash, when they
>  saw bits 6 and 7 in the IPv4 TOS octet [RFC0791]/IPv6 Traffic Class
>  field [RFC2460], which [RFC2481] redefined to be "currently unused",
>  being set to a non-zero value.
>
> Currently:
>  What they did not anticipate was routers that would crash, when they
>  saw bits 6 and 7 in the IPv4 Type of Service (TOS) octet
>  [RFC0791] / IPv6 Traffic Class field [RFC2460], which [RFC2481]
>  redefined to be "currently unused", being set to a non-zero value.
>

Yes, please keep this change.


> 25) Section 6.9.1:  We made this cited text match what
> appears in slide 6 of [vista-impl] and expanded "IGD" in text, as
> follows.  Please let us know any objections.
>

Yes, please keep this change.


>
> Also, FYI that
>
> 1) The slides show "IETF 68 - TSVAREA", and slide 4 has the text
> "has been disabled by default since 2006".  Was a different set of
> slides intended here, or may we change "November 2003" to
> "March 2007" in the reference listing?
>

Yes, please keep this change.


> 2) If a reader clicks the "PPT Version" link on the provided page
> and downloads the file, the file will be saved with a ".ppt"
> extension, which may not be compatible with some newer computers.
> In our case, this file by default opened as an unreadable textfile.
> By doing "Open With" and selecting our computer's PowerPoint
> application, we could then view the file properly.  Assuming that
> these March 2007 slides are the intended slides, we point this out
> in case you would like to either provide a different URL for the same
> set of slides or maybe provide a warning re. how to open the file.
>

Spencer question: As best I can tell, this ppt was never converted to PDF
(I changed the suffix on the link to .pdf and got a 404).

The March 2007 slides are the intended slides, and they're hosted on the
IETF website. I want to do the right thing, but I'm not sure what that is.

I don't remember the name of the tool Dave Thaler used to produce the HTML
slides, but I do remember that he wasn't the only person using that tool to
submit slides to IETF proceedings, and I remember seeing that format pretty
often for several years.

I'm not sure I can give advice about how to open the file that will last as
long as this RFC lasts (Heck, I'm not sure what to suggest on an iPad
today!)

I don't know this, but I SUSPECT that there will be a day when the .ppt
version might not open in Powerpoint at all (that actually was a problem
for 3GPP with their older Word version specifications - people upgraded
their Windows laptops and lost their ability to look at past history for
their specifications. That's not a good look for an archival series RFC.

Maybe (and this is true) pointing out that the PPT link might not work for
everyone, but that the PPT version doesn't include any information that's
not already on the HTML version provided as a reference?

Maybe I could ask the Secretariat if they can host a PDF version of the
slides in the IETF 68 proceedings?

But we do have a bunch of options, and I suspect this isn't the first time
the question has come up, and may not be the last time.

Could you chat about this with the RPC folks and figure out what you really
want to do?


> Original:
>  As described in [vista-impl],
>
>     Intermediate Gateway Device problem #1: one of the most popular
>     versions from one of the most popular vendors.  When a data packet
>     arrives with either ECT(0) or ECT(1) (indicating successful ECN
>     capability negotiation) indicated, router crashed.  Cannot be
>     recovered at TCP layer (sic)
> ...
>  [vista-impl]
>             Sridharan, M., Bansal, D., and D. Thaler, "Implementation
>             Report on Experiences with Various TCP RFCs", November
>             2003, <https://www.ietf.org/proceedings/68/slides/tsvarea-
>             3/sld1.htm>.
>
> Currently:
>  As described in [vista-impl] ("IGD" stands for "Intermediate Gateway
>  Device"),
>
>  |  IGD problem #1: one of the most popular versions from one of the
>  |  most popular vendors.  When a data packet arrives with either
>  |  ECT(0) or ECT(1) (indicating successful ECN capability
>  |  negotiation) indicated, router crashed.  Cannot be recovered at
>  |  TCP layer [sic]
> ...
>  [vista-impl]
>             Sridharan, M., Bansal, D., and D. Thaler, "Implementation
>             Report on Experiences with Various TCP RFCs", November
>             2003, <https://www.ietf.org/proceedings/68/slides/tsvarea-
>             3/sld1.htm>.
>
>
> 26) Section 6.9.2:  As it appears that "but are" refers to
> "This" (and not to the implementations), we updated this sentence
> accordingly.  Please let us know if this is incorrect.
>
> Original:
>  This might be based on the difficulty of
>  distributing implementations that enable it by default, but are
>  just as likely to be based on the "bad taste in the mouth" that
>  implementers have after an unsuccessful deployment attempt that
>  degraded user experience.
>
> Currently:
>  This might be based on the difficulty of
>  distributing implementations that enable it by default, but it is
>  just as likely to be based on the "bad taste in the mouth" that
>  implementers have after an unsuccessful deployment attempt that
>  degraded user experience.
>

Yes, please keep this change.


> 27) References:  We see that the following RFCs have been
> obsoleted.  Although we suspect that they need to be kept because
> they deal with historical information, we wanted to let you know
> about them, in case you'd like to make any updates.  Please review
> the in-text citations for each of the following, and let us know if
> any updates are needed:
>
> RFC 2309 (obsoleted by RFC 7567)
> RFC 2460 (obsoleted by RFC 8200)
> RFC 5575 (obsoleted by RFC 8955)
>
> Original:
>  [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
>             S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
>             Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
>             S., Wroclawski, J., and L. Zhang, "Recommendations on
>             Queue Management and Congestion Avoidance in the
>             Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
>             <https://www.rfc-editor.org/info/rfc2309>.
>  [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>             (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
>             December 1998, <https://www.rfc-editor.org/info/rfc2460>.
> ...
>  [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
>             and D. McPherson, "Dissemination of Flow Specification
>             Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
>             <https://www.rfc-editor.org/info/rfc5575>.
>

These references are correct (I'm talking about when something first
happened, so those were the relevant specifications).


> 28) [Colossal-Cave]:  As this page was last updated in
> April 2021, we updated this listing accordingly.  Please let us know
> any objections.
>
> Original:
>  [Colossal-Cave]
>             "Wikipedia Page for Colossal Cave Adventure", January
>             2019,
>             <https://en.wikipedia.org/wiki/Colossal_Cave_Adventure>.
>
> Currently:
>  [Colossal-Cave]
>             Wikipedia, "Colossal Cave Adventure", April 2021,
>             <https://en.wikipedia.org/wiki/Colossal_Cave_Adventure>.
>

Yes, please keep this change.


> 29) References:  The provided URL for [NANOG-35] yields a 404,
> as this meeting's page has been archived.  We updated this listing
> accordingly.  Please let us know if this is incorrect.
>
> Original:
>  [NANOG-35] "North American Network Operators Group NANOG-35 Agenda",
>             October 2005,
>             <https://www.nanog.org/meetings/nanog35/agenda>.
>
> Currently:
>  [NANOG-35] "NANOG 35 Agenda", North American Network Operators' Group
>             (NANOG), October 2005,
>             <https://archive.nanog.org/meetings/nanog35/agenda>.
>

Thank you for chasing this down. Cool URLs don't change, right?


> 30) The provided URL for [PANRG-99] yields a "couldn't be
> found" message.  Please provide a stable, working URL.
>
> Original:
>  [PANRG-99] "Path Aware Networking Research Group - IETF-99", July
>             2017,
>             <https://datatracker.ietf.org/meeting/99/sessions/panrg>.
>

My apologies - this link ^^^ does return 404 as you said, but going to
https://datatracker.ietf.org/rg/panrg/meetings/ and selecting the IETF 99
materials returns https://datatracker.ietf.org/meeting/99/session/panrg,
which works fine for me - it's "session", not "sessions".


> 31) The provided URL for [PANRG-110] yields a "couldn't be
> found" message.  Also, it appears that there is a mismatch between
> the meeting number and the date, as IETF 99 was held in July 2017 and
> IETF 110 was held in March 2021.  Please advise re. the number/date
> mismatch, and please provide a stable, working URL.
>
> Original:
>  [PANRG-110]
>             "Path Aware Networking Research Group - IETF-110", July
>             2017,
>             <https://datatracker.ietf.org/meeting/110/sessions/panrg>.
>

And, I almost certainly cut and pasted the IETF 99 reference here, because
it has the same sessions/session error. The correct link is
https://datatracker.ietf.org/meeting/110/session/panrg.


> 32) [TRIGTRAN-55] and [TRIGTRAN-56]:
> <https://www.ietf.org/how/meetings/past/> shows IETF 55 as
> November 2002 and IETF 56 as March 2003.  We also see 'This BoF is a
> "second BoF". The first TRIGTRAN BoF was held at IETF 55 ...' on the
> [TRIGTRAN-56] page.  May we update these listings to use the
> correct meeting dates for IETF 55 and IETF 56 (i.e., November 2002
> and March 2003)?  (We ask because we also want to make sure that
> "IETF 55" and "IETF 56" are in fact the intended meeting numbers.)
>

Yes, please update these dates. My apologies (especially because TRIGTRAN
was MY contribution to the document!)


> Original:
>  [TRIGTRAN-55]
>             "Triggers for Transport BOF at IETF 55", July 2003,
>             <https://www.ietf.org/proceedings/55/239.htm>.
>
>  [TRIGTRAN-56]
>             "Triggers for Transport BOF at IETF 56", November 2003,
>             <https://www.ietf.org/proceedings/56/251.htm>.
>
>
> 33) Please let us know if any changes are needed for the
> following:
>
> a) The following terms were used inconsistently in this document.
> We chose to use the latter forms.  Please let us know any objections.
>
>  lessons learned (1 instance) / Lessons Learned
>

Perfect.


>  per flow / per-flow
>

Also perfect.


> b) The following terms appear to be used inconsistently in this
> document.  Please let us know which form is preferred.
>
>  experimental / Experimental (in running text)
>

Spencer question: The only occurrence of "Experimental" that I see is in
this text:

    Quick-Start [RFC4782] is an Experimental TCP extension that leverages
   support from the routers on the path to determine an allowed initial
   sending rate for a path through the Internet, either at the start of
   data transfers or after idle periods.

The intention here is to say that Quick-Start is an Experimental RFC (so,
not Standards-track). "Experimental" is a Category, I believe, and I'm not
sure

   Quick-Start [RFC4782] is an Experimental-Category TCP extension that
leverages
   support from the routers on the path to determine an allowed initial
   sending rate for a path through the Internet, either at the start of
   data transfers or after idle periods.

is helpful (if you disagree, it's an accurate statement, so that text would
be fine with me).

If that suggestion isn't helpful, perhaps

   Quick-Start [RFC4782] is defined in an Experimental RFC, and is a TCP
extension that leverages
   support from the routers on the path to determine an allowed initial
   sending rate for a path through the Internet, either at the start of
   data transfers or after idle periods.

Do either of those work for the RFC Editor?

 fast-path / fast path (noun)  (We also see "fast path prototype" and
>    "fast path implementation"; in these instances, "fast path" is
>    used as a modifier.  We suggest hyphenating the modifiers and
>    removing the hyphen in the noun forms.)
>

That all sounds fine to me.


>  flow specification / Flow Specification
>

The latter form is fine with me.


>  global IPv6 routing table / IPv6 global routing table
>    (We see "global IPv4 routing table" as well.)
>

The latter form is fine with me.


>  invariant / Invariant (Do the lowercased instances refer to the
>    category type (in which case they should be initial-capitalized),
>    or is the word "invariant" used generally?)
>
>  path / Path (e.g., 'definition of a path', 'current
>    definition of "Path"')
>

The latter form is fine with me.


>  path aware / Path Aware / path-aware (where used generally, e.g.,
>    "many Path Aware techniques*", "some path aware techniques*",
>    "earliest Path-Aware Networking technique", "path-aware protocol",
>    "your path aware technology", "your Path Aware technology")
>
>    * (We also see the variations "Path-Aware techniques" and
>       "Path-Aware Techniques" (title of Section 2.2), "Path-Aware
>       techniques" and "Path Aware Technique"; we suggest choosing one
>       form for consistency of style.)
>

Spencer question: I'm not sure what your suggestion is here - is this
saying that there are this many variations in the document and you don't
have a suggestion?


>  path-aware networking / path aware networking /
>    Path Aware Networking / Path Aware networking /
>    Path-Aware Networking (in text, where used generally)
>

Spencer question: I'm not sure what your suggestion is here - is this
saying that there are this many variations in the document and you don't
have a suggestion?


>  path awareness / Path Awareness (e.g., 'the definition of path
>    awareness', 'The current definition of "Path Awareness"',
>    'think about path awareness', 'benefit of Path Awareness')
>

  The latter form is fine with me.


>  the research group / the Research Group


Perfect.


>
>
>
> Title                  : Path Aware Networking: Obstacles to Deployment (A
> Bestiary of Roads Not Taken)
> Author(s)              : S. Dawkins,  Ed.
> Working Group Chair(s) : Brian Trammell, Jen Linkova
> Area Director(s)       : Not Applicable
>
>