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

[Adrian Farrel <[e-mail]>]

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.