Re: [auth48] AUTH48: RFC-to-be 9522 <draft-ietf-teas-rfc3272bis-27> for your review

[Sarah Tarrant <[e-mail]>]

Hi Adrian,

Thank you for your reply. We have updated the document accordingly.

We have a few followup questions/comments:

a) Regarding:
>> 34) <!-- [rfced] The following text appears in the Acknowledgements
>> section. Should it appear in the Contributors section instead? The text
>> says, "the original authors should be considered as Contributors to this
>> work".
>> 
>> Original:
>>   Much of the text in this document is derived from RFC 3272.  The
>>   editor and contributors to this document would like to express their
>>   gratitude to all involved in that work.  Although the source text has
>>   been edited in the production of this document, the original authors
>>   should be considered as Contributors to this work.  They were:
>> 
>>      Daniel O. Awduche
>>      Movaz Networks
>> 
>>      Angela Chiu
>>      Celion Networks
>> 
>>      Anwar Elwalid
>>      Lucent Technologies
>> 
>>      Indra Widjaja
>>      Bell Labs, Lucent Technologies
>> 
>>      XiPeng Xiao
>>      Redback Networks
>> -->
>> 
> This was done to avoid the IPR issues associated with listing people as contributors.
> Technically, even now, if you move the text we have to either:
> - get all of these people to give IPR disclosure assurances
> or
> - get AD sign-off
> 
> I have objection to crediting these people. I don't want to wait while we track down people who left the industry 20 years ago!

We did not make any changes.


b) Regarding:
>> l) Please review the following terms and verify if the quotation marks are
>> necessary.
>> 
> Double quotes are fine in all cases when used…
> "acceptable service quality" - please quote
Do you want every instance of “acceptable service quality” to be placed in quotations? We found two instances, one with and one without.

> "shortest paths" - please quote
Since “shortest” is also in quotes, did you want every instance of “shortest”, “shortest paths”, and/or “shortest path” to be placed in quotations? Or just a few instances? If so, please let us know which ones.


The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9522.txt
https://www.rfc-editor.org/authors/rfc9522.pdf
https://www.rfc-editor.org/authors/rfc9522.html
https://www.rfc-editor.org/authors/rfc9522.xml

The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9522-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9522-auth48diff.html (AUTH48 changes only)
Note that it may be necessary for you to refresh your browser to view the most recent version. 

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9522

Thank you,
RFC Editor/st



> On Jan 11, 2024, at 9:59 AM, Adrian Farrel <[e-mail]> wrote:
> 
> Hi there,
> 
> Thanks so much for the work. Massive effort!
> 
> Answers in line.
> 
> Best,
> Adrian
> 
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search.
> -->
> 
> Yeah, hmmm...
> Perhaps:
> - Policy
> - Path steering
> - Resource management
> - Network engineering
> - Network performance optimization
> 
> 2) <!-- [rfced] FYI - While we understand RFC 3272 was published with some of the
> text we are questioning below, the questions and edits are aimed at
> making the text as correct and useful to the reader as possible.  Please
> review carefully.
> -->
> 
> Yes, that is reasonable.
> 
> 3) <!-- [rfced] In Section 1.2, would it be helpful to include text to introduce
> the second bulleted list? Or is the current okay?
> -->
> 
> I think it is OK. You could de-bullet those two paragraphs if you want.
> 
> 4) <!-- [rfced] Would it be helpful to clarify "via [RFC3209]" and "via
> [RFC4203]" here by mentioning the mechanisms in those documents?
> 
> Original:
>      Such accounting can
>      be done based on any combination of a static understanding of
>      resource requirements, and the use of dynamic mechanisms to
>      collect requirements (e.g., via [RFC3209]) and resource
>      availability (e.g., via [RFC4203]).
> 
> Perhaps:
>      Such accounting can
>      be done based on any combination of a static understanding of
>      resource requirements and the use of dynamic mechanisms to
>      collect requirements (e.g., via RSVP-TE [RFC3209]) and resource
>      availability (e.g., via OSPF extensions for GMPLS [RFC4203]).
> -->
> 
> Sure
> 
> 5) <!-- [rfced] May we update "The offered load or offered traffic load" and "The
> workload or traffic workload" in these definitions as follows?
> 
> Original:
>   Offered load:  The offered load or offered traffic load is a measure
>      of the amount of traffic being presented to be carried across a
>      network compared to the capacity of the network to carry it.
>   ...      
>   Workload:  The workload or traffic workload is an evaluation of the
>      amount of work that must be done in a network in order to
>      facilitate the traffic demand. 
> 
> Perhaps: 
>   Offered load:  Also called "offered traffic load". A measure
>      of the amount of traffic being presented to be carried across a
>      network compared to the capacity of the network to carry it.
>   ...      
>   Workload:  Also called "traffic workload". An evaluation of the
>      amount of work that must be done in a network in order to
>      facilitate the traffic demand. 
> -->
> 
> Well, this is fine, but I hate (passionately) the fact that this leaves us with non-sentences. I'm also not convinced by the use of quotation marks. More words, but better English would be...
>   Offered load:  Offered load is also sometimes called offered 
>      traffic load. It is a measure of the amount of traffic being 
>      presented to be carried across a network compared to the
>      capacity of the network to carry it.
>   ...      
>   Workload:  Workload is also sometimes called traffic workload.
>      It is an evaluation of the amount of work that must be done
>      in a network in order to facilitate the traffic demand.
> 
> 6) <!-- [rfced] Please review the text starting with "from the entry..." and let
> us know how it can be updated for clarity.
> 
> Original:
>      In contrast, edge-to-edge is often used to describe the traffic
>      flow from the entry to a domain or network, to the exit from that
>      domain or network. 
> 
> Perhaps:
>      In contrast, edge-to-edge is often used to describe the traffic
>      flow from the entry of a domain or network to the exit of that
>      domain or network.
> -->
> 
> Well, it's possibly a personal preference, but I believe doors provide an entry to a room or an exit from the room. I think "entry of a room" is just wrong. Perhaps Americans (being basically German in their grammar) have a different view.
> 
> 7) <!-- [rfced] May we update "a network described" to "a network like the one
> described" to improve clarity?
> 
> Original:
>   There are several problems associated with operating a network
>   described in the previous section. 
> 
> Perhaps: 
>   There are several problems associated with operating a network
>   like the one described in the previous section. 
> -->
> 
> This would need to be:
>   There are several problems associated with operating a network
>   like those described in the previous section.
> 
> 8) <!-- [rfced] Would either 1) updating "How to" to "How do we" or 2) removing
> the question marks improve readability of this text? Or do you prefer the current?
> 
> Original:
>   A particular challenge is to formulate the problems that traffic
>   engineering attempts to solve.  For example:
> 
>   *  How to identify the requirements on the solution space?
> 
>   *  How to specify the desirable features of solutions?
> 
>   *  How to actually solve the problems?
> 
>   *  How to measure and characterize the effectiveness of solutions?
> 
> Perhaps (update "How to" to "How do we"): 
>   A particular challenge is to formulate the problems that traffic
>   engineering attempts to solve.  For example:
> 
>   *  How do we identify the requirements on the solution space?
> 
>   *  How do we specify the desirable features of solutions?
> 
>   *  How do we actually solve the problems?
> 
>   *  How do we measure and characterize the effectiveness of solutions?
> 
> Or (remove question marks):
>   A particular challenge is to formulate the problems that traffic
>   engineering attempts to solve.  For example:
> 
>   *  How to identify the requirements on the solution space
> 
>   *  How to specify the desirable features of solutions
> 
>   *  How to actually solve the problems
> 
>   *  How to measure and characterize the effectiveness of solutions
> -->
> 
> Hrmph.
> I reject "How do we" unless the intention is that the RSE and I are on call to help address these issues.
> The correct usage would be "How does one", but that would be pretty stilted.
> 
> As to retaining or removing question marks: I think that is house style. I would retain them (after all, they look like questions), but I'd not object if you want to remove them.
> 
> 9) <!-- [rfced] Please review the comma after "automatically" here. Should the
> comma be removed or replaced with "and"?
> 
> Original:
>   *  automatically, online using constraint-based routing processes
>      implemented on label switching routers
> 
>   *  automatically, offline using constraint-based routing entities
>      implemented on external TE support systems.
> 
> Perhaps (removed comma): 
>   *  automatically online using constraint-based routing processes
>      implemented on Label Switching Routers (LSRs)
> 
>   *  automatically offline using constraint-based routing entities
>      implemented on external TE support systems.
> 
> Or (replaced comma with "and"):
>   *  automatically and online using constraint-based routing processes
>      implemented on Label Switching Routers (LSRs)
> 
>   *  automatically and offline using constraint-based routing entities
>      implemented on external TE support systems.
> -->
> 
> Using "and" would be fine.
> 
> 10) <!-- [rfced] We note that [AFD03] uses the expansion "Approximate Fair
> Dropping (AFD)", though the title of the reference is "Approximate
> fairness through differential dropping". Please review and let us know if
> any updates are needed for this expansion in this text.
> 
> Link to [AFD03]: https://dl.acm.org/doi/10.1145/956981.956985
> 
> Current:
>   ... while others (such
>   as Approximate Fairness Through Differential Dropping (AFD)
>   [AFD03] have seen some implementation.
> -->
> 
> Yeah, that should read "Approximate Fair Dropping (AFD)"
> 
> 11) <!-- [rfced] We added a semicolon and "in addition" to this sentence. We also
> updated "area/Autonomous System (AS) size" to "the size of the area and
> AS". Please review and let us know any objections.
> 
> Original
>   ALB flooding can be resource intensive, since it requires link bandwidth
>   to carry routing protocol link state advertisements, processor
>   capacity to process those advertisements, and the overhead of the
>   advertisements and their processing can limit area/Autonomous System
>   (AS) size. 
> 
> Current:
>   ALB flooding can be resource intensive, since it requires link bandwidth
>   to carry routing protocol link state advertisements and processor
>   capacity to process those advertisements; in addition, the overhead of the
>   advertisements and their processing can limit the size of the area and AS. 
> -->
> 
> OK. Sigh.
> See https://www.rfc-editor.org/materials/abbrev.expansion.txt for AS not being "well known".
> Suggest in Section 1
> OLD
>   Even though Internet TE is most effective when applied end-to-end,
>   the focus of this document is TE within a given domain (such as an
>   autonomous system).  However, because a preponderance of Internet
>   traffic tends to originate in one autonomous system and terminate in
>   another, this document also provides an overview of aspects
>   pertaining to inter-domain TE.
> NEW
>   Even though Internet TE is most effective when applied end-to-end,
>   the focus of this document is TE within a given domain (such as an
>   autonomous system (AS)).  However, because a preponderance of Internet
>   traffic tends to originate in one AS and terminate in
>   another, this document also provides an overview of aspects
>   pertaining to inter-domain TE.
> END
> 
> And in 1.3
> OLD
>   The scope of this document is intra-domain TE because this is the
>   practical level of TE technology that exists in the Internet at the
>   time of writing.  That is, it describes TE within a given autonomous
>   system in the Internet.  This document discusses concepts pertaining
>   to intra-domain traffic control, including such issues as routing
>   control, micro and macro resource allocation, and the control
>   coordination problems that arise consequently.
> NEW
>   The scope of this document is intra-domain TE because this is the
>   practical level of TE technology that exists in the Internet at the
>   time of writing.  That is, it describes TE within a given AS
>   in the Internet.  This document discusses concepts pertaining
>   to intra-domain traffic control, including such issues as routing
>   control, micro and macro resource allocation, and the control
>   coordination problems that arise consequently.
> END
> 
> Then you could use...
>   ALB flooding can be resource intensive, since it requires link bandwidth
>   to carry routing protocol link state advertisements and processor
>   capacity to process those advertisements; in addition, the overhead of the
>   ALB advertisements and their processing can limit the size of the area and
>   AS.
> 
> 12) <!-- [rfced] These sentences are quite similar and point back to each other
> (i.e., the sentence in Section 4.1 points to Section 4.3.1 and vice
> versa). Please review and let us know if any updates are needed here.
> 
> Current Section 4.1: 
>   A fully functional TE system is likely to use all aspects of time-
>   dependent, state-dependent, and event-dependent methodologies as
>   described in Section 4.3.1.
> 
> Current Section 4.3.1:
>   Lastly, note that a fully functional TE system is likely to use all
>   aspects of time-dependent, state-dependent, and event-dependent
>   methodologies as described in Section 4.1.
> -->
> 
> Ah, nice catch!
> Please delete the paragraph from 4.3.1
> 
> 13) <!-- [rfced] How may we clarify "such as [RFC8040]" here?
> 
> Original:
>   However, SDN may also combine centralized control of
>   resources, and facilitate application-to-network interaction via an
>   application programming interface (API) such as [RFC8040]. 
> 
> Perhaps:
>   However, SDN may also combine centralized control of
>   resources and facilitate application-to-network interaction via an
>   Application Programming Interface (API), such as the one described in [RFC8040]. 
> -->
> 
> Good
> 
> 14) <!-- [rfced] How may we update the text starting with "underlying network
> topology..." for clarity? Specifically, what items are being connected in
> a series?
> 
> Original:
>   Therefore, the SDN
>   control plane needs to be aware of the underlying network topology,
>   capabilities and current node and link resource state.
> 
> Perhaps:
>   Therefore, the SDN
>   control plane needs to be aware of the underlying network topology,
>   capabilities, and current node and link resource state.
> -->
> 
> Yes, thanks. Long live Mr Oxford and his comma.
> 
> 15) <!-- [rfced] Please review the text starting with "performed using...". How
> can we revise to make the items connected by "either...or" have parallel
> structure?
> 
> Original:
>   When a suitable path has been
>   computed the programming of the explicit network path may be
>   performed using either a signaling protocol that traverses the length
>   of the path [RFC3209] or per-hop with each node being directly
>   programmed [RFC8283] by the SDN controller.
> 
> Perhaps: 
>   When a suitable path has been
>   computed, the programming of the explicit network path may be
>   either performed using a signaling protocol that traverses the length
>   of the path [RFC3209] or performed per-hop with each node being directly
>   programmed [RFC8283] by the SDN controller.
> -->
> 
> That works. Thanks.
> 
> 16) <!-- [rfced] Please review the ratio notation in the parenthetical. Is the
> current correct, or would "75% to 25%", "75%:25%", or something else be
> better?
> 
> Original:
>   Load-Balancing:  The traffic is distributed among the available
>      access networks following a distribution ratio (e.g., 75% - 25%).
> -->
> 
> You have the meaning right. I guess you are worried it looks like a minus sign?
> I can't decide which looks right (least wrong)
> 75% to 25%
> 75%:25%
> 75:25%
> 75% : 25%
> 
> Please pick one (definitely house style)
> 
> 17) <!-- [rfced] We do not see "MP-DCCP" in RFC 4340. We have updated this
> sentence to use "DCCP". Please let us know any objections.
> 
> Current:
>   Extensions to the Datagram Congestion Control Protocol (MP-DCCP)
>   [RFC4340] to support multipath operations are defined in
>   [MULTIPATH-DCCP].
> 
> Updated:
>   Extensions to the Datagram Congestion Control Protocol (DCCP)
>   [RFC4340] to support multipath operations are defined in
>   [MULTIPATH-DCCP].
> -->
> 
> Yup, typo.
> 
> 18) <!-- [rfced] Will the use of both "in general" and "in particular" in this
> text be difficult for the reader to follow? Please review and let us know
> if this sentence should be updated for clarity.
> 
> Original:
>   However, distributed applications in general and, in
>   particular, bandwidth-greedy P2P applications that are used, for
>   example, for file sharing, cannot directly use those techniques. 
> 
> Perhaps:
>   However, in general, distributed applications
>   (particularly, bandwidth-greedy P2P applications that are used for
>   file sharing, for example) cannot directly use those techniques. 
> -->
> 
> No objection
> 
> 19) <!-- [rfced] Please review "service" (lowercased) and "Service" (capitalized)
> in the parenthetical in this sentence. Should the capitalization be
> consistent?
> 
> Original:
>   The ALTO Protocol uses a REST-ful
>   design and encodes its requests and responses using JSON [RFC8259]
>   with a modular design by dividing ALTO information publication into
>   multiple ALTO services (e.g., the Map service, the Map-Filtering
>   Service, the Endpoint Property Service, and the Endpoint Cost
>   Service).
> -->
> 
> Direct quote from RFC 7285 section 1.2 :-(
> However, I think it would be correct to...
>   The ALTO Protocol uses a REST-ful
>   design and encodes its requests and responses using JSON [RFC8259]
>   with a modular design by dividing ALTO information publication into
>   multiple ALTO services (e.g., the Map Service, the Map-Filtering
>   Service, the Endpoint Property Service, and the Endpoint Cost
>   Service).
> 
> 20) <!-- [rfced] Would it be helpful for readers to include a citation for
> "original RSVP specification" here?
> 
> Original:
>   One of the issues with the original RSVP specification was
>   scalability.  
> -->
> 
> You can put in a 2205 ref if you like (although we have had it three times in this section already).
> 
> 21) <!-- [rfced] Please confirm that the pointer to Section 5.1.3.4 is correct. We
> ask because Section 5.1.3.4 is titled "RSVP-TE". Should this be updated
> to Section 5.1.3.3?
> 
> Current:
>   GMPLS covers both the signaling and the routing
>   part of that control plane and is based on the TE extensions to MPLS
>   (see Section 5.1.3.4).
> -->
> 
> 5.1.3.4 is correct. 5.1.3.3 is general MPLS only. The TE stuff comes in 5.1.3.4
> 
> 22) <!-- [rfced] Would you like to update "TE Router ID" to "Traffic Engineering
> router ID" to match the usage in RFC 5305 and in the "IS-IS Top-Level TLV
> Codepoints" registry at
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints?
> 
> Original:
>   *  IS-IS uses the Extended IS Reachability TLV (type 22), the
>      Extended IP Reachability TLV (type 135), and the TE Router ID TLV
>      (type 134).  
> -->
> 
> Yes, we should match the registry.
> 
> 23) <!-- [rfced] Please review the instances of "PCE" in this paregraph. Should
> any of these be updated to either "a PCE" or "PCEs"?
> 
> Original:
>   PCEs form key components of a number of TE systems.  More information
>   about the applicability of PCE can be found in [RFC8051], while
>   [RFC6805] describes the application of PCE to determining paths
>   across multiple domains.  PCE also has potential use in Abstraction
>   and Control of TE Networks (ACTN) (see Section 5.1.2.2), Centralized
>   Network Control [RFC8283], and Software Defined Networking (SDN) (see
>   Section 4.3.2).
> -->
> 
> I think all four uses can be plurals. (Need to fix agreements)
> 
> 24) <!-- [rfced] FYI - We have updated this sentence as follows (i.e., hyphenation
> with "XML- and JSON-encoded"). Please let us know any objections.
> 
> Original:
>   These protocols use XML or JSON encoded messages.  
> 
> Perhaps: 
>   These protocols use XML- or JSON-encoded messages.  
> -->
> 
> OK
> 
> 25) <!-- [rfced] May we update this sentence in one of the following ways?
> 
> Original:
>   The messages of PCEP are TLV-based, not
>   defined by a data modeling language such as YANG.
> 
> Perhaps:
>   The messages of PCEP are TLV based; they are not
>   defined by a data-modeling language such as YANG.
> 
> Or:
>   PCEP messages are TLV based; they are not
>   defined by a data-modeling language such as YANG.
> -->
> 
> Second option, please.
> 
> 26) <!-- [rfced] Will it be clear to readers where the "such as..." phrase ends?
> 
> Original:
>      Derived statistics such as traffic matrices, link utilization,
>      latency, packet loss, and other performance measures of interest
>      which are determined from network measurements can be used as
>      indicators of prevailing network conditions.  
> 
> Perhaps (after "measurements): 
>      Derived statistics (such as traffic matrices, link utilization,
>      latency, packet loss, and other performance measures of interest
>      that are determined from network measurements) can be used as
>      indicators of prevailing network conditions.
> 
> Or (after "interest"):
>      Derived statistics (such as traffic matrices, link utilization,
>      latency, packet loss, and other performance measures of interest)
>      that are determined from network measurements can be used as
>      indicators of prevailing network conditions.  
> -->
> 
> Second option, please.
> I believe this is a correct "which" because we could have written...
>      Derived statistics (such as traffic matrices, link utilization,
>      latency, packet loss, and other performance measures of interest)
>      can be used as indicators of prevailing network conditions.  
> ...without loss of meaning (only loss of information).
> But I'll not fight you on it.
> 
> 27) <!-- [rfced] May we update the text after "destination node" as
> follows to improve clarity?
> 
> Original:
>   An important aspect of the traffic mapping function is the ability to
>   establish multiple paths between an originating node and a
>   destination node, and the capability to distribute the traffic
>   between the two nodes across the paths according to configured
>   policies. 
> 
> Perhaps:
>  An important aspect of the traffic mapping function is the ability to
>  establish multiple paths between an originating node and a
>  destination node and to distribute the traffic
>  across those paths according to configured
>  policies.
> -->
> 
> You know what, that looks like two important aspects. Can't show-horn them into a singular. So...
>  Two important aspects of the traffic mapping function are the
>  ability to establish multiple paths between an originating node
>  and a destination node, and the capability to distribute the traffic
>  across those paths according to configured policies.
> 
> 28) <!-- [rfced] Please review "buffer management and packet scheduling
> mechanisms" and clarify if A) "buffer management" refers to "mechanisms"
> or B) "buffer management" is its own entity and separate from
> "mechanisms".
> 
> Original:
>   PHBs are
>   delivered using buffer management and packet scheduling mechanisms
>   and require that the ingress nodes use traffic classification,
>   marking, policing, and shaping.
> 
> Perhaps A:
>   PHBs are
>   delivered using buffer-management and packet-scheduling mechanisms
>   and require that the ingress nodes use traffic classification,
>   marking, policing, and shaping.
> 
> Perhaps B:
>   PHBs are
>   delivered using buffer management and packet-scheduling mechanisms
>   and require that the ingress nodes use traffic classification,
>   marking, policing, and shaping.
> -->
> 
> That's two mechanisms. So option A.
> 
> 29) <!-- [rfced] May we update "routing protocols interactions" as follows for
> clarity?
> 
> Original:
>   ...but this approach is difficult to use and imprecise because
>   of the way the routing protocols interactions occur across the
>   network.
> 
> Perhaps: 
>   ...but this approach is difficult to use and imprecise because
>   of the way interactions among routing protocols occur across the
>   network.
> -->
> 
> How about:
>   ...but this approach is difficult to use and imprecise because
>   of the way the routing protocols interact across the network.
> 
> 30) <!-- [rfced] Please review "the one congested connections" here. Should this
> be updated to "the one congested connection" (singular "connection") or
> something else? This sentence appears in RFC 3272, but it doesn't seem
> quite right.
> 
> Original:
>   When there are multiple exit points toward a given peer, and only one
>   of them is congested, it is not necessary to shift traffic away from
>   the peer entirely, but only from the one congested connections. 
> 
> Perhaps: 
>   When there are multiple exit points toward a given peer, and only one
>   of them is congested, it is not necessary to shift traffic away from
>   the peer entirely, but only from the one congested connection.
> -->
> 
> Correct
> 
> 31) <!-- [rfced] The URL for this reference returns a "Page Not Found" error. We
> updated as shown below. Please let us know any objections.
> 
> Original:
>   [FT01]     Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
>              a Changing World", n.d.,
>              <http://www.research.att.com/~mthorup/PAPERS/papers.html>.
> 
> Current:
>   [FT01]     Fortz, B. and M. Thorup, "Optimizing OSPF/IS-IS Weights in
>              a Changing World", IEEE Journal on Selected Areas in
>              Communications, DOI 10.1109/JSAC.2002.1003042, May 2002,
>              <https://ieeexplore.ieee.org/document/1003042>.
> -->
> 
> Good find, thanks. That URL went ood between working group last call and now. Yours would have been a stable bet all along.
> Unfortunate that the IEEE reference is not a free download. But it is "only" an informative reference.
> 
> 32) <!-- [rfced] The following URL appears to be to a personal webpage. May we update to use
> https://ieeexplore.ieee.org/document/397042 instead?
> 
> Original:
>   [YARE95]   Yang, C. and A. Reddy, "A Taxonomy for Congestion Control
>              Algorithms in Packet Switching Networks", Article IEEE
>              Network Magazine, p. 34-45, 1995,
>              <http://www.cs.uccs.edu/~zbo/teaching/CS522/Projects/
>              Taxonomy_Network1995.pdf>.
> 
> Perhaps: 
>   [YARE95]   Yang, C. and A. Reddy, "A Taxonomy for Congestion
>              Control Algorithms in Packet Switching Networks", IEEE
>              Network, Volume 9, Issue 4, Pages 34-45,
>              DOI 10.1109/65.397042, August 1995,
>              <https://ieeexplore.ieee.org/document/397042>.
> -->
> 
> I'm torn because IEEE require you to have an account. But it is "only" an informative reference, so you choose.
> 
> 33) <!-- [rfced] Would it be helpful to align the format of Appendices A.1 and A.2
> by including the word "Section" before section numbers in A.1? Also, may
> we put the section titles in parentheses with quotation marks? Or do you prefer the current?
> 
> Original (A.1):
>   1.0 Introduction:  Edited in place in Section 1.
> 
>      1.1 What is Internet Traffic Engineering?:  Edited in place in
>         Section 1.1.
> 
>      1.2 Scope:  Moved to Section 1.3.
> 
>      1.3 Terminology:  Moved to Section 1.4 with some obsolete terms
>         removed and a little editing.
> 
> Perhaps (title in parentheses with quotation marks):
>   Section 1 ("Introduction"): Edited in place in Section 1.
> 
>      Section 1.1 ("What is Internet Traffic Engineering?"):  Edited 
>         in place in Section 1.1.
> 
>      Section 1.2 ("Scope"):  Moved to Section 1.3.
> 
>      Section 1.3 ("Terminology"):  Moved to Section 1.4 with some 
>      obsolete terms removed and a little editing.
> -->
> 
> Sure
> 
> 34) <!-- [rfced] The following text appears in the Acknowledgements
> section. Should it appear in the Contributors section instead? The text
> says, "the original authors should be considered as Contributors to this
> work".
> 
> Original:
>   Much of the text in this document is derived from RFC 3272.  The
>   editor and contributors to this document would like to express their
>   gratitude to all involved in that work.  Although the source text has
>   been edited in the production of this document, the original authors
>   should be considered as Contributors to this work.  They were:
> 
>      Daniel O. Awduche
>      Movaz Networks
> 
>      Angela Chiu
>      Celion Networks
> 
>      Anwar Elwalid
>      Lucent Technologies
> 
>      Indra Widjaja
>      Bell Labs, Lucent Technologies
> 
>      XiPeng Xiao
>      Redback Networks
> -->
> 
> This was done to avoid the IPR issues associated with listing people as contributors.
> Technically, even now, if you move the text we have to either:
> - get all of these people to give IPR disclosure assurances
> or
> - get AD sign-off
> 
> I have objection to crediting these people. I don't want to wait while we track down people who left the industry 20 years ago!
> 
> 35) <!-- [rfced] FYI - We added a citation and corresponding reference entry
> for the errata report in this sentence.
> 
> Original:
>   The production of this document includes a fix to the original text
>   resulting from an Errata Report by Jean-Michel Grimaldi.
> 
> Perhaps: 
>   The production of this document includes a fix to the original text
>   resulting from an errata report #309 [Err309] by Jean-Michel
>   Grimaldi.
> -->
> 
> Sure
> 
> 36) <!-- [rfced] Reference Relevance
> 
> a) Please review the use of "MPLS-TE [RFC3209]" in these sentences. We do not
> see the exact term "MPLS-TE" in RFC 3209, though we do see "traffic
> engineering with MPLS" and "traffic engineering over MPLS", both with a
> reference to RFC 2702. Also, the title of RFC 3209 is "RSVP-TE: Extensions to
> RSVP for LSP Tunnels". Please review and let know if any updates are needed.
> 
> Original:
>   Examples include
>   Diffserv with dropping and remarking [RFC4594], MPLS-TE [RFC3209],
>   and GMPLS based label switched paths [RFC3945], as well as
>   controller-based solutions [RFC8453]. 
>   ...
>   The concept of constraint-based routing within the context of MPLS TE
>   requirements in IP networks was first described in [RFC2702] and led
>   to developments such as MPLS-TE [RFC3209] as described in
>   Section 5.1.3.3.      
> 
> 1. Always "MPLS-TE"
> 2. It's OK to use 3209 as a reference for MPLS-TE - the world has moved on from when 3209 was written and 3212 was still considered a possibility.
> 
> b) We do note see the exact term "IP Performance metrics" in RFC 5664, though
> we do see two instances of "performance". Please confirm this citation is
> correct.
> 
> Current:
>   *  Expansion of the function of IP Performance metrics [RFC5664]
>      where specific constraint-based routing (flex-algo) can be
>      instantiated within the network based on the results of
>      performance measurement.
> 
> I think this is fine as is.
> 
> c) Please confirm that the [RFC7471] and [RFC5329] citations are correct. We 
> do not see "Router Address" in RFC 7471, and we see "Router IPv6 Address" as 
> the name of the TLV in RFC 5329. 
> 
> Original:
>   *  OSPFv2 uses Opaque LSA type 10 [RFC5250], and OSPFv3 uses the
>      Intra-Area-TE-LSA.  In both OSPF cases, two top-level TLVs are
>      used (Router Address and Link TLVs), and these use sub-TLVs to
>      carry the TE parameters (as defined in [RFC7471] for OSPFv2 and
>      [RFC5329] for OSPFv3.
> -->
> 
> 7471 says...
>   This document defines new OSPF TE sub-TLVs that are used to
>   distribute network performance information.  The extensions in this
>   document build on the ones provided in OSPFv2 TE [RFC3630] and OSPFv3
>   TE [RFC5329].
> 
> 3630 ss2.4 defines the two top-level TLVs for OSPFv2
> Yes, technically, in OSPFv3, the top-level TLV is called the "Router IPv6 Address" although everyone is happy to call it the "Router Address TLV".
> 
> I think the text can stand.
> 
> 37) <!-- [rfced] Abbreviations
> 
> a) We note that "traffic engineering" and "Segment Routing" and their 
> abbreviations "TE" and "SR" are used often throughout the document. Would 
> you like to expand the first instance and then use the abbreviation in the 
> remainder of the document? Or do you prefer the current arrangement?
> 
> We did this for terms like "Label Switched Paths (LSP)", "Label Switching
> Router (LSR)", "Autonomous System (AS)" and "Path Computation Element (PCE)"
> that appeared only a few times in the document.
> 
> I thought about this a lot wrt "traffic engineering". I felt that, because the document was about traffic engineering, it read better to sometimes return to the expanded name and not use an abbreviation each time.
> 
> I'd be happy if you changed to "SR"
> 
> b) FYI - We have added expansions for abbreviations upon first use per Section
> 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
> document carefully to ensure correctness.
> 
> point-to-point (P2P)
> Standards Development Organizations (SDOs)
> Segment Identifier (SID)
> Simple Two-way Active Measurement Protocol (STAMP)
> Two-Way Active Measurement Protocol (TWAMP)
> MPLS Adaptive Traffic Engineering (MATE)
> -->
> 
> All good. (See "AS" mentioned earlier ;-)
> 
> 38) <!-- [rfced] Terminology
> 
> a) May we hyphenate "traffic engineering" in the attributive position (i.e., adjective 
> before a noun)? Note that this may not apply if TE is used after the first expansion per
> the question above.
> 
> I believe this is not a new question!
> There was a time when the community strongly resisted hyphenation.
> However, with (e.g.) 4461 a page was turned (spot the author ;-)
> With this document, I think the inherited text caused me to fall back to the old style.
> I don't object to hyphenation.
> 
> b) Would you like to update "head-end" to "headend" (no hyphen)? Most instances
> appear in Section 5.1.1.3; that section cites RFC 9256, which uses "headend".
> 
> "Headend" looks like an aberration!
> Merriam-Webster seems to recognise it in a limited form.
> Hmmm. Consistency is probably good. So,
> 1. All uses in the document should be the same
> 2. Consistency with the reference is probably good.
> House style?
> 
> c) We note inconsistencies in the terms below throughout the text. Should these
> be uniform? If so, please let us know which form is preferred.
> 
> IETF network slice vs. IETF Network Slice
>  Note: It looks like draft-ietf-teas-ietf-network-slices-25 mostly uses
>  the capitalized form.
> 
> Yes, capitalise (although, note that that draft is also in your queue!)
> 
> MPLS TE  vs. MPLS-TE
> 
> As above, please hyphenate
> 
> d) We note inconsistencies in the terms listed below. We chose the form on the
> right. Please let us know any objections.
> 
> prefix SID vs. Prefix SID
> 
>  Capitalise
> 
> end-point vs. endpoint
> 
>  Resolve as head-end/headend or house style
> 
> IP Performance metrics vs. IP Performance Metrics
> 
>   All cases are correct (capitalised) except 5.1.3.1 which should read
>             "Expansion of the function of IP performance metrics"
> 
> SR policy vs. SR Policy
> 
>   Capitalise
> 
> flexible algorithm vs. Flexible Algorithm (per RFC 9350)
> 
> See your 38)j)
>   All correct except 5.1.3.1.1 should read...
>                "IGP Flexible Algorithms [RFC9350]"
> 
> time scale vs. timescale
> 
>   timescale
> 
> e) FYI - We made the following hyphenation choices (note that some of these
> vary from usage in RFC 3272 but are consistent with usage in more recent
> RFCs):
> 
> end-user vs. end user (open as noun)
> edge-node vs. edge node (open as noun)
> best effort vs. best-effort (hyphen for adjective before noun)
> equal cost vs. equal-cost (hyphen for adjective before noun) 
> end-system vs. end system (open as noun)
> link state vs. link-state (hyphen for adjective; open for noun)
> mission critical vs. mission-critical (hyphen for adjective before noun)
> traffic aggregate vs. traffic-aggregate (hyphen for adjective; open for noun)
> traffic oriented > traffic-oriented (hyphen for adjective before noun)
> 
> Not going to object with any of those (although note that an "end-user" does not use an end as an "end user" would, they are a user at an end).
> 
> f) This document contains four instances of "TE-tunnel" in Section 7. Although
> "TE-tunnel" was used in RFC 3272 and a few other RFCs, "TE tunnel" (no hyphen)
> is much more common in the RFC Series. Please review and let us know if any
> updates are needed here.
> 
> Happy either way so long as consistent.
> 
> g) FYI - The following terms appear in Section 5.1.3.2, which discusses RSVP
> [RFC2205]. We updated the terms as follows to match usage in RFC 2205.
> 
> PATH message > Path message 
> RESV message > Resv message 
> 
> OK
> 
> h) We updated "Segment-List" to "segment list" as we we do not see
> "Segment-List" in published RFCs. Please review.
> 
> Original:
>   Each SR
>   path consists of a Segment-List (an SR source-routed path), and the
>   head-end uses the endpoint and color parameters to classify packets
>   to match the SR policy and so determine along which path to forward
>   them. 
> 
> Ack. 
> 
> i) The term "class-list" (with hyphen) is used consistently in Section
> 6.8. Should this be updated to "class type" (no hyphen) or "Class-Type"
> (initial caps with hyphen)? We see that the latter is used in RFC 4124, 
> which is cited in Section 6.8.
> 
> Assuming you meant "class-type".
> Yes, per 4124.
> 
> j) The term "flex-algo" is used in this document with a reference to RFC 9350,
> but "flex-algo" does not appear in RFC 9350. In fact, we only see this term
> used once in the RFC Series (RFC 9433). Would you like to update instances of
> "flex-algo" to either "Flexible Algorithm" or "Flex-Algorithm", both of which
> appear in RFC 9350? Or would you like to leave this as is?
> 
> You're right. Sloppy.
> See also your 38)d).
> I'd prefer every "flex-algo" to be changed to "Flexible Algorithm"
> 
> k) FYI - We updated "Edge computing" and "Datacenter interconnect" as follows
> to match usage in past RFCs.
> 
> Current:
>   The ALTO Working Group is
>   evaluating the use of network TE properties while making application
>   decisions for new use cases such as Edge computing and Datacenter
>   interconnect.
> 
> Perhaps:
>   The ALTO Working Group is
>   evaluating the use of network TE properties while making application
>   decisions for new use cases such as edge computing and data-center
>   interconnect.
> 
> OK
> 
> l) Please review the following terms and verify if the quotation marks are
> necessary.
> 
> Double quotes are fine in all cases when used...
> 
> "acceptable service quality" - please quote
> "clouds" - no quote
> "effective capacity" - no quote
> "five-tuple" - no quote
> "intent" - please quote in first line of 4.5.1, but then no more
> "underlay" - no quote
> "overlay" - no quote
> "policy" - no quote
> "publication/subscription" techniques - no quote
> "shortest paths" - please quote
> "sliced" - no quote
> 
> m) We see a number of uses of the "/" character separating terms in this
> document. Please review and let us know if these are okay or if we
> should change any instances to "and/or", "and", or "or".
> 
> Some examples:
> 
> avoiding/relieving
> BGP/Service route
> control/controller level
> data/forwarding plane
> protected/restored
> protection/restoration
> SIDs/Labels
> sources/destinations
> 
> I looked at all cases and would not change any.
> 
> -->
> 
> 39) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.
> 
> a) For example, please consider whether "natively" should be updated.
> 
> Current:
>   Note that
>   QUIC [RFC9000] natively supports the switching and steering
>   functions. 
> 
> Strike "natively". 
> 
> b) In addition, please consider whether "tradition" should be updated for
> clarity.  While the NIST website
> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> 
> Current:
>   The traditional approach to routing in an IGP network relies on the
>   IGPs deriving "shortest paths" over the network based solely on the
>   IGP metric assigned to the links. 
>   ...
>   RED provides congestion
>   avoidance that is better than or equivalent to traditional
>   Tail-Drop (TD) queue management (drop arriving packets only
>   when the queue is full). 
> -->
> 
> s/traditional approach/normal approach/
> s/equivalent to traditional/equivalent to/
> 
> Thank you.
> 
> No, thank you.
> 
> 
> 
>